Ex Parte Mair et al

Board of Patent Appeals and Interferences

May 21, 2012

10702259 (B.P.A.I. May. 21, 2012)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________________

Ex parte DAVID A. MAIR and THOMAS N. LEE
____________________

Appeal 2010-002306
Application 10/702,259
Technology Center 2100
____________________

Before ALLEN R. MacDONALD, MICHAEL R. ZECHER, and
JUSTIN T. ARBES, Administrative Patent Judges.

ARBES, Administrative Patent Judge.

DECISION ON APPEAL

Appeal 2010-002306
Application 10/702,259

2

STATEMENT OF CASE
Appellants appeal under 35 U.S.C. § 134(a) from a rejection of claims
1-4, 6-14, 18-23, 26-31, and 34-48, the only claims pending in the
application on appeal. Claims 5, 15-17, 24, 25, 32, and 33 were cancelled.
We have jurisdiction over the appeal pursuant to 35 U.S.C. § 6(b).1
We affirm.
The claims are directed to an apparatus, system, computer-readable
medium, and method for using a cache with a hierarchical namespace of
containers (e.g., folders) and objects (e.g., files). A cache includes an
association between a flat identifier (e.g., file name), locality of reference
cue (e.g., Internet Protocol (IP) address, user name, password), and identifier
of a hierarchical container (e.g., folder path). Spec., pg. 5, ll. 1-18; pg. 7, l.
28-pg. 8, l. 19. For example, a user with a particular IP address may have
previously accessed a file, causing an association to be stored in the cache.
Spec., pg. 8, ll. 7-14. When the user later requests the same file name, a
search engine searches the cache for a combination of the file name and IP
address to identify the appropriate folder path for the file. Spec., pg. 13, ll.
1-14. If the cache contains the combination, an attempt is made to locate the
file in the associated folder (before looking in other folders if necessary).
Spec., pg. 3, ll. 10-16; pg. 13, ll. 14-25. If not, the system looks for the file
in all of the folders. Spec., pg. 13, l. 26-pg. 14, l. 2.

1 Our decision will make reference to Appellants’ Appeal Brief (“App. Br.,”
filed May 28, 2009) and Reply Brief (“Reply Br.,” filed November 2, 2009),
and the Examiner’s Answer (“Ans.,” mailed September 3, 2009) and Final
Rejection (“Final Rej.,” mailed October 27, 2008).
Appeal 2010-002306
Application 10/702,259

3

While Appellants separately argue many of the claims, claims 1, 18,
and 19 are exemplary:
1. An apparatus, comprising:
a first computer;
a hierarchical namespace including at least a first
hierarchical container and a second hierarchical container;
a cache stored on the first computer, the cache including
a first association including a flat identifier, a locality of
reference cue for the flat identifier, and an identifier of the first
hierarchical container, the flat identifier including a file
identifier identifying a file, the locality of reference cue
including a user identifier identifying a user interested in the
file, and the first association being stored in the cache after the
first computer receives a request from a second computer, the
request including the flat identifier and the locality of reference
cue derived from the request; and
a search engine to search the cache for a combination of
the flat identifier and the locality of reference cue to identify the
identifier of the first hierarchical container.

18. A computer-implemented method for mapping a flat
identifier to a hierarchical container, comprising:
receiving the flat identifier in a request from a client
computer, the flat identifier including a file identifier
identifying a file;
determining a locality of reference cue for the flat
identifier from the request, the locality of reference cue
including an identifier relating to a user interested in the file;
searching a cache for a combination of the flat identifier
and the locality of reference cue to identify the hierarchical
container; and
if the cache contains the combination of the flat identifier
and the locality of reference cue, attempting to locate the file in
a first hierarchical container associated with the combination of
the flat identifier and the locality of reference cue in the cache.
Appeal 2010-002306
Application 10/702,259

4

19. A method according to claim 18, further comprising
attempting to map the flat identifier to a second hierarchical
container if the cache does not contain the combination of the
flat identifier and the locality of reference cue.

REFERENCES
The prior art relied upon by the Examiner in rejecting the claims on
appeal is:
Balabine
Skopp
Ryan
Coram
US 5,937,406
US 6,256,739 B1
US 6,421,675 B1
US 2002/0107835 A1
Aug. 10, 1999
July 3, 2001
July 16, 2002
Aug. 8, 2002

REJECTIONS
Claims 1, 2, 6-14, 18-21, 26-29, and 34-48 stand rejected under 35
U.S.C § 103(a) as being unpatentable over Balabine in view of Coram. Ans.
3-17.
Claims 3 and 4 stand rejected under 35 U.S.C § 103(a) as being
unpatentable over Balabine in view of Coram and further in view of Ryan.
Ans. 17-18.
Claims 22, 23, 30, and 31 stand rejected under 35 U.S.C § 103(a) as
being unpatentable over Balabine in view of Coram and further in view of
Skopp. Ans. 19-21.
Appeal 2010-002306
Application 10/702,259

5

Claim 44 stands rejected under 35 U.S.C § 112, first paragraph, as
failing to comply with the written description requirement.2 Ans. 3.

ISSUES
Appellants argue on pages 8-53 of the Appeal Brief and pages 3-71 of
the Reply Brief that the Examiner’s rejections of independent claims 1, 11,
18, 26, 42, and 46, and dependent claims 3, 4, 7-10, 14, 19-23, 27-31, 34-37,
and 44, are in error. With respect to the independent claims, these
arguments present us with the following issues:
(1) Did the Examiner err in finding that the combination of
Balabine and Coram teaches a “locality of reference
cue,” as recited in claim 1, and as similarly recited in
claims 11, 18, 26, 42, and 46?
(2) Did the Examiner err in finding that the combination of
Balabine and Coram teaches an “identifier of the first
hierarchical container,” as recited in claim 1, and as
similarly recited in claims 11, 18, 26, 42, and 46?
(3) Did the Examiner err in finding that the combination of
Balabine and Coram teaches a “request including the flat
identifier and the locality of reference cue,” as recited in
claim 1, and as similarly recited in claims 11, 18, 26, 42,
and 46?
(4) Did the Examiner err in determining that the combination
of Balabine and Coram would have rendered obvious the
subject matter of claims 1, 11, 18, 26, 42, and 46?
(5) Did the Examiner err in finding that the combination of
Balabine and Coram teaches attempting to locate a file in
a first hierarchical container “if the cache contains the
combination of the flat identifier and the locality of

2 The Examiner withdrew the previous 35 U.S.C § 112 rejection of claims
38-41. Ans. 3.
Appeal 2010-002306
Application 10/702,259

6

reference cue,” as recited in claim 18, and as similarly
recited in claims 26 and 46?
With respect to the dependent claims, these arguments present us with
the following issues:
(1) Did the Examiner err in finding that the combination of
Balabine and Coram teaches “attempting to map” a flat
identifier to a second hierarchical container, as recited in
claim 19, and as similarly recited in claims 21, 27, and
29?
(2) Did the Examiner err in finding that the combination of
Balabine and Coram teaches a “second association,” as
recited in claims 7-10 and 14, and as similarly recited in
claims 20 and 28?
(3) Did the Examiner err in finding that the combination of
Balabine and Coram teaches mapping a flat identifier to a
“plurality” of hierarchical containers, as recited in claims
34 and 35?
(4) Did the Examiner err in finding that the combination of
Balabine and Coram teaches attempting to map a flat
identifier to a “distinct” second hierarchical container, as
recited in claims 36 and 37?
(5) Did the Examiner err in finding that the combination of
Balabine, Coram, and Ryan teaches a “sorter to sort the
combinations of the flat identifier and the hierarchical
containers,” as recited in claims 3 and 4?
(6) Did the Examiner err in finding that the combination of
Balabine, Coram, and Skopp teaches receiving “a user
identifier and a password,” as recited in claims 22 and
30?
(7) Did the Examiner err in finding that the combination of
Balabine, Coram, and Skopp teaches receiving “an
Internet Protocol (IP) address as the locality of reference
cue, from which the identifier and the password are
received,” as recited in claims 23 and 31?
Appeal 2010-002306
Application 10/702,259

7

(8) Did the Examiner err in finding that the Specification
lacks sufficient written description for a flat identifier
that “includes” a user identifier, as recited in claim 44?

ANALYSIS
I. 35 U.S.C. § 103(a) Rejection of Independent Claims
Appellants make a number of arguments that apply to (1) all six
independent claims, (2) just independent claims 42 and 46, and (3) just
independent claims 18, 26, and 46. See App. Br. 7. We select claim 1 as
representative for the first group, claim 42 for the second, and claim 18 for
the third, and address each of Appellants’ arguments in turn. See 37 C.F.R.
§ 41.37(c)(vii).
A. Claims 1, 11, 18, 26, 42, and 46
i. “Locality of Reference Cue”
Appellants first argue that Coram does not teach a cache including a
“locality of reference cue.” App. Br. 8-11; Reply Br. 11-12. Appellants
argue that claim 1 requires a three-way association between a flat identifier,
a locality of reference cue, and an identifier of a first hierarchical container,
but Coram only teaches a two-way association between a “result set” and a
“key” (consisting of a “client identifier” and “query string”). App. Br. 8-11.
Therefore, according to Appellants, the client identifier in Coram cannot be
considered a “locality of reference cue.” We disagree with Appellants.
Coram is directed to improved database searching by caching query
result sets. Coram ¶ 3. When a user queries a database, the query string and
results are stored in a cache so that if the same query is made again later, the
system only needs to look in the cache rather than the database as a whole.
See Coram ¶¶ 35-45. Coram also discloses preventing unauthorized access
Appeal 2010-002306
Application 10/702,259

