Ex Parte Trivedi

Board of Patent Appeals and Interferences

Jun 8, 2011

10097866 (B.P.A.I. Jun. 8, 2011)

UNITED STATES PATENT AND TRADEMARK OFFICE 1
___________ 2
3
BEFORE THE BOARD OF PATENT APPEALS 4
AND INTERFERENCES 5
___________ 6
7
Ex parte PRAKASH A. TRIVEDI 8
___________ 9
10
Appeal 2010-001335 11
Application 10/097,866 12
Technology Center 3600 13
___________ 14
15
16
Before ANTON W. FETTING, MEREDITH C. PETRAVICK, and 17
MICHAEL W. KIM, Administrative Patent Judges. 18
FETTING, Administrative Patent Judge. 19
DECISION ON APPEAL 20
Appeal 2010-001335
Application 10/097,866

2
1
STATEMENT OF THE CASE1 2
Prakash A. Trivedi (Appellant) seeks review under 35 U.S.C. § 134 3
(2002) of a final rejection of claims 1-7, 9-14,16-20, 22, and 24-27, the only 4
claims pending in the application on appeal. We have jurisdiction over the 5
appeal pursuant to 35 U.S.C. § 6(b) (2002). 6
The Appellant invented a support system for telecommunications service 7
providers providing a connector from an integration platform to a billing 8
unit. (Specification ¶ 0005). 9
An understanding of the invention can be derived from a reading of 10
exemplary claim 1, which is reproduced below [bracketed matter and some 11
paragraphing added]. 12
1. A method for communicating from a first system to a billing 13
system, the method comprising: 14
[1]receiving user-entered information at the first system, 15
the user-entered information comprising information 16
associated with at least one of 17
account management, 18
order management, 19
service management or 20
bill presentation; 21
[2] sending, 22
by the first system, 23

1 Our decision will make reference to the Appellant’s Appeal Brief (“App.
Br.,” filed January 29, 2009) and Reply Brief (“Reply Br.,” filed July 14,
2009), and the Examiner’s Answer (“Ans.,” mailed September 15, 2009).
Appeal 2010-001335
Application 10/097,866

3
event information 1
to a channel, 2
the event information being based on 3
the user-entered information and 4
the channel being subscribed to 5
by a first connector 6
associated with the billing system; 7
[3] receiving, 8
by the first connector, 9
the event information; 10
[4] transforming the event information 11
to a format compatible with the billing system; 12
[5] publishing the event information 13
to a channel 14
subscribed to by a second connector 15
associated with a database system; 16
[6] sending, 17
by the database system, 18
an indication 19
that the database system received the event 20
information; 21
[7] receiving 22
the indication 23
by the first connector; 24
[8] establishing, 25
by the first connector 26
and in response to receiving the indication, 27
communications with the billing system 28
Appeal 2010-001335
Application 10/097,866

4
using remote method invocation over 1
Internet inter- ORB protocol [aka IIOP] ; and 2 2
[9] downloading 3
the transformed event information 4
to the billing system. 5
The Examiner relies upon the following prior art: 6

2 The standard setting organization Object Management Group
describes IIOP as follows:
What is IIOP?
The Object Management Group exists to create standards for
distributed object computing that are realistic, commercially
available and usable. OMG does this through its Object
Management Architecture (OMA) at the heart of which is the
Common Object Request Broker Architecture (CORBA).
CORBA specifies the Object Request Broker (ORB) that allows
applications to communicate with one another no matter where
they reside on a network. The CORBA 2.0 specification,
adopted in 1994, created true out-of-the-box interoperability in
heterogeneous environments and delivers this interoperability
over the Internet through IIOP -- the Internet Inter-ORB
Protocol.
A common misconception about IIOP is that it is a "separate"
specification that developers need to write to in order to allow
CORBA to work over the Internet. This is not so. A properly
constructed CORBA 2.0 ORB already incorporates IIOP. IIOP
is an underlying mechanism of CORBA technology which is
transparently managed by ORBs. So IIOP and CORBA are,
essentially, inseparable. Therefore, programmers and users are
never required to interact with IIOP in any way; it is invisible to
them. IIOP allows their programs to interact transparently while
executing, so one does not have to write "IIOP programs."
IIOP: OMG’s Internet Inter-ORG Protocol A Brief Description,
http://www.omg.org/library/iiop4.html (last visited May 16, 2011).

Appeal 2010-001335
Application 10/097,866

5
Reeder US 5,852,812 Dec. 22, 1998
Arnold US 6,460,072 B1 Oct. 1, 2002
Sistanizadeh US 6,681,232 B1 Jan. 20, 2004
Donlan US 6,952,836 B1 Oct. 4, 2005
Deosaran US 2002/0135611 A1 Sep. 26, 2002
Claims 1-2, 9, 16, 22, 24, and 26-27 stand rejected under 35 U.S.C. § 1
103(a) as unpatentable over Sistanizadeh, Reeder, and Deosaran. 2
Claims 3-4, 6-7, 10-14, 17-20, and 25 stand rejected under 35 U.S.C. § 3
103(a) as unpatentable over Sistanizadeh, Reeder, Deosaran, and Donlan. 4
Claim 5 stands rejected under 35 U.S.C. § 103(a) as unpatentable over 5
Sistanizadeh, Reeder, Deosaran, and Arnold. 6
ISSUES 7
The issues of obviousness turn largely on whether the breadth of the 8
terms “connector” and “channel” may encompass the communications links 9
and interfaces described by Sistanizadeh and other similar claim 10
construction issues. 11
FACTS PERTINENT TO THE ISSUES 12
The following enumerated Findings of Fact (FF) are believed to be 13
supported by a preponderance of the evidence. 14
Facts Related to Appellant’s Disclosure 15
01. Connectors may be implemented in software. Specification ¶ 16
0016. 17
Facts Related to the Prior Art 18
Appeal 2010-001335
Application 10/097,866

6
02. We adopt the Examiner’s findings of fact from the Answer 5-61. 1
Sistanizadeh 2
03. Sistanizadeh is directed to a service level manager, for operations 3
support in an extended-area data communications network. The 4
service level manager has a network database, storing network 5
topology information with service and customer information. The 6
database receives and stores dynamic service-related operations 7
data, from agents in the network. A persistence layer module 8
provides data representing a dynamic view of the topology as well 9
as data representing operations of the extended-area data 10
communications network. The service level manager also includes 11
a user interface, for providing information to and receiving inputs 12
from users. Sistanizadeh 2:37-52. 13
04. Sistanizadeh uses a web based interface and appropriate 14
communications links for transferring data from users. 15
Sistanizadeh 6:59-62. 16
05. Java Database Connectivity (JDBC) provides a standard 17
application programming interface (API) which allows 18
Sistanizadeh’s SLM application to access relational data. JDBC 19
provides standard features such as simultaneous connections to 20
several databases, transaction management, simple queries, calls 21
to stored procedures, access to a database dictionary, etc. 22
Essentially, the JDBC driver converts JDBC invocations to calls, 23
which are sent to the Oracle database server. Sistanizadeh 7:48-56. 24
Appeal 2010-001335
Application 10/097,866

7
06. Sistanizadeh’s manager processes data to form IP detailed records 1
(IPDRs). An IPDR, for example, includes session start time, end 2
time or duration, source IP address, destination IP address, type of 3
payload data, layer 4 port ID, number of bytes communicated, and 4
the like. Sistanizadeh 29:24-29. 5
07. Sistanizadeh’s manager supplies the IPDRs to any other 6
operations support system. Sistanizadeh’s SLM can provide the 7
IPDRs to a billing system, to compile bills and maintain archival 8
records of customer traffic to support the carrier's billing 9
operations. Sistanizadeh 29:30-34. 10
08. The main function Sistanizadeh’s SLM is to translate a 11
provisioning request into management messages that the network 12
understands. Sistanizadeh 17:14-17. 13
09. Sistanizadeh’s user interface offers interactive options to change 14
specific customer services. For example, if the customer selects an 15
option to increase bandwidth, the web server supplies a 16
corresponding request message to the provisioning service 17
module. Sistanizadeh 21:15-20. 18
10. Sistanizadeh’s SLM application server is based on Enterprise 19
Java Beans. Upon receipt of a TSP Service Request, a message 20
handler engine retrieves the field that specifies the particular 21
request, selects the appropriate module or entity that can handle 22
the request and passes it to that particular module (or Bean). 23
Sistanizadeh 7:24-34. 24
Appeal 2010-001335
Application 10/097,866

