International Business Machines Corporation

Patent Trials and Appeals Board

May 5, 2020

15149163 - (D) (P.T.A.B. May. 5, 2020)

UNITED STATES PATENT AND TRADEMARK OFFICE
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
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO.
15/149,163 05/08/2016 Nicolas Dangeville GB920120067US2_8150-0646 9692
73109 7590 05/05/2020
Cuenot, Forsythe & Kim, LLC
20283 State Road 7
Ste. 300
Boca Raton, FL 33498
EXAMINER
CHEN, QING
ART UNIT PAPER NUMBER
2191
NOTIFICATION DATE DELIVERY MODE
05/05/2020 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):
ibmptomail@iplawpro.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte NICOLAS DANGEVILLE and THIERRY MATUSIAK
____________

Appeal 2019-001951
Application 15/149,163
Technology Center 2100
____________

Before JOHN A. JEFFERY, JASON J. CHUNG, and BETH Z. SHAW,
Administrative Patent Judges.

JEFFERY, Administrative Patent Judge.

DECISION ON APPEAL
Under 35 U.S.C. § 134(a), Appellant1 appeals from the Examiner’s
decision to reject claims 21–40. We have jurisdiction under
35 U.S.C. § 6(b).
We AFFIRM.

1 We use the word “Appellant” to refer to “applicant” as defined in
37 C.F.R. § 1.42. Appellant identifies the real party in interest as IBM
Corporation. Appeal Br. 1.
Appeal 2019-001951
Application 15/149,163

2

STATEMENT OF THE CASE
Appellant’s invention locates software on a storage device by
searching for program code units identifying themselves as fragments of
particular software modules. See Spec ¶ 21. This identification allows
program units to be recognized as part of a software module fragment even
if the program units are renamed or relocated. See id. Claim 21 is
illustrative:
21. A computer-implemented method, comprising:
associating a label to a program code unit of a software
module to define a software module fragment;
generating, using a plurality of software module
fragments respectively associated with a plurality of different
program code units, a module fragment list that defines the
software module;
receiving a request to retrieve the program code units
from a data storage device;
converting, based upon the received request and using
labels associated with the program code units, the module
fragment list into a list of physical locations, wherein the list of
physical locations correspond to locations of the program code
units within the data storage device.

THE REJECTIONS
1. The Examiner rejected claims 21, 22, 25, 28, 29, 32, 35, 36, and 39
under 35 U.S.C. § 102(a)(1) as anticipated by Thurgood (US 2009/0288093
Al; published Nov. 19, 2009). Final Act. 3–8.2

2 Throughout this opinion, we refer to (1) the Final Rejection mailed April 9,
2018 (“Final Act.”); (2) the Appeal Brief filed August 30, 2018 (“Appeal
Br.”); (3) the Examiner’s Answer mailed November 2, 2018 (“Ans.”); and
(4) the Reply Brief filed January 2, 2019 (“Reply Br.”).
Appeal 2019-001951
Application 15/149,163

3
2. The Examiner rejected claims 23, 24, 30, 31, 37, and 38 under
35 U.S.C. § 103 as unpatentable over Thurgood and Smith (US
2006/0026573 Al; published Feb. 2, 2006). Final Act. 8–10.
3. The Examiner rejected claims 26, 33, and 40 under 35 U.S.C.
§ 103 as unpatentable over Thurgood and Goodman (US 2006/0059253 A1;
published Mar. 16, 2006). Final Act. 10–11.
4. The Examiner rejected claims 27 and 34 under 35 U.S.C. § 103 as
unpatentable over Thurgood and Ben-Itzhak (US 2013/0227544 Al;
published Aug. 29, 2013). Final Act. 11–12.

THE ANTICIPATION REJECTION
The Examiner finds that Thurgood discloses every recited element of
claim 21. Final Act. 4–6. According to the Examiner, Thurgood’s file
discloses a “program code unit of a software module” because each file
defines a resource that is part of a larger “software development
collaborative environment” (i.e., a project). See Final Act. 4, 13–14. The
Examiner further finds Thurgood’s index discloses “a module fragment list
that defines the software module” because the index maps each key to each
file and thus represents a list. Final Act. 4–5, 15–16. The Examiner further
finds Thurgood’s processing environment discloses the recited “storage
device.” Final Act. 6. The Examiner further finds Thurgood’s application
accessing a resource using a provided location discloses “receiving a request
to retrieve the program code units.” Final Act. 5–6, 17–19. The Examiner
adds that Thurgood’s resolving the list of keys into location values discloses
“converting . . . the module fragment list into a list of physical locations.”
Final Act. 6, 19–20.
Appeal 2019-001951
Application 15/149,163

