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 .
Application # 18/435,947 was filed on 2/7/2024.
Claims 1-20 are subject to examination.
An IDS filed on 3/3/2025 has been fully considered and entered by the Examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 6, 15 respectively rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8, 17 respectively of U.S. Patent No. 12,184,480. Although the claims at issue are not identical, they are not patentably distinct from each other because they contain similar subject matter as follows:
“detect a transmission of a first network operation from an originating microservice software application to a first microservice software application of a set of microservice software applications, wherein (i) the first network operation is configured to be provided as input to the first microservice software application and (ii) the first microservice software application generates a second network operation as output, using the first network operation, to be transmitted to a second microservice software application of the set of microservice software applications, the second microservice software application being a destination software application; receiving a first log file associated with a processing of the first network operation at the first microservice software application; storing, in a database, the first log file in association with the first microservice software application; determining a validation process to be performed on the first log file using an identifier associated with the originating software application and an identifier associated with the destination microservice software application; retrieving, from the database, the first log file to perform the determined validation process on the first log file with respect to a set of modifications between the first network operation and the second network operation using (i) the first network operation and (ii) the second network operation; and in response to detecting that the determined validation process results in a failure to validate the first log file, preventing the second network operation from being transmitted to the second microservice software application of the set of microservice software applications”
Claims 1, 2, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, respectively rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 2, 3, 1, 5, 6, 7, 4, 7, 8, 9, 10, 11, 12, 13, 14, 11, 14respectively of U.S. Patent No. 11,924,027. Although the claims at issue are not identical, they are not patentably distinct from each other because they contain similar subject matter as follows:
“detect a transmission of a first network operation from an originating microservice software application to a first microservice software application of a set of microservice software applications, wherein (i) the first network operation is configured to be provided as input to the first microservice software application and (ii) the first microservice software application generates a second network operation as output, using the first network operation, to be transmitted to a second microservice software application of the set of microservice software applications, the second microservice software application being a destination software application; receiving a first log file associated with a processing of the first network operation at the first microservice software application; storing, in a database, the first log file in association with the first microservice software application; determining a validation process to be performed on the first log file using an identifier associated with the originating software application and an identifier associated with the destination microservice software application; retrieving, from the database, the first log file to perform the determined validation process on the first log file with respect to a set of modifications between the first network operation and the second network operation using (i) the first network operation and (ii) the second network operation; and in response to detecting that the determined validation process results in a failure to validate the first log file, preventing the second network operation from being transmitted to the second microservice software application of the set of microservice software applications”
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-10, 15-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jentsch et al. U.S. Patent Publication # 2013/0174181 (hereinafter Jentsch) in view of Roche et al. U.S. Patent # 8,832,640 (hereinafter Roche)
With respect to claim 1, Jentsch teaches a system for reducing wasted computational resources by detecting network operation validation anomalies in conglomerate-application-based ecosystems, the system comprising:
-at least one hardware processor; and at least one non-transitory memory storing instructions, which, when executed by the at least one hardware processor, cause the system to:
-detect a transmission of a first network operation (i.e. input) from an originating microservice software application (i.e. client application) to a first microservice software application (i.e. business application) of a set of microservice software applications, wherein (i) the first network operation is configured to be provided as input to the first microservice software application (i.e. first network operation being input which is forwarded by the runtime UI application to the business application) (Paragraph 17, 19-20) and (ii) the first microservice software application generates a second network operation as output (i.e. output such as error message), using the first network operation (i.e. input), to be transmitted to a second microservice software application (i.e. runtime UI application or client application) of the set of microservice software applications, the second microservice software application being a destination software application (i.e. error message is sent by the business application as an output and runtime UI application may forward or output such error message within field of user interface to the client application) (Paragraph 17, 19-20). Examiner would like to point out that field of user interface is inside runtime UI application hence that is the second application. Also, claim language does not differentiate or state that originating microservice software application is different or cannot be same as the second microservice software application.
receiving a first log file (i.e. error message) associated with a processing of the first network operation at the first microservice software application (Paragraph 19-20)
the first log file (i.e. error message) in association with the first microservice software application (i.e. business application)(Paragraph 34)
determining a validation process to be performed on the first log file using an identifier associated with the originating software application and an identifier associated with the destination microservice software application (Paragraph 30)
retrieving, the first log file to perform the determined validation process on the first log file with respect to a set of modifications between the first network operation and the second network operation using (i) the first network operation and (ii) the second network operation (Paragraph 19-20, 23-25); and
in response to detecting that the determined validation process results in a failure to validate the first log file (i.e. error message), preventing the second network operation from being transmitted to the second microservice software application of the set of microservice software applications (Paragraph 19-20)
Jentsch does not explicitly teach storing, in a database, the first log file in association with the first microservice software application; and retrieving from the database.
Roche teaches storing in a database, the first log file (i.e. log file) in association with the first microservice software application (i.e. purify/pattern insight)(column 3 lines 35-43, 59-67)(column 4 lines 1-10); retrieving from the database, the first log file to perform the determined validation process (column 4 lines 9-11). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Roche’s teaching in Jentsch’s teaching to come up with storing in a database the first log file wherein the log file contains error messages. The motivation for doing so would be output from the SQL queries could be generated in different formats including the ASCII format, XML and the like.
With respect to claim 2, Jentsch and Roche teaches the system of claim 1, but Jentsch further teaches further comprising the instructions to: in response to the detection indicating a successful validation of the first log file, enabling the second network operation to be transmitted to the second microservice software application (Paragraph 23)
With respect to claim 3, Jentsch and Roche teaches the system of claim 1, but Jentsch further teaches further comprising the instructions to: in response to detecting that the validation process results in the failure to validate the first log file, generating for display at a graphical user interface (GUI), a message indicating the failure to validate the first log file (Paragraph 19-20).
With respect to claim 4, Jentsch and Roche teaches the system of claim 1, but Jentsch further teaches wherein determining the validation process to be performed on the first log file further comprises: accessing a data structure indicating validation processes to be performed on the first log file that are associated with the originating microservice software application and the destination microservice software application (paragraph 17, 19-20, 24)
With respect to claim 5, Jentsch and Roche teaches the system of claim 1, but Jentsch further teaches wherein detecting that the determined validation process results in a failure to validate the first log file further comprises: determining whether the second network operation comprises a first modification with respect to the first network operation (Paragraph 19-20, 23-25); and in response to the second network operation failing to comprise the first modification with respect to the first network operation, detecting that the determined validation process results in a failure to validate the first log file (Paragraph 19-20, 23-25)
With respect to claim 6, Jentsch teaches a method for reducing wasted computational resources by detecting network operation validation anomalies in conglomerate-application-based ecosystems, the method comprising:
-providing a first network operation (i.e. input) from an originating software application (i.e. client application) to a first software application (i.e. business application) of a set of software applications, wherein (i) the first network operation is configured to be provided as input to the first software application (i.e. first network operation being input which is forwarded by the runtime UI application to the business application) (Paragraph 17, 19-20) and (ii) the first software application generates a second network operation as output (i.e. output such as error message), using the first network operation, to be provided to a second software application (i.e. runtime UI application or client application) of the set of software applications, the second software application being a destination software application (i.e. error message is sent by the business application as an output and runtime UI application may forward or output such error message within field of user interface to the client application) (Paragraph 17, 19-20). Examiner would like to point out that field of user interface is inside runtime UI application hence that is the second application. Also, claim language does not differentiate or state that originating microservice software application is different or cannot be same as the second microservice software application.
receiving a first message (i.e. error message) associated with a processing of the first network operation at the first software application (Paragraph 19-20)
determining a validation process to be performed on the first message using an identifier associated with the originating software application and an identifier associated with the destination software application (Paragraph 30)
performing the determined validation process on the first message using (i) the first network operation, (ii) the second network operation, and (iii) the first message (Paragraph 19-20, 23-25); and
in response to detecting that the determined validation process results in a failure to validate the first message (i.e. error message), preventing the second network operation from being provided to the second software application of the set of software applications, wherein the determined validation process results in the failure to validate the first message is detected(Paragraph 19-20)
Jentsch does not explicitly teach storing, in a database, the first log file in association with the first microservice software application; and retrieving from the database.
Roche teaches storing in a database, the first log file (i.e. log file) in association with the first microservice software application (i.e. purify/pattern insight)(column 3 lines 35-43, 59-67)(column 4 lines 1-10); retrieving from the database, the first log file to perform the determined validation process (column 4 lines 9-11). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Roche’s teaching in Jentsch’s teaching to come up with storing in a database the first log file wherein the log file contains error messages. The motivation for doing so would be output from the SQL queries could be generated in different formats including the ASCII format, XML and the like.
With respect to claim 7, Jentsch and Roche teaches the method of claim 6, but Jentsch further teaches further comprising: in response to the detection indicating a successful validation of the first message, enabling the second network operation to be transmitted to the second software application, wherein the successful validation of the first message is detected (Paragraph 23)
With respect to claim 8, Jentsch and Roche teaches the method of claim 6, but Jentsch further teaches further comprising: in response to detecting that the validation process results in the failure to validate the first message, generating for display at a graphical user interface (GUI), a message indicating the failure to validate the first message, wherein the validation process resulting in the failure to validate the first message is detected (Paragraph 19-20)
With respect to claim 9, Jentsch and Roche teaches the method of claim 6, but Jentsch further teaches wherein determining the validation process to be performed on the first message further comprises: accessing a data structure indicating validation processes to be performed on the first message that are associated with the originating software application and the destination software application (paragraph 17, 19-20, 24)
With respect to claim 10, Jentsch and Roche teaches the method of claim 6, but Jentsch further teaches wherein detecting that the determined validation process results in a failure to validate the first message further comprises: determining whether the second network operation comprises a first characteristic with respect to the first network operation (Paragraph 19-20, 23-25); and in response to the second network operation failing to comprise the first characteristic with respect to the first network operation, detecting that the determined validation process results in a failure to validate the first message, wherein the second network operation fails to comprise the first characteristic with respect to the first network operation (Paragraph 19-20, 23-25)
With respect to claim 15, it teaches same limitation as claim 6, therefore rejected under same basis.
With respect to claim 16, Jentsch and Roche teaches the media of claim 15, but Jentsch further teaches wherein the instructions, when executed by the one or more processors, further cause operations comprising: in response to the detection indicating a successful validation of the first message, enabling the second network operation to be transmitted to the second software application (Paragraph 23)
With respect to claim 17, Jentsch and Roche teaches the media of claim 15, but Jentsch further teaches wherein the instructions, when executed by the one or more processors, further cause operations comprising: in response to detecting that the validation process results in the failure to validate the first message, generating for display at a graphical user interface (GUI), a message indicating the failure to validate the first message (Paragraph 19-20)
With respect to claim 18, Jentsch and Roche teaches the media of claim 15, but Jentsch further teaches wherein determining the validation process to be performed on the first message further comprises: accessing a data structure indicating validation processes to be performed on the first message that are associated with the originating software application and the destination software application (paragraph 17, 19-20, 24)
With respect to claim 19, Jentsch and Roche teaches the media of claim 15, but Jentsch further teaches wherein detecting that the determined validation process results in a failure to validate the first message further comprises: determining whether the second network operation comprises a first characteristic with respect to the first network operation (Paragraph 19-20, 23-25); and in response to the second network operation failing to comprise the first characteristic with respect to the first network operation, detecting that the determined validation process results in a failure to validate the first message (Paragraph 19-20, 23-25)
Claim objections
Claims 11-14, 20 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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
A). Hockenberry et al. U.S. Patent Publication # 2007/0174810
B). Ginter et al. U.S. Patent Publication # 2005/0015624
C). Akyol et al. U.S. Patent Publication # 2020/0127973
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DHAIRYA A PATEL whose telephone number is (571)272-5809. The examiner can normally be reached M-F 7:30am-4:00pm.
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, Kamal B Divecha can be reached at 571-272-5863. 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.
DHAIRYA A. PATEL
Primary Examiner
Art Unit 2453
/DHAIRYA A PATEL/ Primary Examiner, Art Unit 2453