8
ANALYSIS 1
Claims 1-2, 9, 16, 22, 24, and 26-27 rejected under 35 U.S.C. § 103(a) as 2
unpatentable over Sistanizadeh, Reeder, and Deosaran. 3
We are unpersuaded by the Appellant’s arguments that the claim 4
limitations are not described by the applied art. We adopt the Examiner’s 5
findings of fact and law, and the Examiner’s analysis from Answer 5-14 and 6
24-54, and we reach similar factual and legal conclusions. Thus the 7
remaining issues are those identified in the Reply Brief 4-13. 8
As to independent claim 1, we are unpersuaded by the Appellant’s 9
arguments that the Examiner failed to explain the relevance of the 10
Examiner’s comments section (Reply Brief 4); that a channel cannot be 11
construed as a communications link (Reply Brief 4); that a connector cannot 12
be construed as a Java Database Connectivity module (Reply Brief 4-5); that 13
Sistanizadeh fails to describe sending event information as in claim 1 (Reply 14
Brief 5 -6); that Sistanizadeh fails to describe a billing system subscribing to 15
a channel and connector (Reply Brief 5-6); that Sistanizadeh fails to describe 16
transforming event information to a format compatible with the billing 17
system (Reply Brief 6-7); and that construing event information to 18
encompass Sistanizadeh’s IPDR’s is inconsistent with construing that same 19
event information to encompass Sistanizadeh’s provisioning request (Reply 20
Brief 7). 21
The Examiner clearly provided a comments section to explain the 22
Examiner’s reasons for the claim construction and to facilitate understanding 23
of the mapping from the cited art portions to the claim limitations. 24
Appeal 2010-001335
Application 10/097,866

9
The Appellant provides no real reason that a communications link 1
cannot be an example of a channel, or that a connectivity module cannot be a 2
connector, particularly as the Specification discloses connectors as software 3
implementations (FF 01). Similarly, the Appellant provides no real reason 4
that a Java Database Connectivity module cannot be an example of a 5
connector. Instead, the Appellant recites the claim elements putting the 6
channel and connector in context, viz. the channel being subscribed to by a 7
first connector associated with the billing system. We find that since a 8
channel is a conduit, this encompasses a communications link. FF 04. 9
Similarly, since a connector is simply that which connects, this encompasses 10
an interface such as a Java Database Connectivity module that provides 11
standard features such as simultaneous connections to several databases. FF 12
05. 13
The claim limitations at issue, however, do not further narrow the 14
manner or nature of the subscription or the association. All components 15
within an operating system are associated with the system and so to each 16
other. Accordingly, Sistanizadeh’s Java Database Connectivity module, 17
which is the interface to the database, is associated with the billing system 18
referred to by Sistanizadeh. The activity performed by the software 19
connections from the JDBC’s API to the communications link to handshake 20
its data flow is within the breadth of the word “subscribed,” which in the 21
computer context generally means having requested to receive messages. 22
As to the event information, the nature of the event is undefined, and 23
even the manner in which the information characterizes an event is 24
undefined. Thus, any information that is in some manner associated with 25
some event is sufficient to meet the claim limitation. Since Sistanizadeh is 26
Appeal 2010-001335
Application 10/097,866

10
directed to a service level manager, for operations support in an extended-1
area data communications network (FF 03), all of its data are associated with 2
the events regarding data transmission. 3
As to a billing system and transforming event information to a format 4
compatible with the billing system, Sistanizadeh manager processes data to 5
form IP detailed records (IPDRs) (FF 06), and Sistanizadeh’s SLM can 6
provide the IPDRs to a billing system, to compile bills and maintain archival 7
records of customer traffic to support the carrier's billing operations (FF 07). 8
Again, the claim requires some form of association with Sistanizadeh’s 9
communication link and a Java Database Connectivity module, but does not 10
constrain the manner of association. As we found supra, all the components 11
in Sistanizadeh’s system are associated with each other. Similarly, the claim 12
does not constrain the manner or nature of format compatibility, and does 13
not even require that the pre-transformation format be incompatible. Since 14
Sistanizadeh’s SLM can provide the IPDRs to a billing system, the IPDR’s 15
must necessarily be compatible with the billing system. Since 16
Sistanizadeh’s manager processes data to form IP detailed records, this 17
necessarily requires a transformation in format. 18
As to construing event information to encompass Sistanizadeh’s IPDR’s 19
being inconsistent with construing that same event information to encompass 20
Sistanizadeh’s provisioning request, the claim does not preclude multiple 21
types of event information. In any event, the Examiner clearly relies on 22
Sistanizadeh’s provisioning requests as the pre-formatted event data. 23
As to independent claim 9, we are unpersuaded by the Appellant’s 24
argument that Sistanizadeh fails to show monitoring an input channel for 25
Appeal 2010-001335
Application 10/097,866

