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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 3/06/2026 has been entered.
Response to Amendment
This communication is in response to the RCE filed 3/06/2026. Claims 1, 4-12, 15-17, and 20 remain pending in the application and as such are being considered on the merits.
Response to Arguments
Applicant’s arguments filed 3/06/2026 have been fully considered and are persuasive. Within their remarks, Applicant argues that none of the previously relied upon prior art teaches or suggests split requests corresponding to different micro-services. However, upon further search and consideration, a new ground of rejection is made in view of newly found prior art, Peruri et al. (US 20160337278), combined with the previously cited prior art. The Examiner contends that Peruri teaches and/or suggests that split requests/sub-requests can correspond to separate micro-services (any number of microservice nodes may be used to process a single sub-request from a sub-request queue, therefore each microservice node handles a separate sub-request or sub-request process par. 0235 – 0240). Therefore, the rejection under 35 U.S.C. 103 will be maintained under this new combination of references.
For further details please refer to the 103 rejection section below.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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, 4-6, 11-12, 15-17, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhao et al. (US 20180349037) in view of Racunas et al. (US 20070168712), Unnikrishnan et al. (US 8296774), Cardona et al. (US 9002970), and Peruri et al. (US 20160337278).
Regarding claims 1, 12, and 17, Zhao teaches: A computer system / A computer program product / A computer-implemented method (see par. 0061), comprising: receiving, by one or more processors, an initial request from a client (receiving a read/write request from users par. 0026 - 0029); splitting, by one or more processors, the initial request into a plurality of split requests based on a business logic (splitting write request into plurality of sub-requests based on size logic par. 0050 – 0057); merging, by one or more processors, the one or more candidate groups of split requests into the one or more merged requests (merging sub-requests together after determination that sub-requests can be merged par. 0053 – 0057);
Zhao does not explicitly teach micro-services, mapping information relating to the split requests, and sending merged requests to specific nodes.
However, Racunas teaches: sending, by one or more processors, the one or more merged requests to one or more corresponding nodes for processing (once requests are merged, sending the merged request to the device par. 0018 – 0031).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhao with the teachings of Racunas since the mapping and merging of requests as outlined in Racunas prevents against timing errors associated with the requests as well as using various logic implementations to coordinate responses. It would further be obvious to one of ordinary skill in the art that the requests of Racunas, while not explicitly stated to be split, could first be split by the implementation of Zhao and then further processed through the steps of Racunas.
Neither Zhao nor Racunas explicitly teach the steps of acquiring mapping information associated with split requests.
However, Unnikrishnan teaches: Acquiring, by one or more processors, mapping information associated with the plurality of split requests (topology service response is in response to the topology service request and from a given topology endpoint Col. 6 lines 34 – 44), wherein the mapping information includes a mapping of each split request to a corresponding node for processing the split request (the information provided within the topology service response specifies a plurality of target service endpoint URIs, the URI request module then stores the topology service endpoint URIs, conforming to the service definition of the topology service Col. 6 Lines 34 – 55);
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhao and Racunas with the teachings of Unnikrishnan since the topology service request/responses in a server farm environment allows for the use of load balancing that ensures that requests are sent to the correct endpoint URI without degrading the server’s performance. This would further enhance the steps/teachings of Zhao and Racunas by applying load balancing through potential merging/splitting of requests before sending to the proper destination/node.
None of Zhao, Racunas, or Unnikrishnan explicitly teach determining candidates for merging.
However, Cardona teaches: determining (ACPI modules communicating to each other through an out-of-band process to detect and determine messages flowing through multiple sockets at a given time represent a session between the two applications Col. 4 Line 58 – Col. 5 Line 7), by one or more processors, one or more groups of split requests that are candidates for merger into one or more merged requests (a plurality of concurrent application socket messages are intercepted prior to transmission to a common application socket destination, each message having a payload. The payloads are then aggregated into one or more consolidated payloads of one or more messages and transmitted to the common application socket destination See claim 1 as well as Col. 4 Line 58 – Col. 5 Line 7 and Col. 2 Lines 20 – 22), wherein a group of split requests is a candidate for merger if each split request in the group of split requests is mapped to a common node (ACPM acts as aggregation mechanism for messages heading to a common destination Col. 3 Line 60 – Col. 4 Line 6 and Col. 4 Line 58 – Col. 5 Line 7);
It would be prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application that the teachings of Cardona could be used to enhance Zhao, Racunas, and Unnikrishnan by using a determination through ACPI modules for messages being sent to a common socket/destination and using said determination as a way of determining which messages/requests should be merged together. This results in many benefits, such as reduced CPU costs, application and kernel concurrency, and avoiding recompiling or changing APIs.
None of Zhao, Racunas, Unnikrishnan, or Cardona teach each split request of the plurality of split requests corresponds to a different micro-service.
However, Peruri teaches: wherein each split request of the plurality of split requests corresponds to a different micro-service (any number of microservice nodes may be used to process a single sub-request from a sub-request queue, therefore each microservice node handles a separate sub-request or sub-request process par. 0235 – 0240)
It would be prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application that the teachings of Peruri would enhance the prior art combination by making the micro-service database system fast and highly scalable as having microservice nodes handle individual and separate sub-requests allows for a more deterministic and reliable system. Further, it would be obvious to one of ordinary skill in the art that the split requests, as outlined by the prior art combination, could be handled within a computing pool consisting of microservice nodes, as outlined in Peruri, for increasing the rate of sub-request/split request processing.
Regarding claims 4 and 15, Racunas teaches: receiving, by one or more processors, responses to the one or more merged requests from the one or more corresponding nodes (one or more processors receiving responses from lockstep memories or I/O devices (AKA nodes) par. 0028 – 0029).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhao with the teachings of Racunas since the mapping and merging of requests as outlined in Racunas prevents against timing errors associated with the requests as well as using various logic implementations to coordinate responses. It would further be obvious to one of ordinary skill in the art that the requests of Racunas, while not explicitly stated to be split, could first be split by the implementation of Zhao and then further processed through the steps of Racunas.
Regarding claim 5, Racunas teaches: wherein at least one of the responses to the one or more merged requests from the one or more corresponding nodes is a merged response (responses from ‘farther memory’ are received by ‘closer memory’ and can then be merged and sent if they match par. 0025).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhao with the teachings of Racunas since the mapping and merging of requests as outlined in Racunas prevents against timing errors associated with the requests as well as using various logic implementations to coordinate responses. It would further be obvious to one of ordinary skill in the art that the requests of Racunas, while not explicitly stated to be split, could first be split by the implementation of Zhao and then further processed through the steps of Racunas.
Regarding claim 6, Racunas teaches: wherein the merged response is merged by a node (‘closer memory’ node merges its own response with ‘farther memory’ node before sending par. 0025).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhao with the teachings of Racunas since the mapping and merging of requests as outlined in Racunas prevents against timing errors associated with the requests as well as using various logic implementations to coordinate responses. It would further be obvious to one of ordinary skill in the art that the requests of Racunas, while not explicitly stated to be split, could first be split by the implementation of Zhao and then further processed through the steps of Racunas.
Regarding claims 11 and 16, Racunas teaches: merging, by one or more processors, the one or more merged responses into a final response (if received response matches local response, merging responses together and sending par. 0018 – 0031); and returning, by one or more processors, the final response to the client corresponding to the initial request (sending merged response to the requesting processor par. 0025).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhao with the teachings of Racunas since the mapping and merging of requests as outlined in Racunas prevents against timing errors associated with the requests as well as using various logic implementations to coordinate responses. It would further be obvious to one of ordinary skill in the art that the requests of Racunas, while not explicitly stated to be split, could first be split by the implementation of Zhao and then further processed through the steps of Racunas.
Regarding claim 20, Racunas teaches: receive responses to the one or more merged requests from the one or more corresponding nodes (receiving responses from nodes par. 0018 – 0031); merge, by one or more processors, the one or more merged responses into a final response (if received response matches local response, merging responses together and sending par. 0018 – 0031); and returning, by one or more processors, the final response to the client corresponding to the initial request (sending merged response to the requesting processor par. 0025).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhao with the teachings of Racunas since the mapping and merging of requests as outlined in Racunas prevents against timing errors associated with the requests as well as using various logic implementations to coordinate responses. It would further be obvious to one of ordinary skill in the art that the requests of Racunas, while not explicitly stated to be split, could first be split by the implementation of Zhao and then further processed through the steps of Racunas.
Claim(s) 7 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhao et al. (US 20180349037) in view of Racunas, Unnikrishnan, Cardona, and Peruri, and further in view of Taguchi et al. (US 20040024808).
Regarding claim 7, Taguchi teaches: wherein the one or more merged requests are split into a plurality of requests by a proxy deployed on the node (secondary site uses database proxy to split data access requests from operators and forward them to local database servers par. 0031).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhao, Racunas, Unnikrishnan, Cardona, and Peruri with the teachings of Taguchi since the database proxy outlined by Taguchi provides simultaneous capabilities for nodes to split requests as well as merge responses. This further enhances the nodes of Zhao and Racunas by enabling the nodes to work with an attached proxy to enable operators to access data from multiple databases using a single request and return merged replies.
Regarding claim 8, Taguchi teaches: wherein the merged response is merged from a plurality of responses corresponding to the plurality of requests split from the one or more merged requests by the proxy deployed on the node (secondary site uses database proxy to provide access to data, further the DB proxy merges replies from the multiple servers before it returns a reply to the operator par. 0031, and 0055 - 0056).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhao, Racunas, Unnikrishnan, Cardona, and Peruri with the teachings of Taguchi since the database proxy outlined by Taguchi provides simultaneous capabilities for nodes to split requests as well as merge responses. This further enhances the nodes of Zhao and Racunas by enabling the nodes to work with an attached proxy to enable operators to access data from multiple databases using a single request and return merged replies.
Claim(s) 9 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhao et al. (US 20180349037) in view of Racunas, Unnikrishnan, Cardona, and Peruri, and further in view of Busayarat et al. (US 20170104838)
Regarding claim 9, Busayarat teaches: wherein each merged request is identified by a mergedID (requests for same data, when multiplexed into a single request, and later possible de-multiplexed, maintains requestor-to-provider node ID(s) relationship par. 0092, these ID(s) relating to batched/multiplexed/combined requests for the same data item par. 0127, ensuring that a response is able to be returned to each separate request for data par. 0092).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhao, Racunas, Unnikrishnan, Cardona, and Peruri with the teachings of Busayarat since the use of IDs in Busayarat would enhance the combination through providing the capabilities for requests and responses to be matched with IDs in a mapping which can then be compared/marked to ensure data is sent to the correct nodes.
Regarding claim 10, Busayarat teaches: wherein each merged response shares a same mergedID with a corresponding merged request (responses include requestor ID-to-provider node ID map that matches provider node ID to requestor ID par. 0113 – 0116).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhao, Racunas, Unnikrishnan, Cardona, and Peruri with the teachings of Busayarat since the use of IDs in Busayarat would enhance the combination through providing the capabilities for requests and responses to be matched with IDs in a mapping which can then be compared/marked to ensure data is sent to the correct nodes.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Riand (US 20210173878) which outlines splitting requests into aggregated sub-requests being handled by micro-services which they are connected to.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORDAN SCOTT MOTTER whose telephone number is (703)756-1550. The examiner can normally be reached Monday - Friday 7:30 a.m. - 4:30 p.m..
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, Pierre Vital can be reached at 571-272-4215. 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.
/J.S.M./ Examiner, Art Unit 2198
/PIERRE VITAL/ Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights