Ex Parte Bhatia et al

Patent Trial and Appeal Board

Jul 21, 2014

11369792 (P.T.A.B. Jul. 21, 2014)

UNITED STATES PATENT AND TRADEMARK OFFICE
___________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
___________

Ex parte RISHI BHATIA, MATTHEW J. SCHULZE,
JOHN M. TOMASZEWSKI, ROBERT B. KITTREDGE, and
DAVANUM SRINIVAS
___________

Appeal 2011-009491
Application 11/369,7921
Technology Center 2100
___________

Before ANTON W. FETTING, MICHAEL W. KIM, and
NINA L. MEDLOCK, Administrative Patent Judges.

FETTING, Administrative Patent Judge.

DECISION ON APPEAL

STATEMENT OF THE CASE2

1 The real party in interest is Computer Associates Think, Inc. App. Br. 2.
2 Our decision will make reference to the Appellants’ Appeal Brief (“App.
Br.,” filed December 20, 2010) and Reply Brief (“Reply Br.,” filed May 18,
2011), and the Examiner’s Answer (“Ans.,” mailed March 18, 2011).
Rishi Bhatia, Matthew J. Schulze, John M. Tomaszewski, Robert B.
Kittredge, and Davanum Srinivas (Appellants) seek review under
35 U.S.C. § 134 of the final rejection of claims 1, 3–6, 8–15, and 17–24. We
have jurisdiction over the appeal pursuant to 35 U.S.C. § 6(b).
Appeal 2011-009491
Application 11/369,792

2
The Appellants’ invention relates generally to the field of data
transformation and in particular to providing data transformation
functionality as a web service (Spec. 3:2–4).
An understanding of the invention can be derived from a reading of
exemplary claim 1, which is reproduced below (bracketed matter and some
paragraphing added).
1. A method of transforming data, comprising:
[1] receiving
an input format
defining
a format for an input object
associated with
a transformation,
the input format comprising
at least one main element
and
a plurality of repeating elements;
[2] receiving
an output format
defining
a format for an output object
associated with
the transformation,
the output format comprises
a target data definition
and
a repeating element definition;
[3] receiving
information
defining
a mapping
between
elements in the input format
and
elements in the output format;
Appeal 2011-009491
Application 11/369,792

3
[4] generating,
based on the mapping,
a script
operable when executed to
implement the transformation,
the script comprising
at least one loop
for the plurality of repeating elements;
[5] storing
the script;
[6] receiving,
over a network,
a service request
from a remote client,
the service request
invoking a web service,
wherein the service request
requests a particular one of a plurality of transformations
associated with one of a plurality of stored scripts
and
identifies a request data object;
[7] identifying,
based on
a name of the request data object,
a particular stored script
that performs the requested transformation;
[8] generating
a response data object
by executing the identified script
on the request data object; and
[9] transmitting,
over the network,
the response data object to the remote client.

The Examiner relies upon the following prior art:
Oppenheim US 5,734,905 Mar. 31, 1998
Colon US 5,991,731 Nov. 23, 1999
Appeal 2011-009491
Application 11/369,792

4
Darugar US 2003/0018661 A1 Jan. 23, 2003
Mital US 2005/0182772 A1 Aug. 18, 2005
Hayward US 2005/0251812 A1 Nov. 10, 2005
Claims 1, 4, 8–13, 17, 18, 20, 22, and 24 stand rejected under
35 U.S.C § 103(a) as unpatentable over Darugar, Hayward, and Mital.
Claims 3, 5, 6, 14, and 15 stand rejected under 35 U.S.C § 103(a) as
unpatentable over Darugar, Hayward, Mital, and Oppenheim.
Claim 19 stands rejected under 35 U.S.C § 103(a) as unpatentable
over Darugar, Hayward, Mital, and Colon.
ISSUES
The first issue of obviousness turns primarily on whether the
combination of Darugar, Hayward, and Mital describes or suggests
“receiving, over a network, a service request . . . request[ing] a particular
one of a plurality of transformations associated with one of a plurality of
stored scripts and identif[ying] a request data object,” as recited in
independent claim 1, and whether Hayward teaches away from the
Examiner’s asserted combination.
The second issue of obviousness turns primarily on whether the
combination of Darugar, Hayward, Mital, and Oppenheim describes or
suggests the subject matter of dependent claims 3, 5, 6, 14, and 15.
The third issue of obviousness turns primarily on whether the
combination of Darugar, Hayward, Mital, and Colon describes or suggests
the subject matter of claim 19.
FACTS PERTINENT TO THE ISSUES
The following enumerated Findings of Fact (FF) are believed to be
supported by a preponderance of the evidence.
Appeal 2011-009491
Application 11/369,792

