DETAILED ACTION
This office action is in response to amendment filed on 8/28/2026.
Claims 1 and 7 are amended,
Claims 1 – 12 are pending.
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 .
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.
Claim(s) 1 – 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Desai (US 20240289264), in view of Barude (US 20110239194), and further in view of Derdak et al (US 20200241944, hereinafter Derdak).
As per claim 1, Desai discloses: A method of monolith development using microservices, comprising:
creating a container including a coordinating Enterprise Archive (EAR), a Development EAR (Dev EAR), and a services EAR, the coordinating EAR including a first servlet to accept calls from a monolith client and being configured to delegate to both the Dev EAR and to the services EAR, the Dev EAR including a second servlet to accept calls from a Dev EAR client, the Dev EAR being configured to delegate to the services EAR and to receive responses from the service EAR; (Desai [0103]: “In a microservices architecture or the like for an enterprise application, the first microservice may communicate with one or more other microservices including a second microservice. For example, the first microservice may be configured to communicate with a second microservice via a defined framework such as REST, gRPC, RPC, SOAP, GraphQL, and the like… the pre-production environment may include a container orchestration service such as Kubernetes or K3s (i.e., a lightweight implementation of Kubernetes) for deploying a plurality of containerized computing objects as a network-accessible application.”; [0105]: “The second microservice may be any service that forms a part of an enterprise application, and that can be configured to communicate with the first microservice. In some embodiments, the second microservice may include a login service configured to validate user credentials”; figure 6 and [0094]: “The operation of the microservice 616 may be tested at the on-premises deployment 612 and/or the cloud deployment 614. Testing the microservice 616 may output one or more log files that may be stored at a log database 620… The log files may be accessed at a user interface 622 for the pre-production environment 603 (e.g., at the mock server(s) 618, or at a separate logging resource for the mock server(s)). The user interface 622 may include options for debugging the mock servers 618 and/or the microservice 616”. Examiner notes that the first microservice is mapped to the claimed “Dev EAR”, the second microservice is mapped to the claimed “service EAR”, the container orchestration service such as Kubernetes is mapped to the claimed “coordinating EAR”, and the user accessing and debugging microservice through pre-production environment is mapped to the claimed “calls from a monolith client”.)
developing functionality of the Dev EAR as a mocking microservice independent of the both the coordinating EAR and the services EAR, the mocking microservice having a set of methods configured to delegate to a mocking subsystem rather than to the services EAR while developing the functionality of the Dev EAR; (Desai [0103]: “instantiating the first microservice in a pre-production environment such as any of the pre-production environments described herein. After being developed within the design environment, the first microservice may be deployed in the pre-production environment.”; [0104]: “instantiating a mock server for the second microservice in the pre-production environment. The mock server may be configured to mimic operation of the second microservice by providing a communication interface at a predetermined network address (e.g., an HTTP interface or the like) that responds deterministically with one or more predetermined responses to one or more predetermined requests in place of programming logic for the second microservice when deployed in the pre-production environment.”; [0107]: “creating one or more test cases for the first microservice in the pre-production environment. This may, for example, include a script or other code that can be executed in the pre-production environment to cause the first microservice to access the mock server with the one or more predetermined requests.”. Examiner notes that testing a microservice in a pre-production environment is part of development cycle.)
and after developing the functionality of the Dev EAR, enhancing the Dev EAR to run as an integrated microservice within the container to delegate to the services EAR instead of delegating to the mocking subsystem. (Desai [0116]: “As shown in step 826, the method 800 may include deploying the first microservice in a production environment. The production environment may be a computing environment where microservices are deployed to users, such as any of the production environments 504 described in reference to FIG. 5. In some embodiments, the production environment may be a separate environment from the design environment and/or the pre-production environment, and may have a web server or other network resource exposed to a data network for access by end users. The production environment may execute the first microservice as a component of an enterprise application.”; [0099]: “After testing of individual microservices (or groups of microservices) in the pre-production environment 702, the mock server(s) 708 may be replaced with the corresponding microservices 714 and deployed collectively as an enterprise application in the production environment 703, where end users can access and use the enterprise application.”; [0103]: “In a microservices architecture or the like for an enterprise application, the first microservice may communicate with one or more other microservices including a second microservice.”. Examiner notes that the first microservice would resume calling the second service after deployment to the production environment instead of calling the mock server mimicking the second microservice in the pre-preproduction environment.)
Desai did not explicitly disclose:
configuring the set of methods to delegate to the services EAR;
wherein the coordinating EAR to receive responses from both the Dev EAR and from the services EAR,
However, Barude teaches:
configuring the set of methods to delegate to the services EAR; (Barude [0028] – [0029])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Barude into that of Desai in order to configure the set of methods to delegate to the services EAR; Desai [0099] teaches “after testing of individual microservices (or groups of microservices) in the pre-production environment 702, the mock server(s) 708 may be replaced with the corresponding microservices 714 and deployed collectively as an enterprise application in the production environment 703”. Barude [0028] – [0029] teaches replacing function calls with stubs calling a mock system is a commonly known and used methods for conducting tests, before removing the stubs for final production. Therefore, applicants have merely claimed the combination of known parts in the field to achieve the predictable results of conduction tests in preproduction environment before implement it in production environment and is therefore rejected under 35 USC 103.
Derdak teaches:
wherein the coordinating EAR to receive responses from both the Dev EAR and from the services EAR, (Derdak [0068]: orchestrator receives execution state or output from microservice.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Derdak into that of Desai and Barude in order to have the coordinating EAR to receive responses from both the Dev EAR and from the services EAR; Derdak [0068] has shown the claimed limitations are merely commonly known and used functions for orchestrating workflow to microservices, applicants have merely claimed the combination of known parts in the field to achieve the predictable results of conduction tests in preproduction environment before implement it in production environment and is therefore rejected under 35 USC 103.
As per claim 2, the combination of Desai, Barude and Derdak further teach:
The method of claim 1, wherein the second servlet is configured to accept calls from the Dev EAR client both during development of functionality of the Dev EAR and after the Dev EAR has been enhanced to run as the integrated microservice within the container. (Desai [0110] – [0111]: “The logging tool may include a user interface to view the internal state of the monitored service, and/or a database that stores a log of activities based on logging rules or configuration. As an example, the logging tool may monitor the mock server by monitoring log events, received predetermined requests, and active predetermined responses. The logging tool may include debugging tools for debugging the monitored resources. As shown in step 816, the method 800 may include revising the one or more test cases, thereby providing an updated test case. In some embodiments, the test cases may be revised in respond to updates to the first microservice and/or the second microservice, either to test new and previously unexpected use cases, or to address deficiencies or errors identified in previous use cases based on testing within the pre-production environment.”; [0120]: “The logging tool 912 may be configured to monitor the mock server and/or other services within the environment 900.”)
As per claim 3, the combination of Desai, Barude and Derdak further teach:
The method of claim 2, wherein the second servlet is also configured to accept calls from the monolith client after the Dev EAR has been enhanced to run as the integrated microservice within the container. (Desai [0120]: “The logging tool 912 may be configured to monitor the mock server and/or other services within the environment 900.”)
As per claim 4, the combination of Desai, Barude and Derdak further teach:
The method of claim 2, further comprising intercepting calls to the second servlet and delegating authentication of the calls by the Dev EAR to a monolith authentication service. (Desai [0105])
As per claim 5, the combination of Desai, Barude and Derdak further teach:
The method of claim 1, wherein the mocking subsystem is configured to provide responses mocking the services EAR when delegated to by the methods of the Dev EAR. (Desai [0103]: “instantiating the first microservice in a pre-production environment such as any of the pre-production environments described herein. After being developed within the design environment, the first microservice may be deployed in the pre-production environment.”; [0104]: “instantiating a mock server for the second microservice in the pre-production environment. The mock server may be configured to mimic operation of the second microservice by providing a communication interface at a predetermined network address (e.g., an HTTP interface or the like) that responds deterministically with one or more predetermined responses to one or more predetermined requests in place of programming logic for the second microservice when deployed in the pre-production environment.”.)
As per claim 6, the combination of Desai, Barude and Derdak further teach:
The method of claim 1, further comprising creating the Dev EAR client while developing the functionality of the Dev EAR as the mocking microservice; and integrating the Dev EAR client into the monolith client in connection with enhancing the Dev EAR to run as the integrated microservice. (Desai figure 8.)
Claim(s) 7 – 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Desai, in view of Derdak.
As per claim 7, Desai discloses: A method of monolith development using microservices, comprising:
creating a container including a coordinating Enterprise Archive (EAR), a Development EAR (Dev EAR), and a services EAR, the coordinating EAR including a first servlet to accept calls from a monolith client and being configured to delegate to both the Dev EAR and to the services EAR, the Dev EAR including a second servlet to accept calls from a Dev EAR client, the Dev EAR being configured to delegate to the services EAR and to receive responses from the service EAR; (Desai [0103]: “In a microservices architecture or the like for an enterprise application, the first microservice may communicate with one or more other microservices including a second microservice. For example, the first microservice may be configured to communicate with a second microservice via a defined framework such as REST, gRPC, RPC, SOAP, GraphQL, and the like… the pre-production environment may include a container orchestration service such as Kubernetes or K3s (i.e., a lightweight implementation of Kubernetes) for deploying a plurality of containerized computing objects as a network-accessible application.”; [0105]: “The second microservice may be any service that forms a part of an enterprise application, and that can be configured to communicate with the first microservice. In some embodiments, the second microservice may include a login service configured to validate user credentials”; figure 6 and [0094]: “The operation of the microservice 616 may be tested at the on-premises deployment 612 and/or the cloud deployment 614. Testing the microservice 616 may output one or more log files that may be stored at a log database 620… The log files may be accessed at a user interface 622 for the pre-production environment 603 (e.g., at the mock server(s) 618, or at a separate logging resource for the mock server(s)). The user interface 622 may include options for debugging the mock servers 618 and/or the microservice 616”. Examiner notes that the first microservice is mapped to the claimed “Dev EAR”, the second microservice is mapped to the claimed “service EAR”, the container orchestration service such as Kubernetes is mapped to the claimed “coordinating EAR”, and the user accessing and debugging microservice through pre-production environment is mapped to the claimed “calls from a monolith client”.)
developing functionality of the Dev EAR as a semi-integrated microservice independent of the coordinating EAR, the semi-integrated microservice having a set of methods configured to delegate to the services EAR while developing the functionality of the Dev EAR; (Desai [0103]: “instantiating the first microservice in a pre-production environment such as any of the pre-production environments described herein. After being developed within the design environment, the first microservice may be deployed in the pre-production environment.”; [0104]: “instantiating a mock server for the second microservice in the pre-production environment. The mock server may be configured to mimic operation of the second microservice by providing a communication interface at a predetermined network address (e.g., an HTTP interface or the like) that responds deterministically with one or more predetermined responses to one or more predetermined requests in place of programming logic for the second microservice when deployed in the pre-production environment.”; [0107]: “creating one or more test cases for the first microservice in the pre-production environment. This may, for example, include a script or other code that can be executed in the pre-production environment to cause the first microservice to access the mock server with the one or more predetermined requests.”. Examiner notes that testing a microservice in a pre-production environment is part of development cycle.)
and after developing the functionality of the Dev EAR, enhancing the Dev EAR to run as an integrated microservice within the container to include the coordinating EAR. (Desai [0116]: “As shown in step 826, the method 800 may include deploying the first microservice in a production environment. The production environment may be a computing environment where microservices are deployed to users, such as any of the production environments 504 described in reference to FIG. 5. In some embodiments, the production environment may be a separate environment from the design environment and/or the pre-production environment, and may have a web server or other network resource exposed to a data network for access by end users. The production environment may execute the first microservice as a component of an enterprise application.”; [0099]: “After testing of individual microservices (or groups of microservices) in the pre-production environment 702, the mock server(s) 708 may be replaced with the corresponding microservices 714 and deployed collectively as an enterprise application in the production environment 703, where end users can access and use the enterprise application.”.)
Desai did not explicitly disclose:
wherein the coordinating EAR to receive responses from both the Dev EAR and from the services EAR,
Derdak teaches:
wherein the coordinating EAR to receive responses from both the Dev EAR and from the services EAR, (Derdak [0068]: orchestrator receives execution state or output from microservice.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Derdak into that of Desai in order to have the coordinating EAR to receive responses from both the Dev EAR and from the services EAR; Derdak [0068] has shown the claimed limitations are merely commonly known and used functions for orchestrating workflow to microservices, applicants have merely claimed the combination of known parts in the field to achieve the predictable results of conduction tests in preproduction environment before implement it in production environment and is therefore rejected under 35 USC 103.
As per claim 8, the combination of Desai and Derdak further teach:
The method of claim 7, wherein the second servlet is configured to accept calls from the Dev EAR client both during development of functionality of the Dev EAR and after the Dev EAR has been enhanced to run as the integrated microservice within the container. (Desai [0110] – [0111]: “The logging tool may include a user interface to view the internal state of the monitored service, and/or a database that stores a log of activities based on logging rules or configuration. As an example, the logging tool may monitor the mock server by monitoring log events, received predetermined requests, and active predetermined responses. The logging tool may include debugging tools for debugging the monitored resources. As shown in step 816, the method 800 may include revising the one or more test cases, thereby providing an updated test case. In some embodiments, the test cases may be revised in respond to updates to the first microservice and/or the second microservice, either to test new and previously unexpected use cases, or to address deficiencies or errors identified in previous use cases based on testing within the pre-production environment.”; [0120]: “The logging tool 912 may be configured to monitor the mock server and/or other services within the environment 900.”)
As per claim 9, the combination of Desai and Derdak further teach:
The method of claim 8, wherein the second servlet is also configured to accept calls from the monolith client after the Dev EAR has been enhanced to run as the integrated microservice within the container. (Desai [0120]: “The logging tool 912 may be configured to monitor the mock server and/or other services within the environment 900.”)
As per claim 10, the combination of Desai and Derdak further teach:
The method of claim 8, further comprising intercepting calls to the second servlet and delegating authentication of the calls by the Dev EAR to a monolith authentication service. (Desai [0105])
As per claim 11, the combination of Desai and Derdak further teach:
The method of claim 7, wherein the services EAR is configured to execute functions when delegated to by the methods of the Dev EAR. (Desai [0105].)
As per claim 12, the combination of Desai and Derdak further teach:
The method of claim 7, further comprising creating the Dev EAR client while developing the functionality of the Dev EAR as the semi-integrated microservice; and integrating the Dev EAR client into the monolith client in connection with enhancing the Dev EAR to run as the integrated microservice. (Desai figure 8.)
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 – 12 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the 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 CHARLES M SWIFT whose telephone number is (571)270-7756. The examiner can normally be reached Monday - Friday: 9:30 AM - 7PM.
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, April Blair can be reached at 5712701014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
/CHARLES M SWIFT/Primary Examiner, Art Unit 2196
Prosecution Insights