4
Appellant argues Thurgood fails to disclose “associating a label to a
program code unit of a software module to define a software module
fragment.” Appeal Br. 9–13. Appellant argues that Thurgood’s resource is
not a software module because the resource is a “complete software module”
(id. 10), and adds that “resource” is inconsistent with the plain meaning of
“software module fragment.” Id. 11. Appellant also argues that Thurgood’s
file fails to represent a software module or a software module fragment. Id.
12–13.
Appellant further argues Thurgood fails to disclose “generating, using
a plurality of software module fragments respectively associated with a
plurality of different program code units, a module fragment list that defines
the software module.” Appeal Br. 13–16. Appellant further argues a
resource’s current location taught in Thurgood fails to disclose a list of
fragments. Id. 13. Appellant further argues Thurgood’s project is “not a
software module that is defined a module fragment list.” Id. Appellant
further argues that Thurgood’s index fails to disclose a list because it “maps
a key to a current location (of the resource).” Id. 13. Appellant adds that
Thurgood’s index fails to define a software module. Id. 13–15.
Appellant also argues Thurgood fails to disclose “converting, based
upon the received request and using labels associated with the program code
units, the module fragment list into a list of physical locations.” Appeal Br.
15–16. According to Appellant, Thurgood’s index fails to disclose the
recited “module fragment list” because it already teaches the recited “list of
physical locations”—a different claim term with a different meaning. See id
15–16.
Appeal 2019-001951
Application 15/149,163

5
Appellant also argues Thurgood fails to disclose “receiving a request
to retrieve the program code units from a data storage device.” Appeal Br.
16–19. Appellant argues Thurgood’s project fails to disclose “program code
units.” Id. 16. Appellant adds that physical processing devices fail to
disclose a data storage device. Id. 16, 18. Appellant further argues
Thurgood fails to disclose “program code units” and “data storage device” as
they are arranged in claim 21. Id. 17. Appellant further argues Thurgood’s
software resource (i.e., a service, application, or system) fails to disclose a
fragment of software module. Id. 18. Appellant further argues that
Thurgood discloses returning locations associated with keys rather than
“retrieving program code units.” See id.
Appellant also argues that Thurgood fails to disclose “converting,
based upon the received request and using labels associated with the
program code units, the module fragment list into a list of physical
locations.” Appeal Br. 19–21. Appellant argues that Thurgood fails to
disclose converting the module fragment list into a list of physical locations
because Thurgood fails to disclose that that its index is converted. Id. 20.
Appellant further argues that using Thurgood’s key to return a location using
the index is a “basic database operation” that is not a conversion. Id. 21.

ISSUE
Under § 102, has the Examiner erred in rejecting claim 21 by finding
that Thurgood discloses (1) “associating a label to a program code unit of a
software module to define a software module fragment”; (2) “generating,
using a plurality of software module fragments respectively associated with
a plurality of different program code units, a module fragment list that
Appeal 2019-001951
Application 15/149,163

6
defines the software module”; (3) “receiving a request to retrieve the
program code units from a data storage device”; and (4) “converting, based
upon the received request and using labels associated with the program code
units, the module fragment list into a list of physical locations” as recited in
claim 21?

ANALYSIS
We begin by clarifying the Examiner’s mapping. As shown in the
partial detail view of Thurgood’s Figure 2 reproduced below, the figure
includes elements that are illustrative of the Examiner’s mapping of claim
21. See Final Act. 4–6 (citing various elements of Figure 2).

Appeal 2019-001951
Application 15/149,163

7

Partial detail view of Thurgood’s Figure 2 displaying elements 210
through 260 as a flow chart

The first element of claim 21 recites “associating a label to a program
code unit of a software module to define a software module fragment.” The
Examiner maps Thurgood’s key to the recited label. See Final Act. 4; Ans.
Appeal 2019-001951
Application 15/149,163