8

to data in the cache by “stor[ing] result sets separately for each client.”
Coram ¶ 80. Specifically, Coram stores with each result set in the cache “a
key equal to a client identifier and the query string from the actual
[Structured Query Language] statement.” Coram ¶¶ 45, 80. The client
identifier in Coram identifies a “client”/”user” and therefore constitutes a
locality of reference cue, regardless of the particular format in which it is
stored in the cache (as part of a “key” with other data, or independently).
See Coram ¶ 80; Spec., pg. 8, ll. 10-12 (citing various “user”-associated
parameters as examples of a locality of reference cue). Thus, we agree with
the Examiner that Coram teaches or suggests a “locality of reference cue.”
Appellants’ position is essentially that to teach the locality of
reference cue in claim 1, Coram must teach it in a three-way association
with the other two required elements of the cache. The Examiner, however,
relied on Coram solely for a teaching of a cache and the locality of reference
cue itself. Ans. 5. The Examiner found that the combination of Balabine
and Coram together teaches or suggests the overall apparatus of claim 1,
mapping the following elements of the cache to their corresponding parts in
the combined references:
Flat identifier File name (Balabine, Figs. 2, 5)
Locality of reference cue Client identifier (Coram ¶ 80)
Identifier of a first
hierarchical container
Folder path (Balabine, Figs. 2, 5)
Ans. 4-6, 23-24. The Examiner also explained in detail how and why a
person of ordinary skill in the art would have combined the two references to
arrive at a cache comprising the three elements above. Ans. 4-6, 21-24, 27.
We are not persuaded that the Examiner erred in this analysis.
Appeal 2010-002306
Application 10/702,259

9

Appellants are responding to the rejection by arguing what Coram
teaches individually, even though the rejection is based on the combined
teachings of the references. “Non-obviousness cannot be established by
attacking references individually where the rejection is based upon the
teachings of a combination of references.” In re Merck & Co. Inc., 800 F.2d
1091, 1097 (Fed. Cir. 1986). Appellants have not pointed to any reason,
supported by sufficient facts, explaining why the combined functionality of
Balabine and Coram described by the Examiner would not result in a cache
with the three required elements. Further, to the extent Appellants’
arguments pertain to the Examiner’s stated rationale for incorporating
Coram’s caching into the Balabine system, the fact that some minimal
technical modification within the knowledge of a skilled artisan (e.g.,
changing the format of how the client identifier is stored in the cache) may
need to be made does not mean that a person of ordinary skill in the art
would not have combined them in the manner proposed by the Examiner.
See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007) (a patentability
analysis “can take account of the inferences and creative steps that a person
of ordinary skill in the art would employ,” and the skilled artisan would “be
able to fit the teachings of multiple patents together like pieces of a puzzle”).
Appellants also argue in the Reply Brief that Coram’s client identifier
does not include a “user identifier identifying a user interested in the file,” as
required by claim 1, pointing to the Examiner’s statement that the client
identifier could be, for example, an IP address. Reply Br. 4, 12 (citing Ans.
24). This argument regarding the “user identifier” element of claim 1 was
not timely raised, as it was made for the first time in Appellants’ Reply
Appeal 2010-002306
Application 10/702,259

10

Brief.3 See 37 C.F.R. § 41.41; Ex parte Nakashima, 93 USPQ2d 1834,
1836-40 (BPAI 2010); Ex parte Borden, 93 USPQ2d 1473, 1475 (BPAI
2010) (informative). Regardless, however, the client identifier in Coram
operates to only give certain “users” access to data in the cache, and
therefore identifies a user. See Coram ¶¶ 80 (referring to “end-users” and
information that “they” should not be allowed to access), 82 (referring to the
data in the key as “user information”).

ii. “Identifier of the First Hierarchical Container”
Appellants next argue that Coram does not teach a cache including an
“identifier of the first hierarchical container.” App. Br. 11-16; Reply Br. 6-
9, 13-15. Appellants contend that the “result set” in Coram is not an
“identifier” of a hierarchical container that stores an object, but rather a set
of objects themselves (i.e., items previously retrieved from a database).
App. Br. 11-14 (citing Coram ¶¶ 40-44). By contrast, the cache recited in
claim 1 does not store the object itself. Reply Br. 7-8.
We are not persuaded by Appellants’ argument, as it largely repeats
the argument addressed above that Coram lacks a three-way association of
the three required cache elements. Again, Appellants are arguing the
references individually rather than addressing the Examiner’s proposed
combination. See Merck, 800 F.2d at 1097. It is not the Balabine file or the
Coram query results that the Examiner mapped to the “identifier” element of

