Ex Parte Lo et al

Patent Trial and Appeal Board

Feb 23, 2016

12315730 (P.T.A.B. Feb. 23, 2016)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE
12/315,730 12/05/2008
28524 7590 02/25/2016
SIEMENS CORPORATION
INTELLECTUAL PROPERTY DEPARTMENT
3501 Quadrangle Blvd Ste 230
Orlando, FL 32817
FIRST NAMED INVENTOR
George Lo
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O. Box 1450
Alexandria, Virginia 22313-1450
www .uspto.gov
ATTORNEY DOCKET NO. CONFIRMATION NO.
2007P27549US01 3295
EXAMINER
HARMON, COURTNEY N
ART UNIT PAPER NUMBER
2159
NOTIFICATION DATE DELIVERY MODE
02/25/2016 ELECTRONIC
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the
following e-mail address( es):
ipdadmin.us@siemens.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte GEORGE LO and RONALD LANGE1
Appeal2014-000758
Application 12/315,730
Technology Center 2100
Before MICHAEL J. STRAUSS, JON M. JURGOV AN, and
MICHAEL M. BARRY, Administrative Patent Judges.
BARRY, Administrative Patent Judge.
Appellants appeal under 35 U.S.C. § 134(a) from a final rejection
under 35 U.S.C. § 103(a) of claims 1-23. We have jurisdiction under
35 U.S.C. § 6(b).
We affirm.
1 Appellants identify the real party in interest as Siemens Aktiengesellschaft.
App. Br. 1.
Appeal2014-000758
Application 12/315,730
Introduction
Appellants generally describe the "invention relates to collaborative
authoring using software applications, and more particularly, to integrating
multiple authoring applications in a collaborative environment." Spec. i-f 2
("Background of the Invention"). Claim 1 is illustrative of the claimed
subject matter at issue on appeal (key disputed limitations in italics):
1. A method for enabling collaborative authoring of data
between multiple authoring applications, comprising:
receiving a request for at least one data object from an
authoring application at an integration platform;
determining whether the at least one data object is stored
in an integration layer of the integration platform;
when the at least one data object is not stored in the
integration layer:
loading at least one data cluster including the at
least one data object to the integration layer from a
backbone layer of the integration platform, and
locking the at least one data cluster on the
backbone layer in response to loading at least one data
cluster including the at least one data object to the
integration layer;
loading the at least one data object from the integration
layer to the authoring application; and
locking the at least one data object in the integration
layer.
App. Br. 35 (Claims App'x).
Rejections
Claims 1-23 stand rejected under 35 U.S.C. § 103(a) as obvious over
Seelemann (US 2004/0122897 Al; June 24, 2004) and Eshel (US
2006/0212453 Al; Sept. 21, 2006). Final Act. 3-16.
2
Appeal2014-000758
Application 12/315,730
ANALYSIS
We have reviewed the Examiner's rejections and Answer in light of
the Appellants' Appeal and Reply Briefs, including the cited evidence.
Unless noted otherwise below, we adopt as our own the findings and reasons
set forth by the Examiner. See Final Act. 3-16; Ans. 3-8. We discuss
selected issues for emphasis.
A. Claim 1
The Examiner finds Seelemann teaches all steps of claim 1 except for
"locking the at least one data object in the integration layer," which the
Examiner finds Eshel teaches. Final Act. 3-5. Appellants argue Seelemann
fails to teach or suggest the "loading at least one data cluster ... to the
integration layer ... "and "locking the at least one data cluster on the
backbone layer ... " limitations. App. Br. 16-21. Appellants also argue
Eshel, in combination with Seelemann, fails to teach or suggest "locking the
at least one data object in the integration layer." Id. at 22-23.
1. Loading to the Integration Layer
Appellants argue the Examiner errs because "the repository adapter of
Seelemann is not the same as the claimed integration layer of independent
claim 1," explaining
[t]here is no description in Seelemann of the repository adapter
loading a data cluster (or cluster of multiple documents) that
includes the requested document from the WebDA V repository
when the requested document is not already stored on the
repository adapter. Therefore, Seelemann does not teach or
suggest "loading at least one data cluster including the at least
one data object to the integration layer from a backbone layer of
the integration platform," as recited in independent claim 1.
App. Br. 19. The Examiner responds
3
Appeal2014-000758
Application 12/315,730
the claims merely recite the request of a data object and
retrieval of a data cluster. A data object can be any amount of
data, the data object can be as little as a portion of a document
or an entire document. Thus, a search for a keyword that
retrieves a document from the WebDA V [repository] and loads
the document in the repository adaptor is equivalent to the
determining if a data object (keyword) is in the integration layer
and the loading of a data cluster (the document containing the
keyword) from the backbone layer.
Additionally, to provide the domain hierarchy and particular
documents and objects defining the hierarchy, a collection or cluster
of documents need to be retrieved to the repository adaptor (See
paragraph[]71 and 72 in Seelemann).
Ans. 4. Appellants argue in reply that
[ e ]ven if the repository adapter of Seelemann can retrieve
multiple documents, paragraph [0072] teaches that the
repository adapter retrieves the documents requested by a user.
There is no description in Seelemann of the repository adapter
retrieving a cluster of documents when a particular document
requested by a user is not stored in the repository adapter.
Reply Br. 4. Appellants further argue
there is no description in Seelemann of any determination of
whether a requested keyword is stored on the repository adaptor
and then retrieving a document including that keyword when
the requested keyword is not stored on the repository adapter.
Further, no matter how the Examiner attempts to interpret the
terms "data object" and "data cluster" recited in independent
claim 1, there is no description in Seelemann of loading a data
cluster including a requested data object to the repository
adapter when it is determined that the requested data object is
not stored in the repository adapter.
Reply Br. 5---6.
We agree with the Examiner. Seelemann's WebDA V repository and
repository adapter map to the claimed backbone layer and integration layer,
4
Appeal2014-000758
Application 12/315,730
respectively. The Examiner correctly concludes that "data object" and "data
cluster" are not limited to files and clusters of files. A broad but reasonable
interpretation of "data cluster" includes data objects within a document
(unlike, as Appellants suggest above, that in the context of Seelemann a data
cluster must be a "cluster of multiple documents").
We agree with the Examiner one of ordinary skill would have
understood that in the system taught by Seelemann, a user can perform
keyword searching and then retrieve a document from the WebDA V
repository so as to retrieve a file containing a data cluster that includes a
requested object to a repository adapter. Although we agree with Appellants
that Seelemann is silent on keyword searching, this does not detract from the
finding that one of ordinary skill would have understood that Seelemann
describes retrieving documents, which contain objects, and that an attempt to
retrieve such documents will, when they are unavailable from the repository
adapter, result in loading such documents from the WebDA V repository,
thus disclosing the disputed step of "loading at least one data cluster
including the at least one data object to the integration layer from a
backbone layer of the integration platform" as required by claim 1.
2. Locking on the Backbone Layer
Appellants also argue the Examiner errs because "[a]lthough the
repository adapter loads documents from the repository, there is no
description in Seelemann of a document being locked [on the backbone
layer] in response to loading the document from the repository." App. Br.
21. The Examiner responds "[a] data cluster can be an object or an entire
document, [and paragraph] 7 6 in Seelemann describes locking a document at
the WebDA V layer (analogous to backbone layer) to make changes to
5
Appeal2014-000758
Application 12/315,730
them," and that "locks are based on the earlier loading step recited in
[paragraph] 72 of Seelemann." Ans. 5.
Appellants in reply argue that, in Seelemann, "the document being
locked is not a data cluster that includes a requested data object," and
"Seelemann does not teach or suggest 'locking the at least one data cluster
on the backbone layer in response to loading at least one data cluster
including the at least one data object to the integration layer,' as recited
in independent claim 1." Reply Br. 7-8. We find Appellants' arguments
unpersuasive. As discussed above, Seelemann's WebDA V repository maps
to the claimed backbone layer, and a document may constitute a data cluster.
Seelemann also teaches locking documents (i.e., data clusters) in the
WebDA V repository (backbone layer) in response to requests from the
repository adapter (integration layer). Seelemann i-f 76 ("repository adapter
406 communicates with WebDA V repository 102 to obtain all necessary
locks to the documents affected by the change request").
Appellants further argue "[a]lthough the servers of Eshel processes
[sic] lock requests to lock the files in the storage device, there is no
description of a cluster of files being locked in the storage device," and
"[t]here is no description in Eshel of locking a data cluster in a backbone
layer .... " App. Br. 21. The Examiner, however, relies on Eshel only for
its teaching of locking a data cluster in the "locking the at least one data
cluster on the backbone layer" step (i.e., Eshel is not cited for claim 1 's "on
the backbone layer" requirement). Final Act. 4. We agree with the
Examiner's findings including that Seelemann in combination with Eshel
teaches the disputed limitation of "locking ... on the backbone layer ... " as
required by claim 1. See Ans. 4--5. Nonobviousness cannot be established
6
Appeal2014-000758
Application 12/315,730
by attacking the references individually when the rejection is predicated
upon a combination of prior art disclosures. See In re Merck & Co., Inc.,
800 F.2d 1091, 1097 (Fed. Cir. 1986).
3. Locking in the Integration Layer
Appellants argue the Examiner errs in finding Eshel (in the context of
the combination with Seelemann) teaches claim 1 's "locking the at least one
data object in the integration layer" requirement because "the cluster server
of Eshel is not an integration layer of an integration platform having an
integration layer and a backbone layer, as required." App. Br. 22. The
Examiner responds by finding Eshel teaches "managing the locks ofbyte-
ranges by the cluster file system" and "explicitly recites delegating the
locking function to the cluster servers (analogous to integration layer) for the
data in the storage device (backbone layer)." Ans. 6 (citing Eshel i-fi-f 14, 33-
34, and Fig. 2).
Appellants reply that
as described at paragraph [0034] of Eshel "byte-range" locking
is merely another way of saying file record locking. Although,
Eshel describes the use of file record locking, there is no
description in Eshel of a file being locked that is a cluster
including a requested data object. Therefore, Eshel, separately
or in combination with Seelemann, does not teach or suggest
"locking the at least one data cluster on the backbone layer in
response to loading at least one data cluster including the at
least one data object to the integration layer," as recited ....
Reply Br. 9.
We find Appellants' arguments unpersuasive. As discussed above, a
file may constitute a data cluster including a requested data object, and
Seelemann teaches both a backbone layer (WebDA V) and integration layer
7
Appeal2014-000758
Application 12/315,730
(repository adapter) and locking a file (data cluster) on the backbone layer.
Appellants argue in reply that Eshel does not teach "locking ... on the
backbone .... " We note the rejection also finds Seelemann teaches the
locking requirement. Final Act. 4. The Examiner relies upon Eshel only for
"locking the at least one data object in the integration layer." Id. We agree
with the Examiner that Eshel's multi-tier locking disclosure teaches locking
at two tiers that correspond to claim 1 's integration and backbone layers,
respectively, as taught by Seelemann. Thus, the combination of Eshel and
Seelemann teaches or suggests the disputed step of locking the at least one
data object in the integration layer.
4. Reason to Combine
Appellants contend "there is no reason that one of ordinary skill in the
art would apply the locks of Eshel in the repository adaptor of Seelemann"
and that "Seelemann teaches against locking documents in the repository
adapter" (App. Br. 22), arguing
even if Eshel were considered to teach "locking the at least one
data object in the integration layer," as asserted by the
Examiner, this teaching could not be combined with the
repository adapter of Seelemann, because applying locks to
documents at the repository adapter would defeat the capability
of the repository adapter to support fine-grained change
requests, and thus defeat the entire purpose of Seelemann.
Therefore, Seelemann and Eshel cannot be combined to teach
"locking [ ... ] in the integration layer," as recited.
App. Br. 23 (citing Seelemann i-f 79).
Appellants' reasons for why the teachings of the references are not
properly combinable are based on argument that either Seelemann teaches
away from the combination or that modifying Seelemann according to the
8
Appeal2014-000758
Application 12/315,730
teachings of Eshel would render Seelemann's device inoperable for its
intended purpose. We find both arguments unpersuasive. For a reference to
teach away, it must criticize, discredit, or otherwise discourage the claimed
solution. See In re Fulton, 391 F.3d 1195, 1201 (Fed. Cir. 2004). Paragraph
79 of Seelemann, which Appellants cite for their teaching away argument,
states in its entirety:
Following the processing of the first client's change
request, processing of the second client's change request is
undertaken in a like manner. Importantly, neither update will
fail, because the granularity of the change supported is finer
than a WebDAV document and the change requests can be
significantly more efficient than using WebDA V directly, since
a single change request can reference more than one document
while WebDAV changes need to specify all the content of all
the affected documents.
We find, consistent with the Examiner, that Seelemann does not
criticize, discredit, or otherwise discourage a two-tier locking scheme as
claimed. Rather, Seelemann at most criticizes limitations on WebDA V's
locking functionality and "using WebDA V directly." Similarly, the other
passages cited by Appellants for the teaching away argument (Seelemann
i-fi-172 and 74--79) do not criticize, discredit, or otherwise discourage a
combination Eshel's multi-tier locking teachings with Seelemann to achieve
claim 1. We agree with the Examiner that one of ordinary skill understands
that the multi-tier and record-level locking as taught by Eshel can be used
with Seelemann's teachings to result in methods such as claim 1.
Furthermore, we are unpersuaded the combination is improper
"because applying locks to documents at [Seelemann's] repository adapter
would defeat the capability of the repository adapter to support fine-grained
change requests, and thus defeat the entire purpose of Seelemann." App. Br.
9
Appeal2014-000758
Application 12/315,730
23. That is, Appellants' argument improperly relies on wholesale
incorporation of systems rather than what the combination would suggest.
[T]he test for obviousness is not whether the features of a
secondary reference may be bodily incorporated into the
structure of the primary reference; nor is it that the claimed
invention must be expressly suggested in any one or all of the
references. Rather, the test is what the combined teachings of
the references would have suggested to those of ordinary skill
in the art.
In re Keller, 642 F.2d 413, 425 (CCPA 1981).
The artisan is not compelled to blindly follow the teaching of one
prior art reference over the other without the exercise of independent
judgment. See Lear Siegler, Inc. v. Aeroquip Corp., 733 F.2d 881, 889 (Fed.
Cir. 1984). We are further mindful that the skilled artisan would "be able to
fit the teachings of multiple patents together like pieces of a puzzle" because
the skilled artisan is "a person of ordinary creativity, not an automaton."
KSR Int 'l Co. v. Teleflex Inc., 550 U.S. 398, 420-21 (2007). Here,
Appellants have not demonstrated that the Examiner's proffered
combination would have been "uniquely challenging or difficult for one of
ordinary skill in the art." Leapfrog Enters., Inc. v. Fisher-Price, Inc., 485
F.3d 1157, 1162 (Fed. Cir. 2007) (citing KSR, 550 U.S. at 418).
For the reasons discussed above, we are unpersuaded of error in the
Examiner's combination of Seelemann and Eshel, and accordingly, we
sustain the rejection of claim 1.
5. Other Claims Argued Based on Claim 1
Appellants provide no substantive argument for claims 2--4, 6, 7, 10,
11, 13, 14, 17, 18, 20, and 21 separate from the arguments for claim 1. See
App. Br. 23, 26-27, 30-31. We thus sustain the Examiner's rejection of
10
Appeal2014-000758
Application 12/315,730
these claims. See 37 C.F.R. § 41.37(c)(l)(vii); Jn re Lovin, 652 F.3d 1349,
13 51 (Fed. Cir. 2011) (sustaining requirement for separate substantive
arguments for appellate review of individual claims).
Claim 5
Claim 5 adds "loading the at least one data cluster to a local database
of the integration layer that is associated with a user of the authoring
application" to claim 1. Appellants argue the Examiner errs in rejecting
claim 5 because
although paragraph [0081] of Seelemann describes that the
repository adaptor sends [a] copy of a document received from
the WebDA V repository to the requesting client, there is no
description of the document being loaded from the WebDA V
repository to any local database of the repository adaptor that is
associated with the client.
App. Br. 24.
The Examiner responds that "paragraph[]72 of Seelemann describes
the process of loading requested files and data objects from the WebDA V
layer to the repository Adapter layer and provid[ing] such document[s] to the
requesting client." Ans. 7. Appellants in reply argue Seelemann does not
describe "any local database of the repository adaptor that is associated with
the client." Reply Br. 11. However, Appellants do not explain why the
repository adapter, which is used for retrieving, storing, and querying data
objects, does not teach or suggest the recited database and, therefore, fail to
address the Examiner's findings. In the absence of sufficient rebuttal, we
find no reversible Examiner error and sustain the rejection of claim 5, along
with claims 12 and 19, which Appellants do not argue separately from claim
5. See App. Br. 27-28 and 31-32.
11
Appeal2014-000758
Application 12/315,730
Claim 8 adds
Claims 8 and 9
sending notification of the modified at least one data object to
different instances of the integration layer from an instance of
the integration layer at which the modified at least one data
object is received, in response to said step of propagating the
modified at least one data object to the backbone layer
to claim 6 (which modifies claim 1 with (inter alia) "wherein the at least one
data object is modified"). Claim 9 adds "sending the notification of the
modified at least one data object to instances of the integration layer storing
data clusters linked to the at least one data cluster in the backbone layer" to
claim 8. The Examiner's rejection relies upon Seelemann for the added
limitations of both claims. Final Act. 6-7 (citing i-f 85 (which describes
"repository adapter 406 publishes to all clients a domain update message"
after "check-in of the affected documents to WebDA V depository")).
Appellants argue the Examiner errs in rejecting claims 8 and 9
because "there is no description in Seelemann of multiple instances of the
repository adapter and one instance of the repository adapter sending
notification of a modified data object to other instances of the repository
adapter." App. Br. 28, 29. We find this argument unpersuasive. Although
we agree with Appellants that "the domain model is a collection of
documents, not an instance of the repository adapter" in arguing the
Examiner errs in mapping Seelemann' s disclosure to the claim requirements
(Reply Br. 11; Ans. 8), this does not vitiate the correctness of the
Examiner's rejection (Final Act. 6-7 (citing Seelemann i-f 85)). The
rejection is based on disclosure that a repository adapter (one instance of an
integration layer) sends notification to multiple clients to update accordingly
12
Appeal2014-000758
Application 12/315,730
(i.e., make updates in their local repository adapters, which are other
instances of an integration layer). Accordingly, we sustain the Examiner's
rejection of claims 8 and 9, and along with them claims 15, 16, 22, and 23,
which Appellants do not argue separately. See App. Br. 28-30 and 32-33.
DECISION
The Examiner's rejection of claims 1-23 is affirmed.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(l )(iv).
AFFIRMED
13