8
14 (referring to Thurgood’s key as a label, and citing Figure 2 element 231).
We see no error in this finding. The key is a label because it identifies
(labels) the resource (i.e., program code unit) via the file name. See
Thurgood ¶ 0042; Fig. 2 element 231.
The Examiner maps Thurgood’s file-based resource to the recited
“program code unit of a software module.” Final Act. 4. We see no error in
this finding. As Thurgood explains in paragraph 10, a file is a “resource.”
This file-based resource is reasonably construed as a “program code unit”
because it represents program code that is part of a larger software project
that includes stages, each with multiple resources—resources that are files as
noted above. See Thurgood ¶¶ 10–11; Fig. 2 element 210 (indicating that a
project is loaded and includes multiple resources); ¶ 10 (disclosing that a
resource includes software resources with instructions executable on a
computer).3
The Examiner also appears to map Thurgood’s project to the recited
“software module.” See Final Act. 4 (quoting Thurgood’s paragraph 44
disclosing “[a]t 240 the resource location management service records a
current location (at the time of the initial and first load of the project for each
resource of the project)”); Ans. 13–14 (indicating Thurgood discloses “a
software development collaborative environment containing multiple
files.”). See also Thurgood Fig. 2 (element 210).

3 We also note that Thurgood’s resource is also consistent with “program
code unit” as characterized in the Specification. See Spec. ¶ 40 (disclosing
“a program code unit is a building block of a software module fragment, and
is a unit of information that can be processed in a transformation process”).
Appeal 2019-001951
Application 15/149,163

9
We see no error in these findings. First, the term “software module”
is not defined explicitly in the Specification,4 unlike other terms which,
while broad, are defined explicitly. See, e.g., Spec. ¶¶ 39, 40 (defining
“software module fragment” as “a building block of a software module” and
defining “program code unit” as “a building block of a software module
fragment, and is a unit of information that can be processed in a
transformation process”). Thus, we interpret the term “software module”
with its plain meaning consistent with the Specification. See In re Am.
Acad. of Sci. Tech. Ctr., 367 F.3d 1359, 1364 (Fed. Cir. 2004); see also
Manual of Patent Examining Procedure (MPEP) § 2111.01 (9th ed. Rev.
08.2017, Jan. 2018). We construe the term “software module”5 consistent
with the ordinary and customary meaning of the term “module” in the
computer art, namely “[i]n programming, a collection of routines and data
structures that performs a particular task or implements a particular abstract

4 The Specification notes that “[a] software module may be a software
application as defined in a software project, such as a software-based service
or a collection of such services, a holistic user application, a message-
oriented application and so on. A software module may be defined by one
or more fragments, which may be defined in a particular order . . . .”
(emphasis added)). Spec. ¶ 38. The permissive term “may be” indicates that
this description does not limit the term “software module” to any particular
definition.
5 In the Appeal Brief, the Appellant provides a definition of “software
module.” Appeal Br. 11. We do not adopt this definition. Although
Appellant’s cited definition suggests that a module refers to part of an
application, the Specification suggests that a module can refer to an entire
application. Compare Appeal Br. 11 (indicating that a module “implies a
single executable file that is only a part of the application” (emphasis
added)) with Spec ¶ 38 (indicating that a module “may be a software
application as defined in a software project” (emphasis added)).

Appeal 2019-001951
Application 15/149,163

10
data type.” MICROSOFT COMPUTER DICTIONARY 437 (5th ed. 2002)
(defining “module”).
Given this definition, we see no error in the Examiner’s reliance on
Thurgood’s project for disclosing the recited “software module.” Notably,
Thurgood’s project is (1) loaded as software (see Thurgood Fig. 2 element
210 and ¶ 39); (2) performs operations (see Thurgood ¶ 10); and (3) is
“represented and electronically defined as a series of stages. . .” with “[e]ach
stage includ[ing] its own processing environment [and] having its own or
shared resources” (see Thurgood ¶ 11). Therefore, Thurgood’s project fully
meets a “software module” because the project is software that is a
collection of routines (i.e., stages) and data structures that perform a
particular task (i.e., one or more operations).
Appellant’s contention that Thurgood’s project is not interchangeable
with the term “application” (Reply Br. 5) is, at best, overstated given
Thurgood’s associated disclosure. Not only can a project can be viewed as a
type of resource in Thurgood’s paragraph 11, a resource is also an
application as noted in paragraph 10.
The Examiner also maps Thurgood’s file to the recited “software
module fragment.” See Final Act. 14. We see no error in this finding. Each
file in Thurgood identifies and defines a resource included in a project. See
Thurgood ¶ 40 (disclosing files are scanned to identify resources in the
project); ¶ 42 (disclosing a file defining a resource). Thus, each file in
Thurgood is part of an overall project (i.e., software module). Accord Ans.
14 (indicating that Thurgood’s file is “something less than the whole of the
software resource which contains multiple files”). Thurgood’s file defines a
software module fragment because it defines a part (i.e., fragment) of what is
Appeal 2019-001951
Application 15/149,163

11
in the project (i.e., module). See Thurgood ¶¶ 40, 42. Thus, we see no error
in the Examiner’s findings in this regard.
Appellant argues (1) Thurgood’s resource discloses a “complete
software module,” and thus fails to teach a “software module fragment” (see
Appeal Br. 10); and (2) Thurgood’s resource does not represent something
“less than the whole.” See Appeal Br. 11. These arguments are
unpersuasive. As indicated above, the file in Thurgood defines a software
module fragment because it defines a part (i.e., fragment) of what is in the
project (i.e., module). See Thurgood ¶¶ 40, 42.
Appellant further argues “program code unit” and “software module
fragment” must be construed using Appellant’s proffered definition of
“software module.” See Appeal Br. 11. As noted above, we decline to
adopt this definition because the terms are not so limited, particularly in light
of the permissive and open-ended descriptions in the Specification. See
Spec. ¶ 38 (indicating that a software module “may be a software
application as defined in a software project” (emphasis added)); see also id.
¶ 39 (broadly characterizing “software module fragment” as a “building
block of a software module”). Thus, this argument is also unpersuasive.
Appellant’s argument that Thurgood discloses only one file per
resource (see Appeal Br. 12), and thus ostensibly implies a “one-to-one
correspondence between a file and a resource” (see id.), is also unpersuasive.
Thurgood’s project includes multiple resources. See Thurgood Fig. 2
(elements 210, 220). Thus, even if a resource were confined to one file,
Thurgood nevertheless discloses the claimed relationships between the
software module, software module fragment, and program code unit
because, among other things, the project (i.e., software module) contains
Appeal 2019-001951
Application 15/149,163

12
multiple resources (program code units). See Thurgood Fig. 2 (elements
210, 220).
Appellant’s contention that Thurgood’s file fails to disclose a software
module fragment (Appeal Br. 12–13) is also unavailing. Thurgood’s file
defines a resource which is part of a project. See Thurgood Fig. 2 element
210; ¶¶ 40, 42. The term “software module fragment,” when read broadly
but reasonably in light of the Specification, merely requires that the
fragment is “a building block of a software module.” Spec. ¶ 39.
Thurgood’s file is a building block of the software module (i.e., project)
because it defines a project’s resource. See Thurgood Fig. 2 (element 210);
¶¶ 40, 42.
We now address the Examiner’s mapping of the second element of
claim 21, reproduced below:
generating, using a plurality of software module fragments
respectively associated with a plurality of different program
code units, a module fragment list that defines the software
module.

The Examiner maps Thurgood’s production of an index to the recited
generating element. See Final Act 4–5; Ans. 16–17. We see no error in this
finding. Thurgood’s index is generated using the location of resources and a
key for each resource. See Thurgood Fig. 2 (elements 240–260). Thus, the
index is generated using files (i.e., software module fragments), and each file
is associated with a different resource (program code unit). See Thurgood
¶¶ 40, 45. Thurgood’s index is a list that defines a project because the index
represents the project’s (i.e., software module’s) component parts. See
Thurgood ¶¶ 39, 44, 45 (disclosing a produced index that includes a
project’s resources and keys to those resources).
Appeal 2019-001951
Application 15/149,163

13
Appellant’s contention that Thurgood’s “current location is not a list
of fragments” (Appeal Br. 13) is unavailing. As indicated above, we agree
with the Examiner’s finding that Thurgood’s index discloses the recited
module fragment list. See Final Act 4–5; Ans. 16–17.
Appellant’s contention that Thurgood’s project is not a software
module that defines a module fragment list (Appeal Br. 13) is likewise
unavailing. As indicated above, Thurgood’s project is a “software module”
when construed under its plain meaning consistent with the Specification.
Also as indicated above, Thurgood’s index discloses the recited list of
software fragments that define the software module because the index
represents the project’s (i.e., software module’s) component parts. See
Thurgood ¶¶ 39, 44, 45.
Appellant further argues the following:
(1) Thurgood’s index is not a list (Appeal Br. 13);
(2) the index does not define a software module as claimed (see id.
13–15); and
(3) “the Examiner has committed reversible error by ignoring that the
module fragment list defines the software module” (id. 14). These
arguments are likewise unpersuasive. As indicated above, we agree with the
Examiner that Thurgood’s index is a list of module fragments because the
index contains ordered, listed items. See Ans. 17. The index defines the
software module because it contains the component parts of the project. See
Thurgood ¶¶ 39, 44, 45 (disclosing a produced index that includes a
project’s resources and keys to those resources).
Appellant presents the following additional arguments:
Appeal 2019-001951
Application 15/149,163

14
[T]he Examiner’s analysis fails to appreciate that the claimed
invention subsequently recites “converting, based upon the
received request and using labels associated with the program
code units, the module fragment list into a list of physical
locations.” To the extent that the “index” of Thurgood “defines
a current location for a resource within a project,” as alleged by
the Examiner, then this corresponds to the claimed “a list of
physical locations.”

The general assumption is that different terms have different
meanings. Applied Medical Resources Corp. v. United States
Surgical Corp., 448 F.3d 1324, 1333 n.3 (Fed. Cir. 2006).
Consequently, the claimed “module fragment list” must be
construed as having a different meaning than the claimed “list
of physical locations.”

However, the Examiner’s claim construction and reliance upon
the “index” of Thurgood to teach the limitations at issue
improperly fails to distinguish between these two claimed
limitations (i.e., the “module fragment list” and the “list of
physical locations”).

Appeal Br. 15–16.
These arguments are unpersuasive. The index (i.e., the recited
“module fragment list”) refers to a key and a location of the resource. See
Thurgood ¶ 45. The recited “list of physical locations” are the locations
returned to the application as result of the resolving (i.e., converting) the key
using the index. See id. ¶¶ 69–70. Thus, the index (i.e. module fragment
list) and the list of physical locations are different terms with different
meanings.
We now address the Examiner’s mapping of the third element of
claim 21, namely, “receiving a request to retrieve the program code units
from a data storage device.” The Examiner maps Thurgood’s processing of
Appeal 2019-001951
Application 15/149,163

15
references in paragraph 70 to the recited claim language. See Final Act. 5–6.
We see no error in this finding. On this record, we agree with the Examiner
that an application using a location to access a resource discloses the
application retrieving the resource using the location. See Ans. 20–21.
Appellant’s argument that Thurgood’s project does not disclose
program code units (Appeal Br. 16) is unpersuasive. As indicated above,
Thurgood’s project is made up of resources (see Thurgood Fig. 2 element
210) which disclose “program code units” when this term is read broadly,
but reasonably, in light of the Specification.
Appellant’s argument that physical processing devices do not
necessarily disclose a data store device (Appeal Br. 16) is likewise
unpersuasive. We agree with the Examiner that computers inherently have
storage devices. See Ans. 19–20.
Appellant further argues the following:
The Examiner attempts to cure the deficiencies of Thurgood by
alleging that Thurgood teaches both the claimed “the program
code units” and “a data storage device.” However, under
32 U.S.C. § 102, not only must a prior art reference disclose all
elements within a claim, the prior art reference must also
disclose those elements “arranged as in the claim.” In this
instance, the Examiner's citation to a “computer-readable
storage medium” may identically disclose a “data storage
device.” However, the Examiner’s cited paragraph [0062]
merely states that the “project resource location resolution
system 400 is implemented as instructions on or within a . . .
computer- readable storage medium.” Notably, this teaches
nothing regarding the claimed “receiving a request to retrieve
the program code units from a data storage device . . . . Finally,
the Examiner presents no evidence that a processing device
inherently discloses a storage device, as claimed.

Appeal 2019-001951
Application 15/149,163

16
Appeal Br. 17–18 (underlining omitted). These arguments are unpersuasive.
With respect to the recited requesting, as indicated above, an application
using a location to access a resource necessarily discloses the application
retrieving the resource using the location. See Ans. 20–21 (citing Thurgood
¶ 70). With respect to storage devices, Thurgood’s paragraph 62 discloses a
“computer readable storage medium” (i.e., a storage device) that is part of a
computer (i.e., processing device).
Appellant further argues the following:
Additionally, the Examiner refers to a passage that describes a
service, application, and system as types of a “software
resource.” While software may include program code units, the
claimed program code units [are] respectively associated with a
plurality of software module fragments. Notably, none of a
service, application, or system are a fragment of a software
module. Accordingly, they cannot teach the claimed program
code units.