3 Appellants similarly argue for the first time in the Reply Brief that Coram
does not teach a “flat identifier.” Reply Br. 9-11. In addition to being
untimely, we note that the Examiner relied on Balabine, not Coram, for a
teaching of a “flat identifier.” Ans. 4, 23-24.
Appeal 2010-002306
Application 10/702,259

11

claim 1; the Examiner found that Balabine’s folder path, translated from
database results, was the recited “identifier.” Ans. 4, 24, 29-30 (citing
Balabine, col. 9, ll. 15-23, Fig. 5C). We agree with the Examiner’s finding
that in combination, Balabine and Coram would teach or suggest to a person
of ordinary skill in the art a cache including a folder path, which is a type of
“identifier of the first hierarchical container” according to Appellants’
Specification. See Spec., pg. 8, ll. 1-6 (“a folder is a type of container”).
Further, as to Appellants’ argument that the claimed cache does not store the
file itself, we note that there is nothing in claim 1 as written precluding the
cache from also storing the file, particularly because claim 1 recites what the
cache “includ[es].” See Mars, Inc. v. H.J. Heinz Co., 377 F.3d 1369, 1376
(Fed. Cir. 2004) (transitional, open-ended terms “comprising” and
“including” are synonymous).

iii. “Request Including the Flat Identifier and
the Locality of Reference Cue”
Appellants argue that the “request including the flat identifier and the
locality of reference cue” is an “atomic feature” that must be present in a
single reference, not in a combination of Balabine (which teaches a request
including a flat identifier) and Coram (which teaches a request including a
locality of reference cue and other information) as the Examiner found.
App. Br. 19-21; Reply Br. 9-15. Appellants analogize the Examiner’s
rejection to finding a claim to “salt” obvious over references teaching
sodium and chlorine. App. Br. 20-21.
We are not persuaded of error in the Examiner’s analysis combining
the requests from a reference teaching a hierarchical file structure (Balabine)
Appeal 2010-002306
Application 10/702,259

12

and a reference teaching caching for purposes of access control (Coram),
particularly because both references relate to accessing information in a
database and disclose the need to restrict user access. See Ans. 26-27;
Balabine, col. 7, ll. 28-29 (“access rights to the object for its owner,
community and others”); Coram ¶ 80. As the Examiner found, Balabine and
Coram together would teach or suggest to a person of ordinary skill in the art
a request comprising both a flat identifier and a locality of reference cue.
Further, the only case law cited by Appellants for an “atomic feature”
requirement is Diamond v. Diehr, 450 U.S. 175 (1981), which dealt with
patentable subject matter under 35 U.S.C. § 101, not obviousness.

iv. Obviousness
Appellants argue that Balabine and Coram do not render claim 1
obvious because incorporating the caching of Coram into the database
system of Balabine would (1) render Balabine unfit for its intended purpose
(App. Br. 21-25; Reply Br. 20), and (2) render Balabine useless if valid
result sets can be found in the cache (App. Br. 25-26; Reply Br. 21).
First, Appellants argue that “Balabine exists solely to enable
‘database-unaware’ applications to be able to use the database (indirectly)
through the file system calls,” and discloses “only” a file system interface
for accessing database information. App. Br. 21. By contrast, Appellants
contend that “the claimed invention is not limited to . . . a file system
interface,” and permits other types of data requests, such as user login or
Internet searching. App. Br. 23. We understand Appellants’ position to be
that changing Balabine from a file system interface to “some other interface”
capable of handling other types of requests like user login would render
Appeal 2010-002306
Application 10/702,259

13

Balabine unfit for its intended purpose. App. Br. 24-25. We disagree.
Balabine’s intended purpose is to provide a user with access to
information from a database. Balabine, col. 1, ll. 9-10. As Appellants
acknowledge, this can occur via a “database-unaware” or “database-aware”
application. See App. Br. 22-23; Balabine, col. 8, ll. 30-33. Incorporating a
cache as disclosed in Coram into the Balabine system would not destroy
Balabine’s intended purpose because the information stored in, and retrieved
from, the cache would have come from previous database requests.
Appellants provide no technical reason why a cache could not be
incorporated in the Balabine system or why making minimal changes to the
system of Balabine to incorporate a cache would prevent users from
accessing database information.
Further, the examples of user login and Internet searching that
Appellants cite from the Specification are not explicitly recited in claim 1.
Thus, whether or not the combination of Balabine and Coram could perform
those exact functions is not dispositive of the obviousness analysis. We also
disagree with Appellants’ argument that the “exemplary” user login situation
described in the Specification “cannot be reconciled to a file system
structure” (App. Br. 23) because the Specification itself discloses an
embodiment for locating files in a folder structure, just as in Balabine (Spec.,
pg. 7, l. 28-pg. 8, l. 19).
Second, Appellants assert that because Coram teaches returning a set
of objects themselves, not an “identifier” of a container that stores the
objects, the file itself in Balabine would be returned rather than an
“identifier” of the file’s container. App. Br. 26. Thus, Balabine would
never be used if the cache had what the user wanted, and a person of
Appeal 2010-002306
Application 10/702,259