11
data associated with at least one of adding, deleting or modifying 1
information stored in a billing system, the data being associated with at least 2
one of account management, order management, service management or bill 3
presentation. Again, the claim fails to narrow the nature or manner of 4
association. As the Examiner found at Answer 33, Sistanizadeh describes 5
monitoring the input data stream for interactive options to change specific 6
customer services. FF 09. Such changes result in changes in billing and 7
accordingly are associated with changing information in the billing system. 8
Such data is clearly associated with account management. 9
As to independent claims 16, 22 and dependent claim 24, we are 10
unpersuaded by the Appellant’s argument that Sistanizadeh fails to describe 11
transforming the data into an appropriate format for the billing system based 12
on a type associated with the input data (claim 16) or opcode3 (claim 22), or 13
receiving a message from the operational data storage system when the 14
operational data storage system has received the information (claim 24). We 15
found that that Sistanizadeh describes transforming the data into an 16
appropriate format for the billing system supra. Sistanizadeh relies on a 17
code in a field interpreted by a message handler for its operations. Such a 18
code is clearly a form of type data or opcode. Sistanizadeh selects the 19
appropriate module or entity that can handle the request and passes it to that 20
particular module. FF 10. 21
Claims 3-4, 6-7, 10-14, 17-20, and 25 rejected under 35 U.S.C. § 103(a) as 22
unpatentable over Sistanizadeh, Reeder, Deosaran, and Donlan. 23

3 The term opcode is a term of art abbreviating the phrase operation code,
viz. a code designating some operation.
Appeal 2010-001335
Application 10/097,866

12
We are unpersuaded by the Appellant’s arguments that the claim 1
limitations are not described by the applied art. We adopt the Examiner’s 2
findings of fact and law, and the Examiner’s analysis from Answer 14-23 3
and 54-60, and we reach similar factual and legal conclusions. The Reply 4
Brief has no rebuttal. 5
Claim 5 rejected under 35 U.S.C. § 103(a) as unpatentable over 6
Sistanizadeh, Reeder, Deosaran, and Arnold. 7
We are unpersuaded by the Appellant’s arguments that the claim 8
limitations are not described by the applied art. We adopt the Examiner’s 9
findings of fact and law, and the Examiner’s analysis from Answer 23-24 10
and 60-61, and we reach similar factual and legal conclusions. The Reply 11
Brief has no rebuttal. 12
CONCLUSIONS OF LAW 13
The rejection of claims 1-2, 9, 16, 22, 24, and 26-27 under 35 U.S.C. § 14
103(a) as unpatentable over Sistanizadeh, Reeder, and Deosaran is proper. 15
The rejection of claims 3-4, 6-7, 10-14, 17-20, and 25 under 35 U.S.C. § 16
103(a) as unpatentable over Sistanizadeh, Reeder, Deosaran, and Donlan is 17
proper. 18
The rejection of claim 5 under 35 U.S.C. § 103(a) as unpatentable over 19
Sistanizadeh, Reeder, Deosaran, and Arnold is proper. 20
DECISION 21
To summarize, our decision is as follows. 22
Appeal 2010-001335
Application 10/097,866

13
 The rejection of claims 1-2, 9, 16, 22, 24, and 26-27 under 35 U.S.C. 1
§ 103(a) as unpatentable over Sistanizadeh, Reeder, and Deosaran is 2
sustained. 3
 The rejection of claims 3-4, 6-7, 10-14, 17-20, and 25 under 35 U.S.C. 4
§ 103(a) as unpatentable over Sistanizadeh, Reeder, Deosaran, and 5
Donlan is sustained. 6
 The rejection of claim 5 under 35 U.S.C. § 103(a) as unpatentable 7
over Sistanizadeh, Reeder, Deosaran, and Arnold is sustained. 8
No time period for taking any subsequent action in connection with this 9
appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. 10
§ 1.136(a)(1)(iv) (2007). 11
12
AFFIRMED 13
14
15
erc 16