Appeal Br. 18. These arguments are likewise unpersuasive. The application
in Thurgood access and retrieves resources (i.e., program code units) based
on their location. See Thurgood ¶¶ 69–70. As indicated above, the
resources are associated with files (i.e., the recited “software module
fragments”). See id. ¶¶ 40, 42.
Appellant further argues “what is presumably being requested by the
teachings of Thurgood is to retrieve the locations associated with the keys.
Retrieving locations is not the same as retrieving program code units.”
Appeal Br. 18. This argument is unpersuasive. Using a location to access a
resource necessarily retrieves the resource when read in light of Thurgood’s
remaining disclosure. See, e.g., Thurgood ¶ 34 (noting that “the code just
passes the key into the resource location resolution service, which resolves
Appeal 2019-001951
Application 15/149,163

17
the key to a real full path where it can be successfully loaded”) (emphasis
added).
We now address the Examiner’s mapping of the fourth element of
claim 21 reproduced below:
converting, based upon the received request and using labels
associated with the program code units, the module fragment
list into a list of physical locations, wherein the list of physical
locations correspond to locations of the program code units
within the data storage device.

The Examiner maps Thurgood’s resolving the list of keys in the index
to the list of location values to the recited module fragment list conversion.
See Final Act 6, 20; Ans. 22. We see no error in this finding. Thurgood
discloses an application requesting a resource and receiving the resource’s
location responsive to that request. See Thurgood ¶¶ 46, 69, 70. The index
is converted in that each label or key is converted into a corresponding
location from the perspective of the requesting application.
An exemplary application of Thurgood’s process in steps 230 to 260
in Figure 2 illustrates this point. As shown in the table below, a key is
generated for each resource, “File 1” and “File 2” in this example, according
to step 230 of Thurgood’s Figure 2:

Resource Key
File 1 A
File 2 B

Table 1: Exemplary Resources and Associated Generated Keys

Appeal 2019-001951
Application 15/149,163

18
Then, in step 240, a current location is recorded for each resource:

Resource Location
File 1 Location 1
File 2 Location 2

Table 2: Exemplary Resources and Associated Locations

Then, in step 250, an index is produced that maps each key to its
corresponding location:

Key Location
A Location 1
B Location 2

Table 3: Exemplary Keys and Associated Locations

In this example, after resources “File 1” and “File 2” are requested,
their associated keys, A and B, are used to return the corresponding
locations, namely “Location 1” and “Location 2,” according to the procedure
in Thurgood’s steps 250 and 260 in Figure 2. See Thurgood ¶¶ 45–46.
Thus, the index, or “module fragment list,” is effectively converted when
each key is resolved into a location6:

6 We also note that Thurgood teaches an index’s conversion in Figure 2
elements 270 (“updat[ing] the index with new current locations for some of
the resources that were moved since the initial load within the project”); and
Appeal 2019-001951
Application 15/149,163

19
Locations
Location 1
Location 2

Table 4: Exemplary Locations

Appellant argues Thurgood fails to disclose a conversion of the
module fragment list because Thurgood’s index is not converted. See
Appeal Br. 20. This argument is unpersuasive because, as noted above, the
index is converted from the requesting application’s perspective in that the
key is converted into a location that is returned. See Thurgood ¶¶ 46; Fig. 2
(step 270). In short, Appellant’s argument is not commensurate with the
scope of the claim.
Appellant further argues Thurgood’s index is not converted into a list
of physical locations. Appeal Br. 20. This argument is also unpersuasive
because Thurgood’s locations are file path locations—i.e. physical locations
of files. See Thurgood ¶¶ 5, 34.
Appellant further contends that using a table to return a location is a
“basic database operation” and does not involve converting the index.
Appeal Br. 20. This argument is not persuasive. Appellant’s Specification
does not define of the term “converting” explicitly. The Specification does,
however, inform our understanding on how the term is used. On page two
of the Appeal Brief, Appellant cites the following passage as support for the
converting limitation:

272 (“using the corresponding keys to update the index with new current
locations for those resources”).
Appeal 2019-001951
Application 15/149,163