14

ordinary skill in the art would have no reason to combine the references. We
disagree with this argument for the reasons set forth above with respect to
the “identifier” element. See supra, Section I.A.i-ii. Further, as Appellants
recognize, Balabine would still be used for its “translation service” as well
as “the first time the file system request was made” if combined with Coram.
Reply Br. 21. We see no reason why Balabine’s functionality would not be
used in the combination proposed by the Examiner, and concur with the
Examiner that the references would have rendered obvious the apparatus
recited in claim 1.

B. Claims 42 and 46
Appellants also argue independent claims 42 and 46. App. Br. 39-44;
Reply Br. 29-30. Independent claims 42 and 46 recite the three elements of
the cache more broadly than the other independent claims. See App. Br. 40.
For example, claim 1 recites that the flat identifier includes a “file identifier
identifying a file” and the locality of reference cue includes a “user identifier
identifying a user interested in the file,” whereas claim 42 simply recites a
flat identifier for a hierarchical namespace “object” (which may or may not
be a “file”) and a generic “locality of reference cue.” Similarly, claim 18
recites attempting to locate a “file,” whereas claim 46 more broadly recites
attempting to locate an “object.”
Appellants’ arguments restate what was previously argued for the
narrower claims. We disagree for the reasons stated above. Further, to the
extent Appellants argue that the combination of Balabine and Coram would
be incapable of performing other functions like user login (App. Br. 40-42),
again we disagree because a user login is not explicitly recited in the claims.
Appeal 2010-002306
Application 10/702,259

15

C. Claims 18, 26, and 46
Appellants argue that the combination of Balabine and Coram
proposed by the Examiner would not perform two searches. App. Br. 16-19;
Reply Br. 15-18. While Appellants contend that this argument applies to all
of the independent claims, we conclude that it only relates to claims 18, 26,
and 46. These claims recite in similar fashion (1) “searching a cache,” and
(2) “if the cache contains the combination of the flat identifier and the
locality of reference cue, attempting to locate the file [or object] in a first
hierarchical container.” The remaining independent claims 1, 11, and 42
recite the former but not the latter, and Appellants have not directed us to
any persuasive evidence to justify injecting the latter language into those
claims given their broadest reasonable interpretation in light of the
Specification. See In re ICON Health & Fitness, Inc., 496 F.3d 1374, 1379
(Fed. Cir. 2007).
Turning to the substance of the rejected claims 18, 26, and 46,
Appellants argue that the combination of Balabine and Coram does not
perform the second step of “attempting to locate the file.” App. Br. 16-19;
Reply Br. 15-18. Due to the conditional “if” language in the claims,
however, we interpret these claims as not requiring an attempt to locate the
file. The step of attempting to locate the file is expressly conditioned on the
cache containing a combination of the flat identifier and locality of reference
cue. However, there is no requirement in the claim that the cache actually
contain the combination, and therefore no requirement that the conditional
attempt be made. Indeed, claim 19 recites what occurs “if the cache does
not contain the combination.” Under the broadest reasonable scenario, the
Appeal 2010-002306
Application 10/702,259

16

“if” condition in the claims would not occur and the attempt would never be
made. Thus, claims 18, 26, and 46 cannot be read to require an attempt to
locate the file in every circumstance. See Ex parte Katz, 2011 WL 514314,
at *4-5 (BPAI Jan. 27, 2011) (interpreting a similar “if” condition in the
same manner), 2011 WL 1211248, at *2 (BPAI Mar. 25, 2011) (denying
request for rehearing); see also In re Johnston, 435 F.3d 1381, 1384 (Fed.
Cir. 2006) (“optional elements do not narrow the claim because they can
always be omitted”).
We also note that while claims 18 and 46 are method claims, claim 26
is directed to a “computer-readable medium.” Our decisions have drawn a
distinction between method claims and system/apparatus claims for purposes
of conditional “if” language. See, e.g., Katz, 2011 WL 514314, at *4-5.
However, because of how claim 26 is written, we conclude that the claim is
more analogous to a method than a system or apparatus, and interpret it in
the same manner as the method claims. Claim 26 is not written as a typical
system or apparatus claim, but rather as a “computer-readable medium
containing a program” comprising four instances of “software.” Software is
a set of instructions that tells a computer what to do, and the “if” condition
in claim 26 implies that those instructions may or may not ever be
performed. Further, claim 26 is written entirely in terms of function (i.e.,
four sets of instructions). There is no structural component capable of
implementing the instructions, such as a computer processor, that would
typically be present in a system or apparatus claim. See also infra, note 5.
Consequently, we interpret the conditional language in claim 26 in the same
fashion as claims 18 and 46.
Appeal 2010-002306
Application 10/702,259