5
Facts Related to Claim Construction
01. The disclosure contains no lexicographic definition of the term
“script.”
02. The Authoritative Dictionary of IEEE Standards defines a
“script” as “[a] text-formatting language in which formatting commands are
embedded in the text, then processed into a formatted document.”3
Facts Related to the Prior Art
Hayward
03. Hayward is directed to a data conversion system which includes
an extraction module that forms extracted data by extracting source data
from a data source and a conversion module that utilizes the extracted data
and performs a data conversion process on the extracted data to form
converted data that is adapted to the data target. Hayward ¶ 17.
04. Hayward describes that there are known portable data
conversion tools which automate portions of the conversion process, but
points out that “most of these tools use proprietary scripting languages that
are interpreted. This results in a slow execution. When handling very large
conversions, using the tools instead of hard-coding may result in extra days
of downtime processing that may result in downtime costs in the millions of
dollars.” Hayward ¶ 8.
05. Hayward describes a data conversion where source data are
evaluated to determine structure and contents in order to develop an

3 Script Definition. The Authoritative Dictionary of IEEE Standards Terms,
Seventh Edition, (2000).
Appeal 2011-009491
Application 11/369,792

6
understanding of how the source data are structured and how it may be
extracted and/or used. Hayward ¶ 64.
06. Hayward describes that the structure and contents of the source
data should be compared to the target to determine what steps may need to
be performed to transform/clean the source data sufficiently to properly
prepare it for insertion into the target. Hayward ¶ 65.
07. Hayward describes that the “conversion process should be
configured 440 according to determined conversion needs. The tools used
should be adapted for use with the source and target and prepared to perform
the steps needed to convert the data. Then the process should be
defined/revised 450 according to the configuration and any previous
conversion results.” Hayward ¶ 66.
08. Hayward further describes that “[w]hen converting, the Data
Duplicator module 800 may be configured to read each file only once,
stepping through each of the objects, preferably disposed in a hierarchy 900.
Thereby conversion speed and efficiency may be enhanced.” Hayward ¶
137.
09. Hayward describes that “Integration Objects 842 may be
configured to perform one or more conversion steps. The Integration
Object(s) 742 [sic, 842] may be configured to be managed by a module, such
as but not limited to a Data Duplicator module 800. The Integration Objects
842 may be stored and streamed in binary, thereby providing enhanced
speed and efficiency.” Hayward ¶ 93.
10. Hayward describes
[d]ata Duplicator module 800 may be used to manage
conversion of data from a source 210 (see FIG. 2) to a target
220 (see FIG. 2). Also, the Data Duplicator module 800 may
Appeal 2011-009491
Application 11/369,792

