DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-25 are pending.
Response to Arguments
Regarding: Prior Art Rejections:
Applicant’s amendments and arguments regarding the rejection of claims 1-25 under 35 U.S.C. 102 and/or 103 have been fully considered and are moot due to new grounds of rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 6, 12, 13, 24, and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal US 20200285451 A1 in view of Chkodrov et al. US 6895581 B1.
Regarding claim 1, Agarwal teaches the invention as claimed including:
A computer implemented method comprising:
examining a monolithic object oriented computer program, wherein the examining the monolithic object oriented computer program includes identifying that the monolithic object oriented computer program includes an inheritance chain of classes having a first class and a second class (Fig 2 Application 210 is examined including its dependency chart containing parent classes A and B; [0022] the monolithic application 210 is represented as a dependency chart of software modules (e.g., classes)); and
generating a distributed set of microservice partitions in dependence on the examining the monolithic object oriented computer program (Fig 2 Microservices 212, 214 result from analysis of the monolithic application 210; [0023] the system can decouple two microservices service 212 and 214 from the monolithic application 210), wherein the generating the distributed set of microservice partitions includes performing the generating so that there is hosted in a first microservice partition of a distributed set of microservice partitions the first class and further so that there is hosted in a second microservice partition of the distributed set of microservices the second class (Fig 2; [0023] the head (parent class) of microservice 212 is class A while the head of microservice 214 is class B).
While Agarwal includes elements suggesting object-oriented programming and by extension, inheritance, ([0045] The computer programs (also referred to as programs, software, software applications, “apps”, or code) may include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language) it does not explicitly teach an object-oriented computer program including an inheritance chain of classes.
However, Chkodrov teaches an object oriented computer program including an inheritance chain of classes (Fig 2 chain of classes; Claim 1: a computer program developed with an object-oriented programming language; Class inheritance provides the powerful intellectual tool of hierarchical ordering for managing the complexity of a program. In this regard, a program can often be organized as a set of trees or directed acyclic graphs of classes. Each node of the tree may be a class derived from another class and may itself be the base class for another derived class, Col 1 39-45).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Chkodrov’s object-oriented inheritance with the existing class system of Agarwal. A person of ordinary skill in the art would have been motivated to make this combination to provide the resulting system with the advantage of utilizing an object oriented framework to define software entities’ creation, function/behavior, and relations (see Chkodrov The essence of object-oriented programming is to treat data and the procedures that act upon the data as individual "objects," each of which is a self-contained entity with an identity and certain characteristics of its own. Each object type is defined by a "class" defined in the source code of the software application… Col 1 13-29).
Regarding claim 2, Agarwal and Chkodrov teach the computer implemented method of claim 1.
Agarwal further teaches wherein the method includes constructing object data of the first class in the first microservice partition ([0024] the system may extract classes A, C, D, F, H, and J, along with their internal dependencies, and create a self-sufficient microservice 212 that performs the same functionality).
Regarding claim 6, Agarwal and Chkodrov teach the computer implemented method of claim 1.
Agarwal further teaches wherein the method includes constructing object data of the first class in the first microservice partition ([0024] the system may extract classes A, C, D, F, H, and J, along with their internal dependencies, and create a self-sufficient microservice 212 that performs the same functionality), and constructing object data of the second class in the second microservice partition ([0033] The microservice 420 may include executable code/service for the functionality identified through the function identifier input field 416; [0038] the decoupled microservice may include a separately executable software program configured to execute the identified function without depending on the monolithic software application. That is, the decoupled microservice may be self-sufficient; Examiner notes: the generated microservice containing class B contains the code for class B so that the microservice may execute functions requiring objects of class B),
wherein the object data of the first class and the object data of the second class define an object of the first class (Fig 2 Objects of Classes J and H both define an object of class A).
Regarding claim 12, Agarwal teaches the invention as claimed including:
A computer implemented method comprising:
constructing object data of a first class in a first microservice partition (Fig 2 Microservice 212 Class H); and
constructing object data of a second class in a second microservice partition (Fig 2 Microservice 214 Class K),
While Agarwal teaches that classes H and K are in some dependency relation, it does not explicitly teach the relation being an inheritance class relation.
However, Chkodrov teaches wherein the second class and the first class are in inheritance class relation (a replacement class B inheriting from the class A … class A { virtual A(int i) ; // the class A can be replaced } class B : public A { virtual A(int i) ; // replacement constructor as A virtual B(int i, char *s) ; // constructor used // by the new code. }, Col 8 3-17).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Chkodrov’s inheritance relation with the classes of the existing system. A person of ordinary skill in the art would have been motivated to make this combination to provide the resulting system with the advantage of building upon base class functionalities with new classes (see Chkodrov Col 5 56-58 new classes inheriting from those classes used in the existing modules may be designed to provide refined functionality and features).
Regarding claim 13, Agarwal and Chkodrov teach the computer implemented method of claim 12.
Agarwal further teaches wherein the constructing of the object data of the second class is responsive to the constructing of the object data of the first class (Fig 2 Inheritance between Classes H and K ; Examiner notes: instantiation of class H will also invoke instantiation of K).
Regarding claim 24, it is the computer program product of claim 1. Therefore, it is rejected for the same reasons as claim 1.
Regarding claim 25, it is the system of claim 1. Therefore, it is rejected for the same reasons as claim 1.
Agarwal further teaches a memory; at least one processor in communication with the memory; and program instructions executable by one or more processor via the memory to perform a method ([0045] “machine-readable medium” and “computer-readable medium” refer to any computer program product, apparatus, cloud storage, internet of things, and/or device (e.g., magnetic discs, optical disks, memory, programmable logic devices (PLDs)) used to provide machine instructions and/or data to a programmable processor).
Claims 3, 4, and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal US 20200285451 A1 in view of Chkodrov et al. US 6895581 B1 in view of Evans US 7739688 B1.
Regarding claim 3, Agarwal and Chkodrov teach the computer implemented method of claim 1.
Agarwal further teaches wherein the method includes constructing object data of the first class in the first microservice partition ([0024] the system may extract classes A, C, D, F, H, and J, along with their internal dependencies, and create a self-sufficient microservice 212 that performs the same functionality), the constructing including allocating memory space of a runtime memory of the first microservice partition to the object data of the first class, and writing the object data to the allocated memory space of the runtime memory of the first microservice partition ([0033] The microservice 420 may include executable code/service for the functionality identified through the function identifier input field 416; [0038] the decoupled microservice may include a separately executable software program configured to execute the identified function without depending on the monolithic software application. That is, the decoupled microservice may be self-sufficient; Examiner notes: the generated microservice containing class A contains the code for class A so that the microservice may execute functions requiring objects of class A)
Agarwal does not explicitly teach wherein the method includes storing reference identifier for the object data of the first class in an object registry of the first microservice partition.
However, Evans teaches wherein the method includes storing reference identifier for the object data of the first class in an object registry of the first microservice partition (Claim 1 maintain, within the memory, a database of well-defined objects and a registry of identifiers).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Evans’ bookkeeping of objects in a registry with the system of Agarwal to maintain objects of classes within each generated microservice. A person of ordinary skill in the art would have been motivated to make this combination to provide Agarwal’s system with the advantage of tracking objects at an individual level to allow for specified targeting during function invocation (see Evans Col 2 48-57 an improved technique involves distribution management of well-defined objects using a client-provided identifier. The use of such an identifier enables a server to be aware of the client's limitations. Once the server knows which well-defined objects the client can and cannot handle, the server streams only those well-defined objects that the client is capable of handling. As a result, the client does not receive a newer well-defined object that the client cannot construct thus preventing the client from inadvertently failing).
Regarding claim 4, Agarwal and Chkodrov teach the computer implemented method of claim 1.
Agarwal further teaches wherein the method includes constructing object data of the first class in the first microservice partition ([0024] the system may extract classes A, C, D, F, H, and J, along with their internal dependencies, and create a self-sufficient microservice 212 that performs the same functionality), the constructing including allocating memory space of a runtime memory of the first microservice partition to the object data of the first class, and writing the object data of the first class to the allocated memory space of the runtime memory of the first microservice partition ([0033] The microservice 420 may include executable code/service for the functionality identified through the function identifier input field 416; [0038] the decoupled microservice may include a separately executable software program configured to execute the identified function without depending on the monolithic software application. That is, the decoupled microservice may be self-sufficient; Examiner notes: the generated microservice containing class A contains the code for class A so that the microservice may execute functions requiring objects of class A),
Evans teaches wherein the method includes storing a reference identifier for the object data of the first class in an object registry of the first microservice partition (Claim 1 maintain, within the memory, a database of well-defined objects and a registry of identifiers), and wherein the method includes sharing the reference identifier with the second microservice partition (a client-provided identifier Col 3 35-36; Examiner notes: for microservice to invoke other microservices, they need to identify which object to invoke (reference id)).
Regarding claim 5, Agarwal and Chkodrov teach the computer implemented method of claim 1.
Agarwal further teaches wherein the method includes constructing object data of the first class in the first microservice partition ([0024] the system may extract classes A, C, D, F, H, and J, along with their internal dependencies, and create a self-sufficient microservice 212 that performs the same functionality), the constructing including allocating memory space of working memory of the first microservice partition to the object data of the first class, and writing the object data to the allocated memory space ([0033] The microservice 420 may include executable code/service for the functionality identified through the function identifier input field 416; [0038] the decoupled microservice may include a separately executable software program configured to execute the identified function without depending on the monolithic software application. That is, the decoupled microservice may be self-sufficient; Examiner notes: the generated microservice containing class A contains the code for class A so that the microservice may execute functions requiring objects of class A),
constructing object data of the second class on the second partition ([0033] The microservice 420 may include executable code/service for the functionality identified through the function identifier input field 416; [0038] the decoupled microservice may include a separately executable software program configured to execute the identified function without depending on the monolithic software application. That is, the decoupled microservice may be self-sufficient; Examiner notes: the generated microservice containing class B contains the code for class B so that the microservice may execute functions requiring objects of class B), wherein the object data of the first class and the object data of the second class define an object of the first class (Fig 2 Objects of Classes J and H both define an object of class A).
Evans teaches wherein the method includes storing a reference identifier for the object data of the first class in an object registry of the first microservice partition (Claim 1 maintain, within the memory, a database of well-defined objects and a registry of identifiers), and wherein the method includes sharing the reference identifier with the second microservice partition (a client-provided identifier Col 3 35-36; Examiner notes: for services to invoke other services, they need to identify which object to invoke (reference id)), and assigning the reference identifier to the object data of the second class (Claim 1 provide (i) all of the well-defined objects from the database to the client device through the interface in response to the well-defined object request when the particular identifier of the well-defined object request is a most recent identifier in the registry).
Claims 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal US 20200285451 A1 in view of Chkodrov et al. US 6895581 B1 in view of dragosb91 https://www.reddit.com/r/learnjava/comments/gnd6k1/what_is_the_purpose_of_super_in_a_class/.
Regarding claim 7, Agarwal and Chkodrov teach the computer implemented method of claim 1.
Agarwal further teaches wherein the method includes, constructing object data of the first class in the first microservice partition ([0024] the system may extract classes A, C, D, F, H, and J, along with their internal dependencies, and create a self-sufficient microservice 212 that performs the same functionality), and constructing object data of the second class in the second microservice partition ([0033] The microservice 420 may include executable code/service for the functionality identified through the function identifier input field 416; [0038] the decoupled microservice may include a separately executable software program configured to execute the identified function without depending on the monolithic software application. That is, the decoupled microservice may be self-sufficient; Examiner notes: the generated microservice containing class B contains the code for class B so that the microservice may execute functions requiring objects of class B), wherein the object data of the first class and the object data of the second class define the object of the first class (Fig 2 Objects of Classes J and H both define an object of class A).
Agarwal and Chkodrov does not explicitly teach in response to a call for construction of an object of the first class, constructing object data of first and second classes.
However, dragosb91 teaches in response to a call for construction of an object of the first class, constructing object data of first and second classes (Super() means invoke the constructor of the parent class. That is how instantiation of classes in an inheritance hierarchy works in java: the top level parent has to be created first and then the second most top level all the way until the class level that we are actually instantiating).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined the super constructor from dragosb91’s with the system of Agarwal. A person of ordinary skill in the art would have been motivated to make this combination to provide Agarwal’s system with object oriented like instantiation of objects in microservices (see dragosb91 the top level parent has to be created first and then the second most top level all the way until the class level that we are actually instantiating).
Regarding claim 8, Agarwal and Chkodrov teach the computer implemented method of claim 1.
Agarwal further teaches wherein the method includes, constructing object data of the first class in the first microservice partition ([0024] the system may extract classes A, C, D, F, H, and J, along with their internal dependencies, and create a self-sufficient microservice 212 that performs the same functionality), and constructing object data of the second class in the second microservice partition ([0033] The microservice 420 may include executable code/service for the functionality identified through the function identifier input field 416; [0038] the decoupled microservice may include a separately executable software program configured to execute the identified function without depending on the monolithic software application. That is, the decoupled microservice may be self-sufficient; Examiner notes: the generated microservice containing class B contains the code for class B so that the microservice may execute functions requiring objects of class B), wherein the object data of the first class and the object data of the second class define the object of the first class (Fig 2 Objects of Classes J and H both define an object of class A),
Agarwal and Chkodrov does not explicitly teach in response to a call for construction of an object of the first class, constructing object data of first and second classes.
However, dragosb91 further teaches in response to a call for construction of an object of the first class, constructing object data of first and second classes, wherein the method includes receiving, within the first microservice partition a call on the object of the first class for an inherited method inherited from the second class, and responding to the call using the object data of the second class (Super() means invoke the constructor of the parent class. That is how instantiation of classes in an inheritance hierarchy works in java: the top level parent has to be created first and then the second most top level all the way until the class level that we are actually instantiating; Examiner notes: class 1 inherits from class 2 when constructor of class 1 is called, the constructor method of class 2 is also called because class 2 is the parent class of class 1).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Agarwal US 20200285451 A1 in view of Chkodrov et al. US 6895581 B1 in view of Bannon et al. US 5297279 A.
Regarding claim 9, Agarwal and Chkodrov teach the computer implemented method of claim 1.
Agarwal further teaches wherein the method includes constructing object data of the first class in the first microservice partition ([0024] the system may extract classes A, C, D, F, H, and J, along with their internal dependencies, and create a self-sufficient microservice 212 that performs the same functionality), and constructing object data of the second class in the second microservice partition ([0033] The microservice 420 may include executable code/service for the functionality identified through the function identifier input field 416; [0038] the decoupled microservice may include a separately executable software program configured to execute the identified function without depending on the monolithic software application. That is, the decoupled microservice may be self-sufficient; Examiner notes: the generated microservice containing class B contains the code for class B so that the microservice may execute functions requiring objects of class B),
wherein the object data of the first class and the object data of the second class define a certain object ([0045] object-oriented programming language),
Agarwal and Chkodrov do not explicitly teach wherein the method includes incrementing a remote reference count for the certain object to a first value in the first microservice partition, and responsively to the incrementing the remote reference count for the certain object to the first value in the first microservice partition, calling, by the first microservice partition the second microservice partition, and responsively to the calling, incrementing a remote reference count for the certain object in the second microservice partition to the first value so that an object remote reference count for the certain object between the first microservice partition and the second microservice partition is synchronized.
However, Bannon teaches wherein the method includes incrementing a remote reference count for the certain object to a first value in the first microservice partition, and responsively to the incrementing the remote reference count for the certain object to the first value in the first microservice partition, calling, by the first microservice partition the second microservice partition, and responsively to the calling, incrementing a remote reference count for the certain object in the second microservice partition to the first value so that an object remote reference count for the certain object between the first microservice partition and the second microservice partition is synchronized (Number of references to encapsulation 62 is incremented by 1 (one) every time a PTR 44 is created that references encapsulation 62, and decremented by 1 (one) every time a PTR 44 that references encapsulation 62 is deleted, Col 22 3-7; Number of external references is the number of external references of the object being passed in this POS encapsulation 70, Col 28 42-44; Examiner notes: the number of references of an object is being tracked and updated in a database).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Bannon’s tracking of external references for an object with the system of Agarwal. A person of ordinary skill in the art would have been motivated to make this combination to provide Agarwal’s system with the advantage of reducing number of redundant data access operations in object oriented systems (see Bannon Col 5 and 6: Another object of the present invention is to provide a database management system and method that allows the application developer to specify at object definition time how related objects, whether created dynamically or statically, should be clustered when stored, to thereby provide a capability to adjust the size of storage objects to enhance the overall system performance. Still another object of the present invention is to provide a database management system and method that reduces the number of interactions with the database management system that an application developer must code to access objects stored in the database).
Claims 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal US 20200285451 A1 in view of Chkodrov et al. US 6895581 B1 in view of dragosb91 https://www.reddit.com/r/learnjava/comments/gnd6k1/what_is_the_purpose_of_super_in_a_class/ in view of Issack https://issackpaul95.medium.com/rmi-remote-method-invocation-1fd5ba218968.
Regarding claim 10, Agarwal and Chkodrov teach the computer implemented method of claim 1.
Agarwal further teaches wherein the method includes constructing object data of the first class in the first microservice partition ([0024] the system may extract classes A, C, D, F, H, and J, along with their internal dependencies, and create a self-sufficient microservice 212 that performs the same functionality), constructing object data of the second class in the second microservice partition ([0033] The microservice 420 may include executable code/service for the functionality identified through the function identifier input field 416; [0038] the decoupled microservice may include a separately executable software program configured to execute the identified function without depending on the monolithic software application. That is, the decoupled microservice may be self-sufficient; Examiner notes: the generated microservice containing class B contains the code for class B so that the microservice may execute functions requiring objects of class B), and constructing object data of a third class in the first microservice partition (Fig 2), wherein the object data of the first class, the object data of the second class, and the object data of the third class define a certain object (Fig 2 multiple inheritance scenario where a child class has multiple levels of parent classes in different microservices seen in Class H; [0045] object-oriented programming language;).
dragosb91 discloses invoking parent super constructors when invoking the child constructor.
Agarwal, Chkodrov, and dragosb91 do not explicitly teach wherein the method includes, for construction of the certain object, (a) a constructor of the first class within the first microservice partition constructing the object data of the first class and calling a proxy class constructor of the second class within the first microservice partition, (b) the proxy class constructor, without constructing object data, calling a constructor of the third class within the first microservice partition, and (c) the constructor of the third class constructing the object data of the third class.
However, Issack teaches wherein the method includes, for construction of the certain object, (a) a constructor of the first class within the first microservice partition constructing the object data of the first class and calling a proxy class constructor of the second class within the first microservice partition, (b) the proxy class constructor, without constructing object data, calling a constructor of the third class within the first microservice partition, and (c) the constructor of the third class constructing the object data of the third class (Transport Layer − Connection between client and server. It controls the existing connection and new connections. Stub − A stub is a representation (proxy) of the remote object at client. It resides in the client system; it acts as a gateway for the client program. Skeleton − This is the object which resides on the server side. stub communicates with this skeleton to pass request to the remote object. RRL(Remote Reference Layer) − It is the layer which manages the references made by the client to the remote object; Examiner notes: the remote method invocation of Issack proxy’s remote objects at the local client this proxy may be utilized to request constructors of remote or local classes).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined the remote method invocation system of Issack with the system of Agarwal and dragosb91 to obtain a local reference object to call remote class constructors required to instantiate an object with distributed parent classes. A person of ordinary skill in the art would have been motivated to make this combination to provide Agarwal and dragosb91’s system with the advantage of providing communication in distributed object oriented systems (see Issack RMI is provides a mechanism to create distributed application in java. This mechanism allows an object to residing in one system (JVM) to an object running in another JVM. It is an API.).
Regarding claim 17, Agarwal and Chkodrov teach the computer implemented method of claim 12.
dragosb91 teaches wherein the method includes responsively to the constructing of the object data of the first class in the first microservice partition, constructing the object data of the second class in the second microservice partition (Super() means invoke the constructor of the parent class. That is how instantiation of classes in an inheritance hierarchy works in java: the top level parent has to be created first and then the second most top level all the way until the class level that we are actually instantiating; Examiner notes: instantiation of a subclass will invoke the parent class constructor where the parent class resides).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined dragosb91’s super constructor concept and class definitions with the system of Agarwal to obtain object construction across microservices. A person of ordinary skill in the art would have been motivated to make this combination to provide Agarwal’s system with the advantage of defining class fields and methods of an object whilst defining those of the inherited classes as well.
Issack teaches subsequently to the constructing of the object of the second class in the second microservice partition, receiving a service call by an object defined by the first object data and the second object data and responding to the service call using the object data of the second class (Stub − A stub is a representation (proxy) of the remote object at client. It resides in the client system; it acts as a gateway for the client program. Skeleton − This is the object which resides on the server side. stub communicates with this skeleton to pass request to the remote object; Examiner notes: under Issack, utilizing a method located in a remote class involves method proxying).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined the remote method invocation system of Issack with the system of Agarwal, Chkodrov, and dragosb91 to obtain a local reference object to call remote class constructors required to instantiate an object with distributed parent classes. A person of ordinary skill in the art would have been motivated to make this combination to provide Agarwal and dragosb91’s system with the advantage of providing communication in distributed object oriented systems (see Issack RMI is provides a mechanism to create distributed application in java. This mechanism allows an object to residing in one system (JVM) to an object running in another JVM. It is an API.).
Claims 14, 15, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal US 20200285451 A1 in view of Chkodrov et al. US 6895581 B1 in view of Issack https://issackpaul95.medium.com/rmi-remote-method-invocation-1fd5ba218968.
Regarding claim 14, Agarwal and Chkodrov teach the computer implemented method of claim 12.
Chkodrov further teaches a constructor of the first class (Depending on which class is to be used for object creation, the proper class reference information will be used to create the correct object and invoke its constructor, Col 7 34-36); wherein the constructing of the object data of the second class is responsive to the constructing of the first class (The derived class inherits from the base class in that an object of the derived class automatically gets the data and method members of the base class. The derived class may refine the concept represented by the base class by defining additional data or method members or redefining method members to override those of the base class, Col 1 32-39; Examiner notes: in object oriented inheritance, by the creation of objects of derived classes, the data and method members of the base class are constructed and then overridden accordingly with construction of the derived class’ data and methods).
Agarwal and Chkodrov do not explicitly teach wherein responsive to the constructing of the object data of the first class, a constructor of the first class calls the second microservice partition for construction of the object data of the second class.
However, Issack teaches wherein responsive to the constructing of the object data of the first class, a constructor of the first class calls the second microservice partition for construction of the object data of the second class (In RMI application there are two programs we write. server program (resides on the server)- a remote object is created and reference of that object is made available for the client (using the registry). client program (resides on the client)- requests the remote objects on the server and tries to invoke its methods; RMI is provides a mechanism to create distributed application in java. This mechanism allows an object to residing in one system (JVM) to an object running in another JVM. It is an API).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined the remote method invocation system of Issack with the system of Agarwal and Chkodrov to obtain a local reference object to call remote class constructors required to instantiate an object with distributed parent classes. A person of ordinary skill in the art would have been motivated to make this combination to provide Agarwal’s system with the advantage of providing remote method invocations in distributed object oriented systems (see Issack RMI is provides a mechanism to create distributed application in java. This mechanism allows an object to residing in one system (JVM) to an object running in another JVM. It is an API.).
Regarding claim 15, Agarwal and Chkodrov teach the computer implemented method of claim 12.
Chkodrov further teaches a constructor of the first class (Depending on which class is to be used for object creation, the proper class reference information will be used to create the correct object and invoke its constructor, Col 7 34-36); wherein the constructing of the object data of the second class is responsive to the constructing of the first class … and wherein the object data of the second class includes variable defining object data and method defining object data (The derived class inherits from the base class in that an object of the derived class automatically gets the data and method members of the base class. The derived class may refine the concept represented by the base class by defining additional data or method members or redefining method members to override those of the base class, Col 1 32-39; Examiner notes: in object oriented inheritance, by the creation of objects of derived classes, the data and method members of the base class are constructed and then overridden accordingly with construction of the derived class’ data and methods),
Agarwal and Chkodrov do not explicitly teach wherein responsive to the constructing of the object data of the first class, a constructor of the first class calls the second microservice partition for construction of the object data of the second class.
However, Issack teaches wherein responsive to the constructing of the object data of the first class, a constructor of the first class calls the second microservice partition for construction of the object data of the second class (In RMI application there are two programs we write. server program (resides on the server)- a remote object is created and reference of that object is made available for the client (using the registry). client program (resides on the client)- requests the remote objects on the server and tries to invoke its methods; RMI is provides a mechanism to create distributed application in java. This mechanism allows an object to residing in one system (JVM) to an object running in another JVM. It is an API).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined the remote method invocation system of Issack with the system of Agarwal and Chkodrov to obtain a local reference object to call remote class constructors required to instantiate an object with distributed parent classes. A person of ordinary skill in the art would have been motivated to make this combination to provide Agarwal’s system with the advantage of providing remote method invocations in distributed object oriented systems (see Issack RMI is provides a mechanism to create distributed application in java. This mechanism allows an object to residing in one system (JVM) to an object running in another JVM. It is an API.).
Regarding claim 18, Agarwal teaches the invention substantially as claimed including:
A computer implemented method comprising:
receiving, by a certain class hosted on a first microservice partition, a call for construction of an object of the certain class, wherein the certain class is a child class of a parent class (Fig 2 Class J construction involves parent classes H and K; [0045] The computer programs (also referred to as programs, software, software applications, “apps”, or code) may include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language);
in response to the receiving, constructing object data of the certain class on the first microservice partition and sending, by the first microservice partition, to a second microservice partition a call for construction of object data of the parent class (Fig 2 creating the Class J as originally declared in monolith application 210 on Microservice 212 will need to make an invocation of Class K’s constructor on Microservice 214).
Agarwal does not explicitly teach object creation of its mentioned classes.
However, Chkodrov teaches object creation of specific classes (When the instruction in the old code to create an object of the base code is executed, the registered replacement information is referenced. If registered replacement information indicates that the base class is to be replaced with the new class, an object of the new class is created instead of an object of the old class, Col 2 57-62).
Agarwal does not explicitly teach constructing object data of the parent class on the second microservice partition in response to the call for construction of object data of the parent class, wherein the object of the certain class is defined by the object data of the certain class and object data of the parent class.
However, Issack teaches constructing object data of the parent class on the second microservice partition in response to the call for construction of object data of the parent class, wherein the object of the certain class is defined by the object data of the certain class and object data of the parent class (In the RMI application, both client and server interacts with the remote interface. The client application invokes methods on the proxy object, RMI sends the request to the remote JVM. The return value is sent back to the proxy object and then to the client application; Skeleton − This is the object which resides on the server side. stub communicates with this skeleton to pass request to the remote object).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Issack’s remote method invocation system with the system of Agarwal and Chkodrov which allows for Class H to invoke Class K’s constructor on a different microservice. A person of ordinary skill in the art would have been motivated to make this combination to provide the system with the advantage of providing cross node functionality in object oriented programming (see Issack RMI is provides a mechanism to create distributed application in java. This mechanism allows an object to residing in one system (JVM) to an object running in another JVM. It is an API).
Regarding claim 19, Agarwal, Chkodrov, and Issack teach the computer implemented method of claim 18.
Issack further teaches wherein the method includes receiving, by the object, a call for an object method inherited from the parent class, and wherein the method includes responding to the call using the object data of the parent class (server program (resides on the server)- a remote object is created and reference of that object is made available for the client (using the registry) client program (resides on the client)- requests the remote objects on the server and tries to invoke its methods).
Claims 20, 21, 22, 23 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal US 20200285451 A1 in view of Chkodrov et al. US 6895581 B1 in view of Issack https://issackpaul95.medium.com/rmi-remote-method-invocation-1fd5ba218968 in view of Evans US 7739688 B1.
Regarding claim 20, Agarwal, Chkodrov, and Issack teach the computer implemented method of claim 18.
Agarwal and Issack do not explicitly teach wherein the method includes in response to the constructing of the object data of the certain class, assigning a reference identifier to the object data of the certain class.
However, Evans teaches wherein the method includes in response to the constructing of the object data of the certain class, assigning a reference identifier to the object data of the certain class (Claim 1 maintain, within the memory, a database of well-defined objects and a registry of identifiers).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Evans’ bookkeeping of objects in a registry with the system of Agarwal, Chkodrov, and Issack to maintain objects of classes within each generated microservice. A person of ordinary skill in the art would have been motivated to make this combination to provide the system with the advantage of tracking objects at an individual level to allow for specified targeting during function invocation (see Evans Col 2 48-57 an improved technique involves distribution management of well-defined objects using a client-provided identifier. The use of such an identifier enables a server to be aware of the client's limitations. Once the server knows which well-defined objects the client can and cannot handle, the server streams only those well-defined objects that the client is capable of handling. As a result, the client does not receive a newer well-defined object that the client cannot construct thus preventing the client from inadvertently failing).
Regarding claim 21, Agarwal, Chkodrov, and Issack teach the computer implemented method of claim 18.
Evans teaches wherein the method includes in response to the constructing the object data of the certain class, assigning a reference identifier for the object data of the certain class (Claim 1 maintain, within the memory, a database of well-defined objects and a registry of identifiers), and passing the reference identifier to the second microservice partition (a client-provided identifier Col 3 35-36; Examiner notes: for microservice to invoke other microservices, they need to identify which object to invoke (reference id)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Evans’ bookkeeping of objects in a registry with the system of Agarwal, Chkodrov, and Issack to maintain objects of classes within each generated microservice. A person of ordinary skill in the art would have been motivated to make this combination to provide the system with the advantage of tracking objects at an individual level to allow for specified targeting during function invocation (see Evans Col 2 48-57 an improved technique involves distribution management of well-defined objects using a client-provided identifier. The use of such an identifier enables a server to be aware of the client's limitations. Once the server knows which well-defined objects the client can and cannot handle, the server streams only those well-defined objects that the client is capable of handling. As a result, the client does not receive a newer well-defined object that the client cannot construct thus preventing the client from inadvertently failing).
Regarding claim 22, Agarwal, Chkodrov, and Issack teach the computer implemented method of claim 18.
Issack further teaches assigning the reference identifier to the object data of the parent class (RRL(Remote Reference Layer) − It is the layer which manages the references made by the client to the remote object; Examiner notes: a parent class located in the remote “server” microservice will have a reference in the “client” microservice).
Agarwal, Chkodrov, and Issack do not explicitly teach wherein the method includes in response to the constructing the object data of the certain class, assigning a reference identifier for the object data of the certain class, passing the reference identifier to the second microservice.
However, Evans teaches wherein the method includes in response to the constructing the object data of the certain class, assigning a reference identifier for the object data of the certain class (Claim 1 maintain, within the memory, a database of well-defined objects and a registry of identifiers), passing the reference identifier to the second microservice (a client-provided identifier Col 3 35-36; Examiner notes: for microservice to invoke other microservices, they need to identify which object to invoke (reference id)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Evans’ bookkeeping of objects in a registry with the system of Agarwal, Chkodrov, and Issack to maintain objects of classes within each generated microservice. A person of ordinary skill in the art would have been motivated to make this combination to provide the system with the advantage of tracking objects at an individual level to allow for specified targeting during function invocation (see Evans Col 2 48-57 an improved technique involves distribution management of well-defined objects using a client-provided identifier. The use of such an identifier enables a server to be aware of the client's limitations. Once the server knows which well-defined objects the client can and cannot handle, the server streams only those well-defined objects that the client is capable of handling. As a result, the client does not receive a newer well-defined object that the client cannot construct thus preventing the client from inadvertently failing).
Regarding claim 23, Agarwal, Chkodrov, and Issack teach the computer implemented method of claim 18.
Issack further teaches assigning the reference identifier to the object data of the parent class (RRL(Remote Reference Layer) − It is the layer which manages the references made by the client to the remote object; Examiner notes: a parent class located in the remote “server” microservice will have a reference in the “client” microservice), receiving at the first microservice partition a call for a method of the certain object inherited from the parent class, and responding to the call for the method of the certain object inherited from the parent class using the reference identifier to access the object data of the parent class constructed on the second microservice partition (RMI is provides a mechanism to create distributed application in java. This mechanism allows an object to residing in one system (JVM) to an object running in another JVM. It is an API).
Agarwal, Chkodrov, and Issack do not explicitly teach wherein the method includes in response to the constructing assigning a reference identifier for the object data of the certain class passing the reference identifier to the second microservice partition.
However, Evans teaches wherein the method includes in response to the constructing assigning a reference identifier for the object data of the certain class (Claim 1 maintain, within the memory, a database of well-defined objects and a registry of identifiers), passing the reference identifier to the second microservice partition (a client-provided identifier Col 3 35-36; Examiner notes: for microservice to invoke other microservices, they need to identify which object to invoke (reference id)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Evans’ bookkeeping of objects in a registry with the system of Agarwal, Chkodrov, and Issack to maintain objects of classes within each generated microservice. A person of ordinary skill in the art would have been motivated to make this combination to provide the system with the advantage of tracking objects at an individual level to allow for specified targeting during function invocation (see Evans Col 2 48-57 an improved technique involves distribution management of well-defined objects using a client-provided identifier. The use of such an identifier enables a server to be aware of the client's limitations. Once the server knows which well-defined objects the client can and cannot handle, the server streams only those well-defined objects that the client is capable of handling. As a result, the client does not receive a newer well-defined object that the client cannot construct thus preventing the client from inadvertently failing).
Allowable Subject Matter
Claims 11 and 16 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the
examiner should be directed to HARRISON LI whose telephone number is (703) 756-1469. The
examiner can normally be reached Monday-Friday 9:00am-5:30pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing
using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is
encouraged to use the USPTO Automated Interview Request (AIR) at
http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s
supervisor, Aimee Li can be reached on (571) 272-4169. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/H.L./
Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195