17

The “attempting to locate the file” element is not present in claims 1,
11, and 42, and is not a limitation against which prior art must be found in
claims 18, 26, and 46. Accordingly, we sustain the Examiner’s rejection of
the independent claims.4

II. 35 U.S.C. § 103(a) Rejections of Dependent Claims
A. Claims 19, 21, 27, 29 (Balabine/Coram)
Appellants argue claims 19, 21, 27, and 29 together as a group. App.
Br. 27-29, 32-35; Reply Br. 23-25. We select claim 19 as representative,
which recites the opposite of the “if” condition in claim 18: “attempting to
map the flat identifier to a second hierarchical container if the cache does not
contain the combination of the flat identifier and the locality of reference
cue.” As claim 19 recites both “if” conditions, at least one of the conditional
features must be taught or suggested by the prior art for the claim to be
obvious.

4 While we interpret the claims as not requiring an attempt to locate the file
and therefore sustain the rejection, we also note that based on the record
before us, we disagree with the Examiner’s stated reasoning for finding such
an attempt in the combination of Balabine and Coram. First, the Examiner
found that although the references do not explicitly disclose two searches,
the first search “includes” the second attempt to locate. Ans. 30-31. As
Appellants point out, the two searches search different things – the first
searches in the “cache” and the second searches “in a first hierarchical
container.” Reply Br. 15-16. Thus, we disagree that one can include the
other. Second, the Examiner found that “in returning the result/result sets
[in the combined system of Balabine and Coram], a first hierarchical
container was located (and, thus, was attempted to be located).” Ans. 36.
The claims, however, recite attempting to locate a file “in” a first
hierarchical container, not attempting to locate the container itself. Reply
Br. 16-18.
Appeal 2010-002306
Application 10/702,259

18

Based on Appellants’ arguments and the Examiner’s reasons for
rejection, the essential issue with respect to claim 19 appears to be the
proper interpretation of “attempting to map.” Appellants contend that the
phrase means “attempt[ing] to identify a hierarchical container that contains
the requested flat identifier” where “the system does not have any clues as to
where to find the desired flat identifier.” App. Br. 32-33; Reply Br. 23
(“there is no hint” in advance). The Examiner appears to have interpreted
the phrase as not requiring the system to have no “clue” about where to find
the desired flat identifier, and found the attempt to map taught by the cited
prior art (i.e., even though the combined system of Balabine and Coram
would know the folder path in advance by virtue of Balabine’s request for a
specific file). Ans. 34-35.
We agree with the Examiner. The meaning of “attempting to map” is
not set forth in the broad language of claim 19 itself. The claim only
specifies that the cache does not contain a combination of the flat identifier
and locality of reference cue; it contains no definitive requirement as to what
is generally known or unknown in advance. Appellants do not point to any
persuasive evidence, such as an explicit definition in the Specification,
indicating that “attempting to map” requires certain information to be
unknown to the entire system. Thus, under its broadest reasonable
interpretation, the “attempting to map” feature of claim 19 simply
encompasses attempting to associate a flat identifier to a second hierarchical
container, and does not require that the system have no “clue” about where
to find the desired flat identifier in advance. See ICON, 496 F.3d at 1379;
Spec., pg. 10, ll. 12-17; pg. 12, 27-34 (a new “association” can be added to
the cache if the “mapping” is successful).
Appeal 2010-002306
Application 10/702,259

19

Given this interpretation, we agree with the Examiner that the
combination of Balabine and Coram teaches an attempt to map. See Ans.
12-13 (citing Balabine, col. 9, ll. 15-20, and Coram ¶ 37). When a request
occurs in Balabine, “the IXFS daemon initializes a filename look-up
procedure to identify the appropriate IXFS extension module 707 to handle
the request” where “[t]he filename specified by the request is used as an
index into a look-up table of corresponding IXFS extension modules.”
Balabine, col. 9, ll. 15-26 (emphases added). The extension module then
translates the request into a database operation, receives information back
from the database, and formats the information into “file system objects,”
which are shown on the user interface in a particular folder (displaying the
folder path). Balabine, col. 9, ll. 27-37, Fig. 5C. Thus, assuming the
Balabine/Coram cache did not contain what the user requested, the process
disclosed in Balabine constitutes mapping a flat identifier (i.e., a requested
file name) to a second hierarchical container (i.e., a folder). Based on the
record before us, we find that the preponderance of the evidence supports the
Examiner’s finding that the combination of Balabine and Coram teaches
“attempting to map the flat identifier to a second hierarchical container if the
cache does not contain the combination of the flat identifier and the locality
of reference cue,” and thus sustain the rejection of dependent claims 19, 21,
27, and 29.

