Ex Parte TrivediDownload PDFBoard of Patent Appeals and InterferencesJun 8, 201110097866 (B.P.A.I. Jun. 8, 2011) Copy Citation 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 Copy with citationCopy as parenthetical citation