Ex Parte Parisi

Board of Patent Appeals and Interferences

Mar 7, 2011

11174701 (B.P.A.I. Mar. 7, 2011)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________

Ex parte MICHAEL A. PARISI
____________

Appeal 2009-008507
Application 11/174,701
Technology Center 2100
____________

Before JOSEPH L. DIXON, HOWARD B. BLANKENSHIP, and
JAY P. LUCAS, Administrative Patent Judges.

BLANKENSHIP, Administrative Patent Judge.

DECISION ON APPEAL1

1 The two-month time period for filing an appeal or commencing a civil
action, as recited in 37 C.F.R. § 1.304, or for filing a request for rehearing,
as recited in 37 C.F.R. § 41.52, begins to run from the “MAIL DATE”
(paper delivery mode) or the “NOTIFICATION DATE” (electronic delivery
mode) shown on the PTOL-90A cover letter attached to this decision.
Appeal 2009-008507
Application 11/174,701

2
STATEMENT OF THE CASE
This is an appeal under 35 U.S.C. § 134(a) from the Examiner’s final
rejection of claims 1-20, which are all the claims in the application. We
have jurisdiction under 35 U.S.C. § 6(b).
We affirm.

Invention
Appellant’s invention relates to a method for processing data gathered
from diverse sources and diverse formats by establishing an object. The
method determines the format of a data source and determines a
communication protocol to retrieve data from the data source. The object,
using the determined format and communication protocol, retrieves data
from the data source, the object acquiring information and transforming the
information into a consistent format. The method receives input from a user
and instantiates, in accordance with the input from the user, the object, then
conveys data generated by the object to the user. The data generated by the
object may be displayed, reproduced, or manipulated on a user readable
medium. Abstract.

Representative Claim
1. A method, utilizing a computer-based system, of
processing data gathered from diverse sources and diverse
formats comprising:

(a) launching an application having an object integrated
therein;

(b) determining the format of a data source;

Appeal 2009-008507
Application 11/174,701

3
(c) determining a communication protocol to retrieve
data from the data source;

(d) retrieving, using the object integrated in the launched
application, based upon the determined format and
communication protocol, data from the data source, the object
integrated in the launched application acquiring information
and transforming the information into a consistent format;

(e) receiving, after retrieving data from the data source,
input from a user to activate the object integrated in the
launched application;

(f) instantiating, in accordance with the input from the
user, the object integrated in the launched application; and

(g) conveying data generated by the object, in accordance
with the launched application, to the user.

Examiner’s Rejections
Claims 1-12 stand rejected under 35 U.S.C. § 102(e) as being
anticipated by Iyer (US 7,130,812 B1).
Claims 13-20 stand rejected under 35 U.S.C. § 103(a) as being
unpatentable over Iyer and Grune (US 2003/0004936 A1).

Claim Groupings
In view of Appellant’s arguments in the Appeal Brief, we will decide
the appeal on the basis of claims 1 and 7. See 37 C.F.R. § 41.37(c)(1)(vii).

PRINCIPAL ISSUE
Has Appellant shown that the Examiner erred in finding that Iyer
describes every limitation of claim 1?
Appeal 2009-008507
Application 11/174,701

4

FINDINGS OF FACT
Iyer
1. Iyer describes a system and method for information
management. The system provides for collection of data from multiple,
dissimilar and disparate sources having various collection schedules by a
plurality of data collectors. It further provides a central database for storage
of the collected data with front-end alerts and triggers. The central database
has a central data store module for data storage and a central configuration
module for configuring the data as well as the components of the system.
The system includes a reporting module for generating and forwarding user
specific scheduled reports from the accessed data in the central database.
The presentation of the data could be any time, anywhere and in any format
required by the end user. The system also provides an administration
module for collecting, monitoring and configuring the collected data, data
collectors, central database and the reports for the end user. Abstract.
2. Figure 1B shows the overall architecture of system 100 with
System 104 coupled to various data sources 203A. The data sources provide
data in various formats that can be used by business entities to make crucial
business decisions. For example, Legacy systems data source 115 collects
data from proprietary systems in a proprietary format. Col. 8, ll. 14-33.
3. Figure 3B shows a block diagram of the basic architecture of
System 104. System 104 is operationally coupled to data collectors 203 that
collect data from various data sources. The collected data is stored at
database 204, which is accessible by the PowerUser interface 106 via
Appeal 2009-008507
Application 11/174,701