B. Claims 7-10, 14, 20, and 28 (Balabine/Coram)
Appellants separately argue (1) claim 7, (2) claims 8 and 10, and (3)
claims 9, 14, 20, and 28. App. Br. 29-31; Reply Br. 25-26. We group these
claims together and deem claim 7 representative, as Appellants essentially
Appeal 2010-002306
Application 10/702,259

20

repeat their arguments addressed above with respect to the claimed “locality
of reference cue,” “identifier,” and three-way “association” (flat identifier,
locality of reference cue, and identifier of a first hierarchical container). For
the reasons stated above, we are not persuaded of error by the Examiner.
See supra, Section I.A.i-ii.

C. Claims 34 and 35 (Balabine/Coram)
Appellants argue claims 34 and 35 together as a group. App. Br. 36-
38; Reply Br. 26-29. We select claim 34 as representative.
The Examiner found that the combination of Balabine and Coram
teaches mapping a flat identifier to a plurality of hierarchical containers
because, as shown in Figure 5C of Balabine, a flat identifier (e.g.,
“Adams.txt”) is mapped to multiple folders (e.g., “x:\customer\name” and
“x:\customer\”). Ans. 13, 38-39. Appellants argue that a “folder itself might
be stored in another folder, but a person of ordinary skill in the art would not
describe [a] file as being stored in both folders.” App. Br. 36; Reply Br. 29.
We agree with the Examiner. Appellants have not pointed to any facts in
support of their characterization of how a skilled artisan would read
Balabine and claim 34. Nor is there anything in the claim as written
requiring that a flat identifier be associated with only one container. Given
the broadest reasonable interpretation of “attempting to map” explained
above, a flat identifier like “Adams.txt” can be considered associated with
both the “customer” and “name” folders. Accordingly, we sustain the
rejection of dependent claims 34 and 35.

Appeal 2010-002306
Application 10/702,259

21

D. Claims 36 and 37 (Balabine/Coram)
Appellants argue claims 36 and 37 together as a group. App. Br. 38-
39. We select claim 36 as representative.
Appellants refer to their arguments regarding the “attempting to map”
feature of claim 19. App. Br. 38-39. For the reasons stated above, we are
not persuaded of error by the Examiner. See supra, Section II.A.

E. Claims 3 and 4 (Balabine/Coram/Ryan)
Appellants argue claims 3 and 4 together as a group. App. Br. 44-45;
Reply Br. 31. We select claim 3 as representative.
Appellants argue that Ryan does not “combin[e] the user ID with
anything” and does not teach a “locality of reference cue.” See App. Br. 44-
45; Ryan, col. 20, ll. 2-3. Again, Appellants are responding to the rejection
by attacking Ryan individually, even though the rejection is based on the
combined teachings of the references. See Merck, 800 F.2d at 1097. The
Examiner found that Balabine and Coram teach combining a flat identifier
with a hierarchical container, as recited in claim 2, and Ryan teaches sorting
by user identification (ID) (neither of which are challenged by Appellants).
Ans. 17-18, 41-42. The Examiner further found reasons why a person of
ordinary skill in the art would use Ryan’s sorting procedure to sort the
combinations taught by Balabine and Coram by locality of reference cue
(i.e., user ID). Ans. 18; see Spec., pg. 8, ll. 10-12 (citing various “user”-
associated parameters as examples of a locality of reference cue).
Appellants’ arguments directed to Ryan individually do not persuade us of
error in this analysis.
Accordingly, we sustain the rejection of dependent claims 3 and 4.
Appeal 2010-002306
Application 10/702,259

22

F. Claims 22 and 30 (Balabine/Coram/Skopp)
Appellants argue claims 22 and 30 together as a group. App. Br. 45-
46; Reply Br. 32-33. We select claim 22 as representative.
Appellants argue that the invention recited in claim 22 “could” be
used to assist in authenticating a user “when the user logs in,” but Balabine,
Coram, and Skopp cannot do so because they require a user to be
authenticated before accessing a database, cache, etc. App. Br. 45-46. We
disagree with Appellants. The only portion of claim 22 referring to
authentication is the third element regarding the attempt to locate the file,
which we interpret to not be a requirement of the claim. See supra, Section
I.C. The combination of Balabine, Coram (receiving a user identifier), and
Skopp (receiving a password) teaches all of the remaining elements of claim
22, which is all that is required. Ans. 19-21, 42-44. Accordingly, we sustain
the rejection of dependent claims 22 and 30.