7
be used to build, test, and cause to be executed steps of data
conversion 200 (see FIG. 2). More, the Data Duplicator
module 800 may be written in machine language/binary for the
purpose of greatly enhancing speed and efficiency.
Additionally, the Data Duplicator module 800 may function as
a management module, organizing and directing the steps
required to convert data from a source 210 to a target 220.
Hayward ¶ 81.
11. Hayward describes
[d]ata Duplicator module 800 may create, manage, and control
Integration Objects 842, described in more detail later in the
specification. There may also be included the ability to call and
control other modules, such as Data Get/Put 810 (see FIG. 7),
Data Parse 820 (see FIG. 7), and Data Cleanse 830 (see FIG. 7).
Further, there may be included the ability to call and control
other files including but not limited to file types EXE, DLL,
Active X Controls, OCX, Service, Scripts, and ODBC (SQL
Server, Oracle, My SQL, Access, stored procedures, macros,
other features provided by an ODBC manufacturer, etc.).
Hayward ¶ 82.
12. Hayward describes
[a] process may be configured to be compiled into a process
DLL. The process DLL may be configured to be called as an
external procedure from a database. The process DLL may be
configured to accept parameters defining which process or
which portion of which process to run. The process DLL may
be configured to accept a key by which to filter selects. For
example, a trigger on a person table could call an update script
that would select only that person from a source database 210
and update information in a target database 220 on another
machine.
Hayward ¶ 87.
Appeal 2011-009491
Application 11/369,792

8
Mital
13. Mital is directed to a streaming conversion from a first data
structure to a second data structure. Mital describes that “a document
conversion file is received that converts data in the first data structure to data
in the second data structure. Next, a repeating structure definition is
received. The document conversion file is executed. Then each instance of
a repeating structure is streamed.” Mital ¶ 5.
14. Mital describes that its system “includes a document conversion
file (BizDocument) 48 that describes the overall data conversion process.
The document conversion file 48 calls or references 50 one or more
component conversion files (BizComponent) 52, 54, 56 & 58.” Mital ¶ 30.
15. Mital describes that component conversion files 52, 54, 56 &
58 are dedicated to converting certain portions of a data file and that
component conversion files 52 and 56 have an “R” which indicates a
repeating structure which should be streamed. Mital ¶ 30.
16. Mital further describes
[t]he process starts, step 80, by receiving a reference to a file in
the first data structure for conversion at step 82. This may be
accomplished by a user designating a file, such as the weeks
purchase orders, for conversion. Next a document conversion
file that converts data in the first data structure to data in the
second data structure is received at step 84. This may be
accomplished by loading a document conversion file in
memory. A repeating structure definition is received at step 86.
The repeating structure definition may [be] defined in user
interface. The document conversion filed is executed at step
88. At step 90, each instance of the repeating structure is
streamed which ends the process at step 92.
Mital ¶ 31.
Appeal 2011-009491
Application 11/369,792

9
Oppenheim
17. Oppenheim is directed to a mechanism that allows distinct
application programs to communicate with one another by allowing the
output of one application program to automatically flow into another
application program as its input. Oppenheim 1:19–26.
18. Oppenheim states
[e]ach transformation script 174 includes a list 176 of
transformee object types to which the script is applicable. In
other words, a script 174 is used only if an object (called the
transformee object) of a corresponding object type is being
transformed by the application program 165 to which the script
belongs.
Oppenheim 5:46–50.

Colon
19. Colon describes that each type of data is stored in a separate
table and joined as needed. Colon 3:20–23.
20. Colon describes using a JavaScript object to manage the
transfer of data between computers which “is used to retrieve values from
the database tables 42 and send them to forms viewed on the computers 17,
18 and 19 at the remote sites, and the JavaScript object 41 is also used to
retrieve values input to the forms and store them in the database.” Colon
4:4–26.
Appeal 2011-009491
Application 11/369,792

10
ANALYSIS
Claims 1, 4, 8–13, 17, 18, 20, 22, and 24 under 35 U.S.C § 103(a) as
unpatentable over Darugar, Hayward, and Mital.
Appellants argue independent claims 1, 4, 9–13, 17, 18, and 20 as a
group (App. Br. 16–21; Reply Br. 2–5), and so, we select claim 1 as
representative. See 37 C.F.R. § 41.37(c)(1)(vii).
We are not persuaded by the Appellants’ argument that the Examiner
erred in combining Darugar, Hayward, and Mital because “Hayward teaches
away from scripting in general.” (App. Br. 18; Reply Br. 2–3). Specifically,
Appellants assert that Hayward discloses that “tools us[ing] proprietary
scripting languages . . . result[] in slow execution . . . [and] may result in
downtime costs in the millions of dollars,” and thus, cannot be combined
with Darugar to teach identifying a stored script to perform the
transformation. (App. Br. 18; citing Hayward ¶ 8). Appellants further assert
that Hayward discloses that its “Data Duplicator module 800 may be
configured to read each file only once, stepping through each of the objects,
preferably disposed in a hierarchy 900,” and thus, cannot be combined with
Mital to teach a script that includes a loop for the plurality of repeating
elements. (App. Br. 18; citing Hayward ¶ 137).
However, the prior art’s mere disclosure of more than one alternative
does not constitute a teaching away from any of the alternatives when the
disclosure does not criticize, discredit, or otherwise discourage the solution
claimed. In re Fulton, 391 F.3d 1195, 1201 (Fed. Cir. 2004). Although
Hayward at paragraph 8 cites a disadvantage of using proprietary scripting
languages because they result in slow execution, there is no indication that
using such proprietary scripting languages would be inoperative, hence it is
Appeal 2011-009491
Application 11/369,792

11
still suggested, just not desired. We further note that Hayward’s reference to
proprietary scripting cannot be said to teach away from “scripting in
general,” as the Appellants assert.
Similarly, although Hayward at paragraph 137 describes that
conversion speed and efficiency may be enhanced by reading each file only
once, Hayward does not criticize, discredit, or otherwise discourage utilizing
a script that includes a loop for repeating elements; it just points out the
inefficiencies. In fact, the portion relied upon by Appellants to support this
argument refers to reading each file only once using optional language
providing that the “the Data Duplicator module 800 may be configured to
read each file only once” (emphasis added). See In re Gurley, 27 F.3d 551,
552–53 (Fed. Cir. 1994) (“[A] reference will teach away if it suggests that
the line of development flowing from the reference’s disclosure is unlikely
to be productive of the result sought by the applicant.”).
We also are not persuaded by the Appellants’ argument that the
combination of Darugar, Hayward, and Mital fails to disclose or suggest
“receiving, over a network, a service request . . . request[ing] a particular
one of a plurality of transformations associated with one of a plurality of
stored scripts and identif[ying] a request data object,” as recited in
independent claim 1, because “Hayward teaches away from scripts and the
integration objects cannot be said to include scripts.” (App. Br. 19–20;
Reply Br. 3–4). Specifically, Appellants assert that in Hayward, it is the
integration objects that perform the conversion steps, as opposed to scripts,
as the claim requires. (App. Br. 20; Reply Br. 4–5).
However, we agree with the Examiner that Hayward describes the
argued limitation (Ans. 27–29), and as discussed above, are not persuaded
Appeal 2011-009491
Application 11/369,792

12
by the Appellants’ argument that Hayward teaches away from scripting in
general. Hayward generally describes a conversion module that utilizes
extracted data and performs a data conversion process on the extracted data
to form converted data that is adapted to data target. (FF 03). Although
Hayward describes that integration objects may be configured to perform
one or more conversion steps, as Appellants assert, Hayward discloses that
the integration objects may be configured to be managed by its data
duplicator module (FF 09), which Hayward describes calls and controls files
including executables, scripts, and a dynamic link library. (FF 10, 11).
Accordingly, we agree with the Examiner that Hayward’s data
duplicator module which causes data conversion steps to be executed
addresses “request[ing] a particular one of a plurality of transformations
associated with one of a plurality of stored scripts and identif[ying] a request
data object,” as claim 1 requires. This interpretation is commensurate with
the scope of claim 1, which broadly recites “a script operable when executed
to implement the transformation,” and reasonable in view of Appellants’
Specification, which does not lexicographically define the term “script.”
(FF 01). We also note this interpretation is reasonable in light of the
definition provided by the Authoritative Dictionary of IEEE Standards,
which defines a “script” as “[a] text-formatting language in which
formatting commands are embedded in the text, then processed into a
formatted document.” (FF 02).
For these reasons, we affirm the rejection of independent claim 1, as
well as claims 4, 9–13, 17, 18, and 20, that were not argued separately.
As to dependent claim 8, the Appellants argue that the combination of
Darugar, Hayward, and Mital fails to disclose or suggest “storing the
Appeal 2011-009491
Application 11/369,792

13
response data object in memory” because “Hayward discloses only that
integration objects perform conversion steps, [and] Appellants respectfully
submit that integration objects are not ‘response data object’ that are
generated ‘by executing the identified script on the request data object.’”
(App. Br. 21–22; Reply Br. 6). However, we agree with the Examiner that
Hayward describes converting formats of source and target data using scripts
on objects like integrated objects which can be stored and streamed back to a
requested target over a network. (See FF 03, 06, 09, 10). For these reasons,
we affirm the rejection of claim 8.
As to claims 22 and 24, the Appellants argue that the combination of
Darugar, Hayward, and Mital fails to disclose “presenting the target data
definition and the repeating elements definition as separate addressable
palette objects on a QUI for a user” because Mital fails to disclose or suggest
“presenting the target data definition and the repeating elements definition as
separate addressable palette objects on a GUI for a user.” (App. Br. 22–23;
Reply Br. 7–8). We disagree.
Mital describes converting a first data structure to a second data
structure. (FF 13). Mital’s system includes a document conversion file that
describes the overall data conversion process and calls or references one or
more component conversion files to convert certain portions of a data file.
(FF 14, 15). Mital’s system places an “R” to indicate a repeating structure
which should be streamed. (FF 15). Mital further describes that its
conversion process identifies a repeating structure definition which may be
defined in a user interface (FF 16), and we agree with the Examiner that
Figure 3 depicts the target data definition and repeating elements definition
Appeal 2011-009491
Application 11/369,792

14
as separate addressable palette objects on a user interface, as the claim
requires. (Ans. 30–31).
For these reasons, we affirm the rejection of claim 22 and 24.
Claims 3, 5, 6, 14 and 15 rejected under 35 U.S.C § 103(a) as unpatentable
over Darugar, Hayward, Mital, and Oppenheim.
Appellants also argue that a combination of Darugar, Hayward, Mital,
and Oppenheim fails to disclose or suggest the subject matter of claims 3, 5,
6, 14, and 15 “[b]ecause Oppenheim does not relate to service requests for
web services or disclose a service definition.” (App. Br. 23–24; Reply Br.
8–9). However, we agree with the Examiner that Oppenheim discloses
receiving a service request that includes a request data object that conforms
with the service definition and generating a response that conforms with the
service definition. (Ans. 32; See also FF 17, 18).
For these reasons, we affirm the rejection of claims 3, 5, 6, 14 and 15.
Claim 19 rejected under 35 U.S.C § 103(a) as unpatentable over
Darugar, Hayward, Mital, and Colon.
As to claim 19, Appellants argue a combination of Darugar, Hayward,
Mital, and Colon fails to disclose or suggest “the response data object
comprises a database row, and wherein storing the response data object
comprises storing the database row in a database table specified by the
script” because “there is no disclosure in Colon that the data ‘comprise[] a
database row.’” (App. Br. 25; Reply Br. 10). However, we agree with the
Examiner that Colon describes storing data in a row in a database table.
(Ans. 23, 33; See also FF 19, 20).
For these reasons, we affirm the rejection of independent claim 19.
Appeal 2011-009491
Application 11/369,792

15
CONCLUSION OF LAW
The rejection of claims 1, 4, 8–13, 17, 18, 20, 22, and 24 under 35 U.S.C
§ 103(a) as unpatentable over Darugar, Hayward, and Mital is proper.
The rejection of claims 3, 5, 6, 14 and 15 under 35 U.S.C § 103(a) as
unpatentable over Darugar, Hayward, Mital, and Oppenheim is proper.
The rejection of claim 19 under 35 U.S.C § 103(a) as unpatentable over
Darugar, Hayward, Mital, and Colon is proper.
DECISION
The rejections of claims 1, 3–6, 8–15, and 17–24 are 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). See 37 C.F.R.
§ 1.136(a)(1)(iv).
AFFIRMED

Klh