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-12, 14-19, and 22-28 are pending. Claims 13, 20, and 21 are cancelled.
Response to Arguments
Regarding Prior Art Rejections:
Regarding claim 1:
Applicant’s remarks indicate the combination of prior arts Agarwal and Chkodrov is insufficient to teach the claimed identification step involving the monolithic object-oriented computer program including an inheritance chain of classes. Examiner respectfully disagrees.
The examiner’s broadest reasonable interpretation of the claimed inheritance chain of classes includes at least two object-oriented classes with one “child” class deriving characteristics from the other “parent” class. Agarwal discloses in Fig. 2 and associated [0022-0025] the decomposing of a monolithic application containing a chain of classes into two microservice applications each containing a subset of the chain of classes. The details of the relationships within the chain of classes of Agarwal are left generic as Agarwal merely describes the relations as dependencies between software modules/classes. However, Agarwal further goes to characterize the head classes of the resulting microservices as “parent classes” with dependent nodes being characterized as “child nodes” which pushes towards the relationship between the classes as being one of a child inheriting characteristics of a parent. The examiner acknowledges that the relationships between parent and child classes in Agarwal are not clearly defined as being that of classical object-oriented inheritance. However, Agarwal discloses that the applications in their specifications may be within an object oriented context: ([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, and/or in assembly/machine language). Examiner introduces Chkodrov as prior art to solidify the ambiguity of Agarwal’s class dependency. Chkodrov is relied on to explicitly teach the dependencies of Agarwal may very well be object-oriented inheritance relations between a parent and child class as one of ordinary skill in the art of software development will recognize class inheritance as being a fundamental concept of the object-oriented programming within Agarwal.
Applicant asserts the combination of Agarwal and Chkodrov does not disclose the identifying of the inheritance chain of classes as part of the examination of the monolithic program and subsequent generation of microservices. Examiner respectfully disagrees. Having established Chkodrov as teaching the inheritance relationships between object-oriented classes, the cited portion of Agarwal’s Fig. 2 and supporting specification disclose identification and extraction of subsets of the dependency chain into standalone services. This process at minimum requires identification of classes of the original dependency chain to include in each resulting generated microservice so that each microservice functions independently. Indicated subject within Agarwal and Chkodrov are sufficient to teach the claimed steps of examining and generating based on examining without clarification of the claimed examining, identifying, or generating steps.
Applicant further alleges the rationale to combine Chkodrov’s teachings of inheritance within the context of Agarwal’s decomposing of monolithic application class chains into microservice class chains is insufficient to bridge the gap of obviousness. Examiner respectfully disagrees because Agarwal itself discloses that applications may utilize object-oriented programming ([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, and/or in assembly/machine language). Chkodrov is relied upon to further expand upon the concept of inheritance within object-oriented programming in which Agarwal is largely silent to. A person having ordinary skill in the art would have come to the conclusion of obviousness due to having access to all publicly available art including Chkodrov.
Regarding claim 12:
Applicant’s remarks assert the combination of Agarwal and Chkodrov do not teach the claimed constructing object data of the first and second classes on their respective microservice partitions. Examiner respectfully disagrees.
The examiner’s broadest reasonable interpretation of constructing object data of a class includes any storing, declaring, installing, configuring, creating, instantiating, programming, coding of any data with respect to a class of objects. It is unclear whether the claimed object data of a first/second class is intended to represent class file data defining objects of a class or an object’s data itself as the claimed “object data” is not referencing a particular antecedent object. As a result, object data of a class is interpreted broadly to be any data related to a class because classes themselves define objects of their respective classes. Therefore, it can be said that storing in a microservice class code defining classes of objects is able to be construed as constructing object data of a class. Agarwal’s specification of Fig. 2 discloses the storing of code defining multiple classes in their respective microservice partitions [0025]. The cited portion teaches class H being stored in microservice 212 and class K being stored in microservice 214.
Applicant further asserts that Agarwal and Chkodrov do not teach the second class and the first class are in inheritance class relation with the rationale not bridging the gap of obviousness. Examiner respectfully disagrees.
The claim limitation relating to inheritance does not limit the first and second class as needing to be in an inheritance class relation with each other. Specifically, it is not claimed that the first and second class are in an inheritance class relation. Therefore, the rejection acknowledges that class H and K in Agarwal are in some form of dependency relation. Chkodrov is then combined with Agarwal to teach that the respective dependency relations of classes H and K are able to be inheritance relations as one of ordinary skill in the art would have found it obvious to have done so as Agarwal already recites usage of object-oriented programming in applications [0045] and Chkodrov was publicly available to a person having ordinary skill in the art of software development at the time of filing.
Regarding claim 5:
Applicant’s arguments are found to be persuasive as examiner finds that the prior art of record does not render obvious claimed subject matter involving the assigning of the reference identifier to the object data of the second class and wherein the object data of the first class and the object data of the second class define an object of the first class. Claim 5 is 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.
Regarding claim 6:
Applicant’s arguments are found to be persuasive as examiner finds that the prior art of record does not render obvious claimed subject matter wherein the object data of the first class and the object data of the second class define an object of the first class. Claim 6 is 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.
Regarding claims 8, 9, and 10:
Applicant’s arguments are found to be persuasive as examiner finds that the prior art of record does not render obvious claimed subject matter for reasons similar to claim 6. Claims 8, 9, and 10 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.
Regarding claims 18, 24, and 25:
Examiner appreciates applicant’s amendments clarifying the claimed invention. Applicant’s arguments are found to be persuasive. Claims 18, 24, 25, and all claims dependent are indicated as allowable as applicant’s clarifying amendments further distinguish the claimed invention from the prior art of record.
Applicant is encouraged to contact examiner prior to filing an after-final response to discuss claim amendments to expedite prosecution and allowance.
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, and 12 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 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).
Claims 3, 4, 26, and 27 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 26, Agarwal and Chkodrov teach the computer implemented method of claim 12.
Chkodrov further teaches wherein the object data of the first class and the object data of the second class define respective portions of a same object (Fig 5 Instance of Class C contains portions of its base/parent classes as well as its own members 128; An important aspect of the use of classes in object-oriented programming is the concept of inheritance. A class may be defined as being derived from another class that is referred to as its "base 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 30-39).
Agarwal and Chkodrov do not explicitly teach wherein a reference identifier is assigned to the object data of the first class and shared with the second microservice partition for association with the object data of the second class.
However, Evans teaches wherein a reference identifier is assigned to the object data of the first class (Claim 1 maintain, within the memory, a database of well-defined objects and a registry of identifiers) and shared with the second microservice partition for association with the object data of the second class (Fig 4 96 Provide all of the well-defined objects from the database to the client device).
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 and Chkodrov 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 existing 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 27, Agarwal and Chkodrov teach the computer implemented method of claim 12.
Chkodrov further teaches wherein the constructing of the object data of the first class includes 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 (FIG. 5 shows how the respective objects of the three classes B1, B2, and C appear in the memory. It should be noted that the memory images of these objects are not changed for supporting class replacements, i.e., they are the same as those that would be generated with the existing C++ compilers without class replacement. This allows the usage of the instances of the replaceable classes from functions compiled with the existing compilers. Since both the classes B1 and B2 have virtual functions, their objects 120 and 122 have pointers 121 and 123, respectively, to their associated virtual function tables. Because the class C inherits from B1 and B2, its object 124 has a first part 126 for the functions and data inherited from B1 and B2, and a second part 128 for its own data members. If an instance of the class C is used via a pointer of type C* or B1*, the virtual methods will be called using the pointer 129 to the vtable for B1 and C methods. If the same instance is used via a pointer of type B2*, the virtual methods will be called using the vtable pointer 130, which is at an offset of 8 bytes from the pointer "this" of the instance 124, Col 10 20-39), wherein the constructing of the object data of the second class includes allocating memory space of a runtime memory of the second microservice partition to the object data of the second class and writing the object data of the second class to the allocated memory space (Fig 5; The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices, Col 3 62-67; Examiner notes: objects of other classes within the inheritance tree are able to be created in remote memory storage devices in a similar way to the structure of Fig 5).
Agarwal and Chkodrov do not explicitly teach wherein a reference identifier is assigned to the object data of the first class and shared with the second microservice partition for association with the object data of the second class.
However, Evans teaches wherein a reference identifier is assigned to the object data of the first class (Claim 1 maintain, within the memory, a database of well-defined objects and a registry of identifiers) and shared with the second microservice partition for association with the object data of the second class (Fig 4 96 Provide all of the well-defined objects from the database to the client device).
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 and Chkodrov 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 existing 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).
Claim 17 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 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 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 and 15 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.).
Allowable Subject Matter
Claims 5-11, 16, and 28 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.
Claims 18, 19, and 22-25 are allowed.
Conclusion
Applicant's amendment necessitated any new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
Prosecution Insights