5
PowerInterface server 106A, InfoUser Interface 105 via InfoUser Interface
Server 105A. Col. 9, ll. 17-25.
4. Figure 3C is a top-level block diagram that shows various data
collectors including legacy data collector 203B, DTS data collector 203C,
XML data collector 203D, API data collector 203E, Interactive data
collector 203F and remote data collector 203G coupled to plural data sources
203A. Col. 9, ll. 26-31.
5. Data collectors collect, parse, and packetize (format) data
before sending data to storage module 204A. Data collectors collect data
from a data source and write to storage module 204A. Col. 9, ll. 36-40.
6. For a Windows NT service, data collectors are a set of interface
objects contained in dynamic link libraries (DLLs) that run as an executable
program. A single instance of the program can host multiple collector type
objects and each collector type object can host multiple connections. Col. 9,
ll. 48-53.
7. Figure 4A shows a top-level block diagram of a Data Collector
203. Data Collector 203 may be designed and built as a Windows NT
Service. Data collector 203 includes a collector module 402 that initiates
individual thread collectors for each defined data source 203A. Col. 9, ll.
54-58.
8. API Data Collector 203D (Figure 4D) is used when an API
(Application Programming Interface) is available for a data source.
Typically the manufacturer of a source system makes the API available. The
API allows access to public areas of the source system. Depending on the
protocol used, the API can interface directly (connect to a process on the
Appeal 2009-008507
Application 11/174,701

6
same system), via TCP/IP or via a COM/ActiveX Object, CORBA interface
among other ways. Col. 11, ll. 53-60.
9. Figure 4E shows a block diagram of Interactive Data Collector
system 203E. To capture data, System 104 may send an email with a link
(URL address) to a data input page on a web-browser to a pre-identified
group of people. After the group receives the email, the recipients can go to
a web page using the web-browser and answer a series of questions. These
answers become input for the interactive data collector system 203E. Col.
12, ll. 10-17.
10. At system start-up 104, Remote connector 405A initiates a
TCP/IP session with request handler 405B to transfer configuration
information, including data collector rights, collection objects, collection
schedules, and alert and threshold information. The TCP/IP protocol allows
remote collector 203F to start and connect to a data source. Data transfer
may follow XML data formats. Requests for data and data delivery may
follow XMLP (XML Protocol) being developed by W3C (World Wide Web
Consortium). Col. 14, ll. 33-44.
11. Figure 4B shows a block diagram of a DTS (Data
Transformation Service) collector 203C. DTS Data Collector 203C runs a
DTS package 402A at scheduled times to collect information from an ODBC
compliant data source and writes it to Storage Module 204A. DTS package
402A selects the necessary columns from source tables, including key
columns for transformation. The collected data set is filtered to include only
those rows that are not in Storage Module 204A tables. Transformations are
applied to the filtered data set and the result is written in destination tables
and stored in Storage Module 204A. Col. 10, ll. 25-40.
Appeal 2009-008507
Application 11/174,701

7
12. XML Data Collector 203D takes XML data and transforms into
Storage Module 204A format tables. Col. 12, ll. 2-3.
13. An administrator module includes utilities to set up collection
schedules for data collectors. Col. 6, ll. 3-4; col. 31, ll. 9-11.
14. As shown in Figure 17I, data collection schedules can be both
shipped with database 204 or user defined with a start time and an interval.
These schedules can have a meaningful name associated with them such as
“every 20 seconds.” All existing collection schedules can be listed, and
double clicking on a schedule brings it up for editing/display in the main
window. Col. 33, ll. 8-15.

PRINCIPLES OF LAW
Claim Interpretation
During examination, claims are to be given their broadest reasonable
interpretation consistent with the specification, and the language should be
read in light of the specification as it would be interpreted by one of ordinary
skill in the art. In re Am. Acad. of Sci. Tech Ctr., 367 F.3d 1359, 1364 (Fed.
Cir. 2004) (citations omitted). The Office must apply the broadest
reasonable meaning to the claim language, taking into account any
definitions presented in the specification. Id. (citations omitted).

ANALYSIS
§ 102(e) rejection of claims 1-6
Appellant contends that Iyer fails to disclose “retrieving, using the
object integrated in the launched application, based upon the determined
format and communication protocol, data from the data source, the object
Appeal 2009-008507
Application 11/174,701

