Ex Parte Kalavacharla et alDownload PDFPatent Trial and Appeal BoardApr 9, 201411149647 (P.T.A.B. Apr. 9, 2014) Copy Citation UNITED STATES PATENT AND TRADEMARK OFFICE 1 ___________ 2 3 BEFORE THE PATENT TRIAL AND APPEAL BOARD 4 ___________ 5 6 Ex parte MURALIDHAR KALAVACHARLA, 7 ZAFRULLA KHAN, 8 PETER BOW KWONG LEE, 9 DANYIEL AMII LOUIS, 10 SANDEEP RAGHAV, 11 and ALAN MICHAEL WINTROUB 12 ___________ 13 14 Appeal 2011-010763 15 Application 11/149,647 16 Technology Center 2100 17 ___________ 18 19 20 Before ANTON W. FETTING, BIBHU R. MOHANTY, and 21 NINA L. MEDLOCK, Administrative Patent Judges. 22 FETTING, Administrative Patent Judge. 23 24 DECISION ON APPEAL 25 Appeal 2011-010763 Application 11/149,647 2 STATEMENT OF THE CASE1 1 1 Our decision will make reference to the Appellants’ Appeal Brief (“App. Br.,” filed December 20, 2010) and Reply Brief (“Reply Br.,” filed April 28, 2011), and the Examiner’s Answer (“Ans.,” mailed March 2, 2011). Muralidhar Kalavacharla, Zafrulla Khan, Peter Bow Kwong Lee, 2 Danyiel Amii Louis, Sandeep Raghav, and Alan Michael Wintroub 3 (Appellants) seek review under 35 U.S.C. § 134 of a final rejection of 4 claims 1-10 and 23-40, the only claims pending in the application on appeal. 5 We have jurisdiction over the appeal pursuant to 35 U.S.C. § 6(b). 6 The Appellants invented a way of processing logical units of work and 7 more particularly of encapsulating operations comprising logical units of 8 work into a single business object. (Spec. ¶0001). 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 computer implemented method, 13 the method implemented on a processor and a memory 14 programmed for processing a data transaction 15 using a single business object, 16 the method comprising: 17 [1] receiving a business object; 18 [2] identifying the business object 19 as a transaction business object, 20 the transaction business object comprising a single 21 business object 22 Appeal 2011-010763 Application 11/149,647 3 encapsulating a plurality of business objects 1 corresponding respectively to 2 a plurality of function calls 3 for performing an entire atomic transaction, 4 the atomic transaction comprising 5 an indivisible set of operations 6 forming a logical unit of work 7 that must be executed in its entirety; 8 [3] determining an execution sequence 9 for the plurality of function calls encapsulated in the 10 single business object, 11 the execution sequence defined by metadata 12 encapsulated by the transaction business object; 13 and 14 [4] executing each of the function calls 15 according to the execution sequence 16 and 17 executing one of a commit and roll back function 18 to either commit or roll back 19 each operation of the logical unit of work. 20 The Examiner relies upon the following prior art: 21 Doan US 6,128,611 Oct. 3, 2000 Bowman-Amuah US 7,289,964 B1 Oct. 30, 2007 Claims 1-10 and 23-40 stand rejected under 35 U.S.C. § 103(a) as 22 unpatentable over Doan and Bowman-Amuah. 23 Appeal 2011-010763 Application 11/149,647 4 ISSUES 1 The issues of obviousness turn primarily on whether the applied art 2 describes or otherwise shows as predictable: (1) a single business object 3 encapsulating a plurality of business objects corresponding respectively to a 4 plurality of function calls for performing an entire atomic transaction; 5 (2) identifying such an object as a transaction business object; and 6 (3) determining an execution sequence for the plurality of function calls 7 encapsulated in the single business object, the execution sequence defined 8 by metadata encapsulated by the transaction business object. 9 FACTS PERTINENT TO THE ISSUES 10 The following enumerated Findings of Fact (FF) are believed to be 11 supported by a preponderance of the evidence. 12 Facts Related to Claim Construction 13 01. The disclosure contains no lexicographic definition of “business 14 object.” 15 02. The customary meaning of the word “object” in computer 16 science is a discrete item that can be selected and maneuvered. In 17 object-oriented programming, objects include data and the 18 procedures necessary to operate on that data.2 19 20 2 http://education.yahoo.com/reference/dictionary/entry/object (Houghton Mifflin) Appeal 2011-010763 Application 11/149,647 5 Facts Related to Appellants’ Disclosure 1 03. In addition to the data, the business objects may include 2 instructions encoded as metadata that specify, for example, how 3 to process the business objects or how to locate data in a specific 4 application. Spec. ¶0039. 5 Facts Related to the Prior Art 6 Doan 7 04. Doan is directed to computerized methods for accessing 8 databases, and in particular, to an Internet-enabled generic 9 application program for accessing hierarchical data using an 10 object-oriented framework. Doan 3:33-36. 11 05. Doan introduces an Internet-enabled generic application 12 program for accessing hierarchical databases, such as an IMS™ 13 database, by modeling the database into an objects framework and 14 then accessing the database via the objects framework using 15 standard tools, such as the DL/I™ query language for the IMS™ 16 database. The Internet-enabled generic application program 17 dynamically builds a DL/I™ query string based on web browser 18 inputs. The generic application program loads the objects 19 framework to instantiate IMS™ objects and dynamically 20 constructs DL/I™ calls to access the IMS™ database. The 21 generic application program can be used in a number of different 22 environments, such as: (1) DL/I™ batch processing and (2) on-23 line transactions including both IMS™ and CICS™ transactions. 24 Doan 4:41-55. 25 Appeal 2011-010763 Application 11/149,647 6 06. FIG. 2 is a block diagram illustrating a layered processing 1 model provided by Doan’s objects framework. The layered 2 processing model corresponds to the application views, database 3 definitions, and data defined and stored in an IMS™ database 4 management system. The objects framework comprises a C++ 5 class library that interfaces to the generic application program, 6 which dynamically loads previously defined objects into the 7 objects framework to access the database during execution time. 8 The objects loaded into the objects framework include a DL/I™ 9 object, one or more application views, (applView objects) one or 10 more dbdView objects, one or more business objects (BOs), one 11 or more data objects (DOs), and an iterator object. The generic 12 application program first loads the objects framework class library 13 by instantiating a DL/I™ object, one applView object, and one 14 dbdView object. The objects framework then dynamically loads 15 the class library for the BOs and DOs requested by the generic 16 application program to create an iterator object. The iterator 17 object then instantiates the BOs and their corresponding DOs 18 during execution. All the class objects, except the iterator class, 19 are organized into a tree structure to represent the hierarchical 20 structure of data retrieved from the database. The tree structure 21 ensures that there is exactly one path through the hierarchy to each 22 object and consequently exactly one identity, i.e., segment 23 occurrence, for an object. Each of the objects encapsulates a 24 logical unit of data retrieved from the database and includes 25 Appeal 2011-010763 Application 11/149,647 7 member functions for manipulating the encapsulated data. Doan 1 6:5-38. 2 07. The IMS™ database is comprised of a collection of segment 3 types, and each segment type contains a collection of segment 4 occurrences. A data object (DO) class represents each segment 5 type and each segment occurrence is represented by an instance of 6 the class, i.e., a DO. Thus, the DOs provide a direct mapping of 7 the data within each segment occurrence. Moreover, the object-8 oriented generic application program can directly access the data 9 of the segment occurrence by interacting with the DO via the 10 objects framework to perform the necessary operations on the 11 database. In addition, a business object (BO) may be instantiated 12 with a DO to provide business logic for the generic application 13 program. In such an embodiment, the generic application program 14 accesses the business logic via the BO, which in turns invokes the 15 methods of its corresponding DO to perform the necessary 16 operations on the database to manage its essential state data. 17 Thus, the DO isolates the BO from the specifics of the database. 18 With the BO/DO model, customers can easily separate business 19 logic from the physical data access logic to accommodate more 20 diversified business needs. Furthermore, because of the nature of 21 the separation of BO and DO, the objects framework can be easily 22 extended to other non-hierarchical datastores, e.g. DB2™. 23 Doan 7:2-26. 24 08. In the objects framework, the generic application program uses 25 a DL/I™ query string to access the IMS™ database. After the 26 Appeal 2011-010763 Application 11/149,647 8 generic application program receives and parses the user input, it 1 first instantiates a desired applView object. If the associated 2 DL/I™ object has not been instantiated yet, this also results in its 3 instantiation as the root of the objects framework and the root for 4 the collection of application views (applView objects) in the 5 IMS™ database. The generic application program then provides 6 the DL/I™ query string to an "evaluate" method of the applView 7 object. The applView object builds a DL/I segment search 8 argument list based on the values within the DL/I™ query string. 9 The generic application program then creates the iterator object3 10 that is used to point to an incrementally-materialized collection of 11 BOs and DOs that meet the search criteria specified in the DL/I™ 12 query string. The "evaluate" method of the applView object reads 13 the DL/I™ query string and sets a pointer in the iterator object to 14 point to the collection of BOs and DOs that meet the DL/I™ 15 segment search criteria. A "next" method of the iterator object is 16 invoked to instantiate each BO and/or DO from the database, 17 wherein the resulting state data of the BO and DO are cached in 18 the memory of the server computer. Using the pointer and "next" 19 3 An iterator is any object that, pointing to some element in a range of elements (such as an array or a container), has the ability to iterate through the elements of that range using a set of operators (with at least the increment (++) and dereference (*) operators). The most obvious form of iterator is a pointer: A pointer can point to elements in an array, and can iterate through them using the increment operator (++). But other kinds of iterators are possible. For example, each container type (such as a list) has a specific iterator type designed to iterate through its elements. http://www.cplusplus.com/reference/iterator/ Appeal 2011-010763 Application 11/149,647 9 method of the iterator object, the generic application program 106 1 can iterate through a collection of BOs and/or DOs to materialize 2 one BO and/or DO after the other in the memory of the server 3 computer. Each BO and DO class contains both "get" and "set" 4 methods associated for each class attribute. The generic 5 application program can then retrieve or update the attributes of a 6 DO by invoking these methods. Preferably, no I/O operations are 7 performed at the invocation of these "get" and "set" methods, and 8 all state data is changed in memory only until a commit occurs. 9 As described above, the BOs are used by the generic application 10 program to perform needed business logic on the associated DOs. 11 In addition, the generic application program can perform DL/I™ 12 operations (e.g., retrieve, update, delete and insert) using methods 13 of the BOs. The BO will, in turn, invoke the methods of its 14 corresponding DO to perform actual DL/I™ calls. Doan 7:29 – 15 8:5. 16 Bowman-Amuah 17 09. Bowman-Amuah is directed to transaction services patterns. 18 Bowman-Amuah 1:20-21. 19 10. The Document Object Model DOM categorizes Web page 20 elements--including text, images, and links--as objects and 21 specifies the attributes that are associated with each object. The 22 DOM makes Web document objects accessible to scripting 23 Appeal 2011-010763 Application 11/149,647 10 languages such as JavaScript and VisualBasic Script (VBScript). 1 Bowman-Amuah 40:53-61. 2 11. TP monitors offer robust functionality with two-phase commit 3 and recovery/rollback. Bowman-Amuah 94:45-46. 4 12. Two-Phase Commit is a feature found in distributed database 5 management systems and online transaction processing (OLTP) 6 monitors to ensure information integrity across distributed 7 databases. With this feature, a transaction is only committed if 8 two databases have the necessary information. If a problem arises 9 on a network connection or a computer, the software will roll the 10 transaction back so it will not be entered in either place. A restart 11 mechanism may then retry to complete the transaction. Bowman-12 Amuah 99:51-58. 13 13. Web Server Services . . . support . . . [p]rocessing scripts such 14 as Common Gateway Interface (CGI), Active Server Pages (ASP). 15 Server side scripting enables programs or commands to be 16 executed on the server machine providing access to resources 17 stored both inside and outside of the Web server environment. 18 For example, server side scripts can be used to process requests 19 for additional information, such as data from an RDBMS. 20 Bowman-Amuah 109:15-21. 21 14. The "shared format" provides the meta-data information needed 22 to interpret the raw data in the buffer. This shared format is like a 23 secret decoder ring for systems sending and receiving messages. 24 The sending system uses the decoder ring to convert objects, 25 Appeal 2011-010763 Application 11/149,647 11 structures, etc. into raw data on a stream. The receiving system 1 uses another decoder ring to reconstitute the raw data back into 2 objects or structures. Bowman-Amuah 245:18-24; 213:60-37. 3 ANALYSIS 4 Initially, we construe the word “object’ in the claims. An “object” in 5 computer science is a discrete item that can be selected and manipulated. In 6 object oriented programming, such objects may include the procedures 7 necessary to operate on that data. But we find this inclusion of procedures is 8 at the programming level alone. In operation, an object is simply a 9 collection of data with a pointer to its defining class. The class definitions 10 contain the actual definitions (program code) for procedure implementation. 11 Thus, the objects referred to in the claims and in the art are collections of 12 data. The correspondence to function calls is simply the correspondence 13 between an object and its defining class, an inherent property of compiled 14 objects. 15 We adopt the Examiner’s findings from Answer 3-30 and reach similar 16 legal conclusions. Appellants present three arguments with respect to 17 claim 1 in the Briefs: Doan does not describe (1) a single business object 18 encapsulating a plurality of business objects corresponding respectively to a 19 plurality of function calls for performing an entire atomic transaction; 20 (2) identifying such an object as a transaction business object; and (3) 21 determining an execution sequence for the plurality of function calls 22 encapsulated in the single business object, the execution sequence defined 23 by metadata encapsulated by the transaction business object. 24 Appeal 2011-010763 Application 11/149,647 12 We are not persuaded by the Appellants’ argument that Doan does not 1 describe a single business object encapsulating a plurality of business 2 objects corresponding respectively to a plurality of function calls for 3 performing an entire atomic transaction. As the Examiner found, Doan’s 4 iterator object is such an object. Doan’s iterator object and the claimed 5 “single business object” both contain business objects; therefore they are 6 fairly characterized as business object themselves, as there is no 7 lexicographic definition of “business object.” 8 Appellants contend that 9 a logical unit of data retrieved from a database is not a plurality 10 of business objects corresponding respectively to a plurality of 11 function calls for performing an entire atomic transaction 12 Reply Br. 5. An iterator is an object that typically includes a container 13 that contains a range of objects to be addressed one at a time. While Doan 14 does not explicitly describe relying on such a container for its iterator object, 15 this is an obviousness rejection, and iterator objects typically rely on such 16 containers to define their scope.3 17 Thus, Doan’s iterator object is a single object containing the objects 18 iterated over. Doan explicitly includes business objects within the set of 19 such objects iterated over. It is each such business object that Appellants 20 contend is a logical unit of data, not the iterator object. 21 Doan also explicitly describes functions within the iterator object to 22 perform the iteration, and “get” and “set” functions within each business 23 object. Each such function is inherently a set of lower level functions 24 assigned by the program compiler. The function call for each object in the 25 iterate process results in a plurality of such function calls corresponding 26 Appeal 2011-010763 Application 11/149,647 13 respectively to the plurality of objects in the iterator object. Thus, Doan’s 1 iterator object is a single business object encapsulating a plurality of 2 business objects corresponding respectively to a plurality of function calls 3 for performing an entire atomic iterate transaction. 4 As for identifying such an object as a transaction business object, the 5 claim does not recite the manner of identification. The limitation does recite 6 what constitutes a transaction business object, however, and we found 7 Doan’s iterator object is such a transaction business object. Thus, Doan’s 8 identifying an iterator object, which inherently contains the data and 9 functions constituting its contained objects within a defined data structure, 10 implicitly identifies the iterator object as an object containing those parts. 11 As any such container with such parts is within the scope of a transaction 12 business object, the data structure defining Doan’s iterator objet identifies 13 the iterator object as having those attributes and so being within the scope of 14 an transaction business object. We further find that the identification 15 referred to in claim 1 is only for the purpose of identifying the object that is 16 to have an execution sequence determined and executed, so the identification 17 is only that of pointing to the object for such purposes, which Doan 18 necessarily does to perform an iteration. 19 We are not persuaded by the Appellants’ argument that the applied art 20 fails to describe determining an execution sequence for the plurality of 21 function calls encapsulated in the single business object, the execution 22 sequence defined by metadata encapsulated by the transaction business 23 object. To properly answer this contention, we first examine what is within 24 the scope of such metadata. The Specification describes such metadata as 25 being programming instructions embedded as metadata, rather than being 26 Appeal 2011-010763 Application 11/149,647 14 abstract words and phrases acted upon by other instructions. Such 1 programming instructions embedded as metadata are referred to as scripts, 2 which are embedded in comment fields, i.e., metadata fields, in markup 3 languages, such as HTML and XML. 4 The issue then is whether it was predictable to encode Doan’s iterator 5 object programming in scripts. Bowman-Amuah shows it was known to use 6 such scripts in web applications, which are HTML and XML applications 7 that embed scripting language programs written in languages, such as 8 JavaScript or VBScript. Bowman-Amuah also shows it was known to use 9 meta-data to encode objects. Objects include the functions defined by their 10 class. 11 As this line of reasoning as to the use of scripting departs substantially 12 from that of the Examiner, we will designate this as a new ground of 13 rejection. 14 As to claim 2, reciting determining a type associated with the business 15 object, the type identifying the business object as a transaction business 16 object, Doan again identifies its iterator objects, which are a type of 17 transaction business objects. 18 As to claim 31, Appellants contend Doan does not describe the recited 19 the transaction business object encapsulating the plurality of function calls in 20 the single business object such that the plurality of business objects 21 corresponding to the plurality of function calls are passed through an 22 integration broker as a single business object. This limitation does not recite 23 what constitutes an integration broker, so an integration broker is simply that 24 which does what is recited, viz. allowing a transaction business object to 25 Appeal 2011-010763 Application 11/149,647 15 pass through as itself. Such an entity necessarily exists if Doan’s equivalent 1 to the transaction business object is operated upon as such. Doan’s calls to 2 the iterator are, therefore, such integration brokers. 3 CONCLUSIONS OF LAW 4 The rejection of claims 1-10 and 23-40 under 35 U.S.C. § 103(a) as 5 unpatentable over Doan and Bowman-Amuah is proper. 6 DECISION 7 The rejection of claims 1-10 and 23-40 is affirmed, and is designated as 8 a new ground of rejection. 9 10 Our decision is not a final agency action. 11 In addition to affirming the Examiner's rejection(s) of one or more 12 claims, this decision contains new grounds of rejection pursuant to 37 CFR 13 § 41.50(b). 37 CFR § 41.50(b) provides “[a] new ground of rejection 14 pursuant to this paragraph shall not be considered final for judicial review.” 15 This Decision contains a new rejection within the meaning of 37 C.F.R. 16 § 41.50(b) (2007). 17 37 C.F.R. § 41.50(b) also provides that Appellants, WITHIN TWO 18 MONTHS FROM THE DATE OF THE DECISION, must exercise one of 19 the following two options with respect to the new rejection: 20 (1) Reopen prosecution. Submit an appropriate amendment of 21 the claims so rejected or new evidence relating to the claims 22 so rejected, or both, and have the matter reconsidered by the 23 Appeal 2011-010763 Application 11/149,647 16 Examiner, in which event the proceeding will be remanded 1 to the Examiner. . . . 2 (2) Request rehearing. Request that the proceeding be reheard 3 under § 41.52 by the Board upon the same record. . . . 4 Should the Appellants elect to prosecute further before the examiner 5 pursuant to 37 CFR § 41.50(b)(1), in order to preserve the right to seek 6 review under 35 U.S.C. §§ 141 or 145 with respect to the affirmed rejection, 7 the effective date of the affirmance is deferred until conclusion of the 8 prosecution before the examiner unless, as a mere incident to the limited 9 prosecution, the affirmed rejection is overcome. 10 If the Appellants elect prosecution before the Examiner and this does 11 not result in allowance of the application, abandonment or a second appeal, 12 this case should be returned to the Board of Patent Appeals and Interferences 13 for final action on the affirmed rejection, including any timely request for 14 rehearing thereof. 15 No time period for taking any subsequent action in connection with this 16 appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. § 17 1.136(a)(1)(iv). 18 19 20 AFFIRMED; 41.50(b) 21 22 23 tkl 24 Copy with citationCopy as parenthetical citation