G. Claims 23 and 31 (Balabine/Coram/Skopp)
Appellants argue claims 23 and 31 together as a group. App. Br. 47-
48; Reply Br. 33-34. We select claim 23 as representative.
Appellants argue that Skopp’s IP address is not a “locality of
reference cue.” App. Br. 47. The Examiner relied on Coram for a teaching
of a locality of reference cue (i.e., the “client identifier”) and, because
Coram does not specify the exact content of its client identifier, relied on
Skopp for a teaching of a client identifier that is an IP address. Ans. 11, 20-
21, 44. Again, we are not persuaded by Appellants’ arguments challenging
the references individually, when the rejection is based on combined
Appeal 2010-002306
Application 10/702,259

23

teachings. See Merck, 800 F.2d at 1097. Coram need not specifically teach
an IP address for the combination of references to teach the claimed feature.
Accordingly, we sustain the rejection of dependent claims 23 and 31.
Finally, we note that dependent claims 2, 6, 12, 13, 38-41, 43-45, 47,
and 48, which were not separately argued by Appellants, fall with their
respective independent claims. We sustain the rejections of those claims
under 35 U.S.C. § 103(a) as well.

III. 35 U.S.C. § 112 Rejection of Dependent Claim 44
To satisfy the written description requirement, “the disclosure of the
application relied upon [must] reasonably convey[] to those skilled in the art
that the inventor had possession of the claimed subject matter as of the filing
date.” Ariad Pharm., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir.
2010).
Claim 44 recites that “the flat identifier includes a user identifier.”
The Examiner found support in the Specification for a flat identifier that “is”
a user identifier, but not a flat identifier that “includes” a user identifier, and
therefore rejected the claim as failing to comply with the written description
requirement. Ans. 3, 44-45; Advisory Action mailed January 29, 2009.
Appellants argue that “includes” is an open-ended term and the Specification
broadly discloses a number of examples of what the flat identifier may be,
including a user identifier (e.g., the name “Joe”) or something else like a file
identifier (e.g., the file name “File 1”). App. Br. 52; Reply Br. 34-35; see
also Spec, pg. 5, ll. 6-18 (the flat identifier “can vary” and “can be any
identifier, not just a user’s name”). We agree with Appellants that the
Specification reasonably conveyed to those skilled in the art that Appellants
Appeal 2010-002306
Application 10/702,259

24

were in possession of the invention using a flat identifier that is solely a user
identifier, or is a user identifier and something more. Accordingly, we do
not sustain the rejection of claim 44 under 35 U.S.C. § 112, first paragraph.

CONCLUSION
Appellants have persuaded us of error in the Examiner’s decision to
reject claim 44 under 35 U.S.C § 112, first paragraph, but have not
persuaded us of error in the Examiner’s decision to reject claims 1-4, 6-14,
18-23, 26-31, and 34-48 under 35 U.S.C § 103(a).5

DECISION
For the above reasons, the rejections of claims 1-4, 6-14, 18-23, 26-
31, and 34-48 under 35 U.S.C § 103(a) are affirmed, and the rejection of
claim 44 under 35 U.S.C § 112, first paragraph, is reversed. However,
because we have affirmed at least one ground of rejection with respect to
each claim on appeal, the Examiner’s decision is affirmed. See 37 C.F.R.
§ 41.50(a)(1).

5 We have decided the appeal before us. However, should there be further
prosecution of claims 26-31, 35, 37, and 41 directed to a “computer-readable
medium containing a program” comprising instances of “software,” the
Examiner’s attention is directed to 35 U.S.C. § 101 and U.S. Patent &
Trademark Office, Interim Guidance for Determining Subject Matter
Eligibility for Process Claims in View of Bilski v. Kappos, 75 Fed. Reg.
43,922 (July 27, 2010); David J. Kappos, Subject Matter Eligibility of
Computer Readable Media, 1351 Off. Gaz. Pat. Office 212 (Feb. 23, 2010);
and U.S. Patent & Trademark Office, Interim Examination Instructions for
Evaluating Subject Matter Eligibility Under 35 U.S.C. § 101, Aug. 24, 2009,
available at http://www.uspto.gov/web/offices/pac/dapp/opla/2009-08-
25_interim_101_instructions.pdf.
Appeal 2010-002306
Application 10/702,259

25

No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(1)(iv).

AFFIRMED

msc