Ex Parte Ebrahimi et al

Patent Trial and Appeal Board

Mar 8, 2016

12636441 (P.T.A.B. Mar. 8, 2016)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE
12/636,441 12/11/2009
25537 7590 03/10/2016
VERIZON
PA TENT MANAGEMENT GROUP
1320 North Court House Road
9th Floor
ARLINGTON, VA 22201-2909
FIRST NAMED INVENTOR
Fariborz Ebrahimi
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O. Box 1450
Alexandria, Virginia 22313-1450
www .uspto.gov
ATTORNEY DOCKET NO. CONFIRMATION NO.
20090009 1360
EXAMINER
MUDRICK, TIMOTHY A
ART UNIT PAPER NUMBER
2194
NOTIFICATION DATE DELIVERY MODE
03/10/2016 ELECTRONIC
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the
following e-mail address( es):
patents@verizon.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte F ARIBORZ EBRAHIMI, W ALID HASSAN, SUMIT SINGH,
and INDU MOHAN BABU NORI
Appeal 2014-004411
Application 12/636,441
Technology Center 2100
Before MAHSHID D. SAADAT, CATHERINE SHIANG, and
MATTHEW J. McNEILL, Administrative Patent Judges.
McNEILL, Administrative Patent Judge.
DECISION ON APPEAL
Appellants 1 appeal under 35 U.S.C. § 134(a) from the Examiner's
rejection of claims 1-24, which are all the claims pending in this application.
We have jurisdiction under 35 U.S.C. § 6(b).
We affirm.
1 According to Appellants, the real party in interest is Verizon
Communications Inc. App. Br. 3.
Appeal 2014-004411
Application 12/636,441
STATEMENT OF THE CASE
Introduction
Appellants' present patent application relates to a service integration
platform that acts as an interface between various enterprise systems.
Spec. ,-i 20. Claims 1 and 10 are illustrative of the claimed invention and
read as follows:
1. A method comprising:
receiving, by an interface gateway, a batch data request
including an interface identifier and a file name of a batch data,
the interface gateway being associated with a plurality of
interfaces, each interface, of the plurality of interfaces, providing
conversion of data between a different set of source and target
formats, each interface further being associated with a
combination of components from a group of components that
includes:
a first component to fetch data from a source
location and store the fetched data in a particular target
location,
a second component to create session logs relating
to a processing of data at the interface gateway,
a third component to convert data to a canonical
format,
a fourth component to at least one of translate data,
transform data, or edit data, and
a fifth component to forward data to a target system
and notify one or more users of a successful or
unsuccessful processing of data by the interface gateway;
querying, by the interface gateway and using the interface
identifier, a data table to identify one interface, of the plurality of
interfaces, and the corresponding combination of components
with which the batch data is to be processed; and
processing, by the corresponding combination of
components, the batch data to be converted to the target format.
2
Appeal 2014-004411
Application 12/636,441
10. A system comprising:
an interface gateway that includes:
a memory to store a plurality of tables, the plurality of
tables defining different interfaces that are used to process data
that are to be transferred between source systems and target
systems, the plurality of tables including:
a first table to store parameters relating to an
interface of the different interfaces, the parameters
including an interface identifier,
a second table, mapped to the first table via the
interface identifier, to store a plurality of rules that are
used to implement the interface, wherein a first rule, of the
plurality of rules, causes received data to be converted to
a canonical structure, and wherein a second rule, of the
plurality of rules, causes the canonical structure to be
translated or transformed to a target format,
a third table to store information mapping, for at
least one rule of the rules stored in the second table, the at
least one rule to a server and a service,
a fourth table to store parameters for the server,
a fifth table to store parameters for the service, and
a sixth table to store parameters for the canonical
structure; and
an orchestrator component to:
receive a request to process data, wherein the
request includes the interface identifier and wherein the
data is in a source format,
query, using the interface identifier, the first table to
identify the interface corresponding to the interface
identifier,
process the data using the interface to convert the
data to the target format, wherein the target format is
different than the source format, wherein when processing
3
Appeal 2014-004411
Application 12/636,441
the data, the orchestrator component is to:
execute the rules, wherein, when executing the
rules, the orchestrator component is to:
execute the first rule to cause the data to be
converted to the canonical structure,
execute the second rule to cause the canonical
structure to be translated or transformed into the target
format, and
execute the at least one rule by invoking the service
on the server.
The Examiner's Rejections
Claims 1, 2, and 4-24 stand rejected under 35 U.S.C. § 103(a) as
unpatentable over Gaurav (US 2007/0143334 Al; June 21, 2007) and Taylor
(US 6,256,676 Bl; July 3, 2001). See Final Act. 2-22.
Claim 3 stands rejected under 35 U.S.C. § 103(a) as unpatentable over
Gaurav, Taylor, and McKinley (US 2006/0031584 Al; Feb. 9, 2006). See
Final Act. 23-24.
ANALYSIS
Claim 1
Appellants argue the Examiner erred in finding the combination of
Gaurav and Taylor teaches or suggests "querying, by the interface gateway
and using the interface identifier, a data table to identify one interface, of the
plurality of interfaces, and the corresponding combination of components
with which the batch data is to be processed." See App. Br. 9-13; Reply Br.
3-6. In particular, Appellants argue Taylor does not teach or suggest
querying a data table to identify both the "one interface" and "the
4
Appeal 2014-004411
Application 12/636,441
corresponding combination of components." App. Br. 12. Appellants argue
that even assuming Taylor's message brokering system or rules database can
be construed as the "data table to identify one interface," Taylor does not
teach using its subscription list or rules database to identify the
corresponding batch of components. Id.
Appellants' contentions have not persuaded us of error. Claim 1
recites querying a data table to "identify one interface ... and the
corresponding combination of components with which the batch data is to be
processed." The Board "determines the scope of claims in patent
applications not solely on the basis of the claim language, but upon giving
claims their broadest reasonable construction 'in light of the specification as
it would be interpreted by one of ordinary skill in the art."' Phillips v. A WH
Corp., 415 F.3d 1303, 1316 (Fed. Cir. 2005) (quoting Jn re Am. Acad. of Sci.
Tech. Ctr., 367 F.3d 1359, 1364 (Fed. Cir. 2004).
Under the broadest reasonable interpretation, "querying" does not
require that the interface gateway directly identify the interface and the
corresponding combination of components from a single database query.
Instead, the broadest reasonable interpretation permits the interface gateway
to query the data table to identify the interface and the corresponding
components indirectly or through the use of multiple database queries.
Applying this claim construction, we agree with the Examiner that
Taylor teaches or suggests this limitation by disclosing querying the
subscription list (the claimed "data table") to identify the subscriber to which
a message should be forwarded (the claimed "one interface"). Ans. 3 (citing
Taylor 8:4-32, 12:7-10). This query also allows the interface gateway to
identify the combination of components that corresponds to the interface
5
Appeal 2014-004411
Application 12/636,441
(i.e., the claimed "first" through "fifth" components, which define the
functionality needed for the interface to perform its translation functions,
among others). Ans. 4-5 (citing Taylor 10:40--49; see also Taylor 8:4-32;
12:7-10).
Claim 9
Appellants argue the Examiner erred in finding Taylor teaches
"receiving second information identifying steps to be executed by the
combination of components and an order in which the steps are to be
executed," as recited in claim 9. App. Br. 14-15; Reply Br. 5-6. In
particular, Appellants argue Taylor teaches allowing a user to specify
sources from which an adapter will receive messages instead of identifying
steps and an order for executing the steps. App. Br. 14-15.
Appellants have not persuaded us that the Examiner erred in finding
Taylor teaches this limitation. As the Examiner found, Taylor teaches an
integration workbench that collects information from a user via a graphical
user interface. Ans. 8 (citing Taylor 28:15-16). The workbench allows the
user to select either a standard or custom configuration for an adapter. Id. If
the user selects a custom configuration, the user specifies the sources from
which the adapter is to receive messages and the order in which those
messages are to be received. Ans. 8-9 (citing Taylor Fig. 10; 23:62-24:37,
28:15-16, 24-26). We agree with the Examiner that the user specifying
sources from which the adapter receives messages comprises "identifying
steps to be executed" and the "order in which the steps are to be executed,"
because the order in which messages are to be received determines the order
in which the steps are performed by the components (e.g., fetching data from
6
Appeal 2014-004411
Application 12/636,441
a source location; storing the fetched data; converting data to a canonical
format; and translating, transforming, or editing data). See id.
Claim 10
Appellants argue the Examiner erred in finding Taylor teaches "a first
table to store parameters relating to an interface of the different interfaces,
the parameters including an interface identifier," "a fourth table to store
parameters for the server," and "a fifth table to store parameters for the
service." See App. Br. 15-16, Reply Br. 6-7. In particular, Appellants
argue that even if Taylor teaches user selection of parameters relating to an
interface (including an interface identifier, parameters for the service, and
parameters for the server), Taylor does not teach that this information is
stored in tables that are used to process data between source systems and
target systems, as required by claim 10. App. Br. 16.
Appellants have not persuaded us of error. As found by the Examiner,
Taylor teaches a repository service comprising a relational database that
stores message broker service rules to determine to which subscriber a
message should be forwarded. Ans. 9-10. This database stores information
related to the user's selection of a particular adapter (the claimed "interface
identifier"), implementation information (the claimed "parameters for the
server"), and connection information (the claimed "parameters for the
service"). Final Act. 12. While not relied on for our analysis, we also
observe that although Taylor does not explicitly disclose that this
information is stored in separate tables, an ordinarily skilled artisan would
understand that Taylor's disclosure that the data is stored in a "relational
7
Appeal 2014-004411
Application 12/636,441
database" suggests that it could be stored in a single table or in separate
tables, as claimed. See e.g. Taylor 11 :29--40.
Claim 20
Appellants argue the Examiner erred in finding Taylor teaches or
suggests "metadata that defines the interface, the metadata including ...
information identifying services to be executed for the interface and an order
in which the identified services are to be executed," as recited in claim 20.
See App. Br. 16-18, Reply Br. 7-9. Appellants further argue that even if
Taylor teaches user selection of information identifying services to be
executed for the interface and user selection of information identifying
servers on which the services are to be implemented, Taylor does not teach
information identifying an order in which the identified services are to be
executed or that the information is included in metadata that defines the
interface. App. Br. 18.
As explained above with respect to claim 9, we agree with the
Examiner's finding that Taylor teaches information identifying an order in
which the identified services are to be executed. See Ans. 10. We also
agree with the Examiner's finding that Taylor teaches the claimed
"metadata" for the same reasons that Taylor teaches the claimed data tables
discussed relating to claim 10. See Ans. 10-11. Accordingly, Appellants
have not shown that the Examiner erred in rejecting claim 20 for the same
reasons set forth above for claims 9 and 10.
8
Appeal 2014-004411
Application 12/636,441
CONCLUSIONS
On the record before us and in view of the analysis above, Appellants
have not persuaded us that the Examiner erred in rejecting claims 1, 9, 10,
and 20. Therefore, we sustain the rejection of claims 1, 9, 10, and 20 under
35 U.S.C. § 103(a) as unpatentable over Gaurav and Taylor. We also sustain
the rejection of claims 2, 4-8, 11-19, and 21-24, which were not argued
separately. See App. Br. 13, 16, 18. Appellants argue the patentability of
claim 3 based on the same reasons presented for claim 1. See App. Br. 18.
We, therefore, sustain the rejection of claim 3 under 35 U.S.C. § 103(a) as
unpatentable over Gaurav, Taylor, and McKinley for the same reasons.
DECISION
We affirm the Examiner's rejection of claims 1-24.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § l .136(a)(l )(iv).
AFFIRMED
9