8
integrated in the launched application acquiring information and
transforming the information into a consistent format” as recited in claim 1.
Br. 9. In particular, Appellant contends the CTableAccessAuthoritiesObject
object and the CDatabaseRequest object described by Iyer and cited by the
Examiner do not retrieve, based upon the determined format and
communication protocol, data from database 204, wherein the objects
acquire information and transform the information into a consistent format.
Br. 8.
The table access and database request objects cited by the Examiner
are described in col. 21, ll. 14-26 of Iyer. However, the Examiner also
states, inter alia, that col. 9, ll. 54-58 and col. 12, ll. 2-3 of Iyer describe the
“retrieving” limitation. Ans. 6. Columns 9 and 12 of Iyer describe data
collectors that take data from data sources and transform the data into
storage module tables. FF 7, 12. Appellant has not provided persuasive
argument or evidence to distinguish the “retrieving” limitation of claim 1
from retrieving data using the data collectors of Iyer.
Further, Iyer describes several data sources that provide data in
various formats. FF 2. Several data collector interface objects (FF 6),
integrated in an application (FF 3-4), retrieve data from the several data
sources using a communication protocol (FF 8-10). The data collectors then
parse and format the retrieved data into storage module format tables before
sending the data to a storage module. FF 5, 11, 12. Therefore, Iyer
describes “retrieving, using the object integrated in the launched application,
based upon the determined format and communication protocol, data from
the data source, the object integrated in the launched application acquiring
Appeal 2009-008507
Application 11/174,701

9
information and transforming the information into a consistent format”
within the meaning of claim 1.
Appellant contends that the PowerUser Interface described by Iyer
and cited by the Examiner does not describe “receiving, after retrieving data
from the data source, input from a user to activate the object integrated in the
launched application” as recited in claim 1. Br. 8.
However, the data collectors described by Iyer are activated to collect
data according to collection schedules (FF 1, 13). The collection schedules
can be setup and edited by a user (FF 14). When the user edits the collection
schedules after the data collectors have collected some data, the method
described by Iyer is “receiving, after retrieving data from the data source,
input from a user to activate the object integrated in the launched
application” within the meaning of claim 1.
Appellant contends that the Examiner has failed to explicitly set forth
that Iyer describes “instantiating, in accordance with the input from the user,
the object integrated in the launched application” as recited in claim 1. Br.
9. When the data collectors of Iyer collect data according to the collection
schedule edited by the user, the data collectors are instantiated. Therefore,
Iyer describes “instantiating, in accordance with the input from the user, the
object integrated in the launched application” within the meaning of claim 1.
Appellant contends that the Examiner has failed to explicitly set forth
that Iyer describes “conveying data generated by the object, in accordance
with the launched application, to the user” as recited in claim 1. Br. 9. The
data collected by the data collectors described by Iyer are displayed to the
user. FF 1.
Appeal 2009-008507
Application 11/174,701

10
We sustain the § 102(e) rejection of claim 1. Appellant has not
provided arguments for separate patentability of claims 2-6.

§ 102(e) rejection of claim 7
Appellant contends that Iyer does not disclose “generating wrapper
function to invoke the object, the wrapper function including parameters
that, when entered by a user, invoke the action of the object” as recited in
claim 7. Br. 10-12.
Iyer describes an administrator module that includes utilities to set up
collection schedules for data collectors. FF 13. The data collection
schedules can be user defined with a start time and an interval. FF 14.
Therefore, Iyer describes “generating wrapper function to invoke the object,
the wrapper function including parameters that, when entered by a user,
invoke the action of the object” within the meaning of claim 7.
We sustain the § 102(e) rejection of claim 7.

§ 102(e) rejection of claims 8-12
Appellant relies on the arguments presented for claim 1 as arguments
for patentability of claims 8-13. Br. 12-16. We find Appellant’s arguments
unpersuasive as discussed in the analysis of claim 1.
We sustain the § 102(e) rejection of claims 8-12.

§ 103(a) rejection of claims 13-20
Appellant relies on the arguments presented for claim 1 as arguments
for patentability of claims 13-20. Br. 15-19. We find Appellant’s arguments
unpersuasive as discussed in the analysis of claim 1.
Appeal 2009-008507
Application 11/174,701

11
We sustain the § 103(a) rejection of claims 13-20.

CONCLUSION OF LAW
Appellant has not shown that the Examiner erred in finding that Iyer
describes every limitation of claim 1.

DECISION
The rejection of claims 1-12 under 35 U.S.C. § 102(e) as being
anticipated by Iyer is affirmed.
The rejection of claims 13-20 under 35 U.S.C. § 103(a) as being
unpatentable over Iyer and Grune is affirmed.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R.
§ 41.50(f).

AFFIRMED

msc

BASCH & NICKERSON LLP
1777 PENFIELD ROAD
PENFIELD NY 14526