20
In step 430, for each logical search fragment 212, the program
code units, e.g., folders 206 or source code files, which have a
label referring to the logical search fragment 212, are located on
the digital data storage, such that the logical search path
fragment 212 can be converted into a software module fragment
comprising a list of physical locations or search paths of its
program code units in step 440.
Spec ¶ 58.
This passage suggests that the recited converting requires nothing
more than a database-like operation of returning data (i.e., a location) based
on an input (i.e., a label). Other portions of the Specification support this
interpretation. See id. ¶ 26 (“The conversion step may include searching the
digital data storage for program code units relating to the software module
based on said labels as previously explained.”) (emphases added); Abstract
(noting that the invention includes “converting, using a processor, the
module fragment list of the specified module into a list of physical locations
for resolving the locations of the corresponding program code units on the
digital data storage using said labels”) (emphases added). Thus, Appellant’s
contention that Thurgood is deficient because it discloses a “basic database
operation” is not persuasive because the recited “converting,” when read
broadly, but reasonably, in light of the Specification, includes a similar
database-like operation.
Appellant further argues Thurgood’s index is “a table that maps a key
to a location” and “when the resource location resolution service receives a
key, the resource location resolution service uses the table to return the
location.” Appeal Br. 21. According to Appellant, “[t]his is a very basic
database operation, and nothing about this involves the converting of the
index into something else.” Id. This argument is unpersuasive. As
Appeal 2019-001951
Application 15/149,163

21
indicated above, Thurgood’s index is converted from the perspective of the
requesting application (see Thurgood ¶¶ 68–69), and the Examiner’s
mapping of the recited converting is reasonable when the term is construed
broadly, but reasonably, in light of the Specification. See Spec.
¶¶ 26, 58.
Appellant also argues that converting means “to change from one
form or function to another.” Reply Br. 8. Although Appellant quotes this
apparent definition, there is no authority cited to substantiate its source. See
id. Nevertheless, we decline to adopt this uncited definition, for nothing on
this record precludes a broader reasonable definition based on other sources
supporting the agency’s interpretation. See, e.g., In re Morris, 127 F.3d
1048, 1056 (Fed. Cir. 1997) (“Absent an express definition in their
specification, the fact that appellants can point to definitions or usages that
conform to their interpretation does not make the PTO’s definition
unreasonable when the PTO can point to other sources that support its
interpretation.”).
The ordinary and customary meaning of “convert” in the computing
arts is “[t]o change the representation of data from one form to another.”
IEEE 100: THE AUTHORITATIVE DICTIONARY OF IEEE STANDARDS TERMS
238 (7th ed. 2000). From the requesting application’s perspective,
Thurgood’s index is converted in that each key in the index is changed into a
different form—a location. Thus, Thurgood discloses the recited conversion
under the term’s plain meaning consistent with the Specification. And even
under Appellant’s uncited definition, Thurgood still anticipates the recited
conversion since the key’s form is changed from an identifier to a location.
See Thurgood ¶¶ 35, 67, 69.
Appeal 2019-001951
Application 15/149,163

22
Therefore, we are not persuaded that the Examiner erred in rejecting
claim 21, and claims 22, 25, 28, 29, 32, 35, 36, and 39 not argued separately
with particularity.

THE OBVIOUSNESS REJECTIONS
We also sustain the Examiner’s obviousness rejections of claims 23,
24, 26, 27, 30, 31, 33, 34, 37, 38, and 40. Final Act. 8–12. Despite
nominally arguing these claims separately, Appellant reiterates similar
arguments made in connection with claim 21, and alleges that the additional
cited prior art fails to cure those purported deficiencies. Appeal Br. 21–23.
We are not persuaded by these arguments for the reasons previously
discussed.

CONCLUSION
In summary:
Claims
Rejected
35 U.S.C. § Reference(s)/
Basis
Affirmed Reversed
21–22, 25,
28–29, 32,
35–36, 39
102(a)(1) Thurgood 21, 22, 25, 28, 29,
32, 35, 36, 39

23–24, 30–
31, 37–38
103 Thurgood,
Smith
23, 24, 30, 31, 37,
38

26, 33, 40 103 Thurgood,
Goodman
26, 33, 40
27, 34 103 Thurgood,
Ben-Itzhak
27, 34
Overall
Outcome
21–40

Appeal 2019-001951
Application 15/149,163

23
TIME PERIOD FOR RESPONSE
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).

AFFIRMED