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 .
DETAILED ACTION
This action is response to the Remarks filed on 08/26/2026.
Claims 1-20 are pending in this Office Action in which claims 1-20 are rejected and claims 5-8, 10 and 17-19 are further objected to. Claims 1, 13 and 20 are independent claims.
Priority
Acknowledged is that this Application claims the benefit of priority from parent Application 17899381, filed 08/30/2022 now the U.S. Patent 12292880, issued 05/06/2025.
Response to Arguments
Applicant's arguments filed 08/26/2026 have been fully considered. The double patenting rejections is updated with claims as currently amended and is hereby maintained.
As per amendments made to independent claims, the amendments is not a full incorporation of subject matters from claims 5 and 3, the Examiner respectfully introduced a reference published to ZIZLAVSKY for curing the deficiency of previously cited Brewer in view of LANDER reference(s). Furthermore, the Examiner interpreted a removal of computer node from service as a decommissioning of the node.
Double Patenting Rejections
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 non-statutory 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-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-20 of U.S. Patent 12292880 (issued 07/08/2025 to the parent application 17899381, filed 09/25/2023). Although the conflicting are not patentably distinct from each other because since the claims of the U.S. Patent 12292880 contain elements of the claims of the instant application, and as such, anticipate the claims of the instant application. The conflicting claims between the instant application and the granted U.S. Patent 12292880 are listed in parallel in below table.
Patent 12292880 claims 1-20
Instant Application claims 1-20
1. A method for performing search system upgrades, the method comprising:
processing, by a computer processing system, a software upgrade for a search system cluster distributed over one or more nodes, the one or more nodes comprising current search system data nodes;
allocating, by the computer processing system, at least a set of one or more search system data nodes for the software upgrade including at least one upgraded search system data node;
receiving, by the computer processing system during the software upgrade, transaction data for a transaction processed by the computer processing system, and receiving search requests to be executed by the search system cluster;
performing, by the computer processing system, ingestion of all historical transaction data comprising a dual write of the transaction data comprising:
storing and indexing the transaction data in the current search system data nodes; and
storing and indexing the transaction data separately from the current search system data nodes in the at least one upgraded search system data node; and
processing, by the computer processing system, the search requests by the search system cluster against both the current search system data nodes and the at least one upgraded search system data node until the software upgrade is determined to be complete when first search results from the current search system data nodes are compared and match second search results from the at least one upgraded search system data node; and
in response to determining that the software upgrade is complete, decommissioning, by the computer processing system, at least the current search system data nodes and processing new search requests against the at least one upgraded search system;
2. The method of claim 1, further comprising:
performing ingestion of historical transaction data to the at least one upgraded search system data node; and
when the ingestion of the historical transaction data to the at least one upgraded search system data node is complete and the software upgrade is determined to be complete,
decommissioning at least the current search system data nodes and processing new search requests using the at least one upgraded search system data node.
3. The method of claim 2, further comprising:
accessing one or more historical transaction data from a search system snapshot; and
performing ingestion of the accessed historical transaction data comprising storing and indexing the accessed historical transaction data in the at least one upgraded search system data node.
4. The method of claim 2, wherein the software upgrade is determined to be complete further comprising:
determining that all historical transaction data has been ingested by the at least one upgraded search system data node;
after all historical transaction data has been ingested by the at least one upgraded search system data node, processing one or more new search requests against both the current search system data nodes and the at least one upgraded search system data node;
comparing first search results returned using the current search system data nodes with second search results returned using the at least one upgraded search system data node; and
when the first search results match the second search results, determining that the software upgrade is complete.
5. The method of claim 4, wherein comparing the first search results returned using the current search system data nodes with the second search results returned using the at least one upgraded search system data node, further comprises:
receiving a search request for a specific transaction data; and
determining a search results match when the specific transaction data is returned in both the first search results match the second search results.
6. The method of claim 4, wherein comparing the first search results returned using the current search system data nodes with the second search results returned using the at least one upgraded search system data node, further comprises:
receiving a search request for a ranked listing of search results; and
determining a search results match when a first ranked search result returned using the current search system data nodes has a threshold amount of similarity to a second ranked search result returned using the at least one upgraded search system data node.
7. The method of claim 4, wherein comparing first search results returned using the current search system data nodes with second search results returned using the at least one upgraded search system data node, further comprises:
comparing search results obtained using the current search system data nodes and using the at least one upgraded search system data node over a period of time; and
when the search results match over a threshold period of time, determining that the first search results match the second search results.
8. The method of claim 4, further comprising:
when the first search results do not match the second search results, decommissioning the allocated set of one or more search system data nodes including the at least one upgraded search system data node; and
restarting the software upgrade by allocating, by the computer processing system, at least a second set of one or more search system data nodes for the software upgrade including at least one second upgraded search system data node.
9. The method of claim 1, wherein the storing and indexing the transaction data in both the current search system data nodes and the at least one upgraded search system data node comprises:
receiving, by the computer processing system, at least one request to delete identified transaction data from a data store of transaction records;
transforming the at least one request to delete the identified transaction data to an insertion of the identified transaction data with a deletion flag set to true;
ingesting the identified transaction data with the deletion flag, including storing and indexing the identified transaction data, by the at least one upgraded search system data node; and
when the software upgrade is determined to be complete, performing garbage collection to remove any transaction data from the at least one upgraded search system data node with a corresponding deletion flag set to true.
10. The method of claim 1, wherein the processing of the software upgrade for the search system cluster distributed over the one or more nodes and allocating the set of one or more search system data nodes for the software upgrade including the at least one upgraded search system data node, further comprises:
allocating a new search system cluster that comprises the at least one upgraded search system data node, an upgraded master node, and an upgraded ingest node, wherein the at least one upgraded search system data node, the upgraded master node, and the upgraded ingest node are distributed among one or more processing systems of the computer processing system.
11. The method of claim 1, wherein the processing the software upgrade for the search system cluster distributed over the one or more nodes and allocating the set of one or more search system data nodes for the software upgrade including the at least one upgraded search system data node, further comprises:
allocating the at least one upgraded search system data node within a current search system cluster that comprises at least one current search system data node, a current master node, and a current ingest node; and
performing an in-place installation of the software upgrade on the current master node and the current ingest node to respectively update the current master node and the current ingest node to an upgraded master node and an upgraded ingest node.
12. The method of claim 1, wherein the search system cluster comprises a search system executed by the computer processing system.
13. The method of claim 1, wherein the search system cluster comprises a search system remote to the computer processing system.
14. The method of claim 1, wherein the transaction data is generated by the computer processing system and comprises data generated during financial transactions performed by the computer processing system on behalf of one or more merchant systems.
15. A non-transitory computer readable storage medium including instructions that, when executed by a processor, cause the processor to perform operations for performing search system upgrades, the operations comprising;
processing a software upgrade for a search system cluster distributed over one or more nodes, the one or more nodes comprising current search system data nodes;
allocating at least a set of one or more search system data nodes for the software upgrade including at least one upgraded search system data node;
receiving, during the software upgrade, transaction data for a transaction processed by a computer processing system, and receiving search requests to be executed by the search system cluster;
performing ingestion of all historical transaction data comprising a dual write of the transaction data comprising: storing and indexing the transaction data in the current search system data nodes; and
storing and indexing the transaction data separately from the current search system data nodes in the at least one upgraded search system data node; and
processing the search requests by the search system cluster against both the current search system data nodes and the at least one upgraded search system data node until the software upgrade is determined to be complete when first search results from the current search system data nodes are compared and match second search results from the at least one upgraded search system data node; and
in response to determining that the software upgrade is complete, decommissioning at least the current search system data nodes and processing new search requests against the at least one upgraded search system data node.
16. The non-transitory computer readable storage medium of claim 15, further comprising:
performing ingestion of historical transaction data to the at least one upgraded search system data node; and when the ingestion of the historical transaction data to the at least one upgraded search system data node is complete and the software upgrade is determined to be complete, decommissioning at least the current search system data nodes and processing new search requests using the at least one upgraded search system data node.
17. The non-transitory computer readable storage medium of claim 16, wherein the software upgrade is determined to be complete further comprises:
determining that all historical transaction data has been ingested by the at least one upgraded search system data node;
after all historical transaction data has been ingested by the at least one upgraded search system data node, processing one or more new search requests against both the current search system data nodes and the at least one upgraded search system data node;
comparing first search results returned using the current search system data nodes with second search results returned using the at least one upgraded search system data node; and
when the first search results match the second search results, determining that the software upgrade is complete.
18. The non-transitory computer readable storage medium of claim 15, wherein the processing of the software upgrade for the search system cluster distributed over the one or more nodes and allocating the set of one or more search system data nodes for the software upgrade including the at least one upgraded search system data node, further comprises:
allocating a new search system cluster that comprises the at least one upgraded search system data node, an upgraded master node, and an upgraded ingest node, wherein the at least one upgraded search system data node, the upgraded master node, and the upgraded ingest node are distributed among one or more processing systems of the computer processing system.
19. The non-transitory computer readable storage medium of claim 15, wherein the processing the software upgrade for the search system cluster distributed over the one or more nodes and allocating the set of one or more search system data nodes for the software upgrade including the at least one upgraded search system data node, further comprises:
allocating the at least one upgraded search system data node within a current search system cluster that comprises at least one current search system data node, a current master node, and a current ingest node; and
performing an in-place installation of the software upgrade on the current master node and the current ingest node to respectively update the current master node and the current ingest node to an upgraded master node and an upgraded ingest node.
20. A commerce platform system for performing search system upgrades, comprising:
a memory; and
a processor coupled with the memory configured to:
process a software upgrade for a search system cluster distributed over one or more nodes, the one or more nodes comprising current search system data nodes,
allocate at least a set of one or more search system data nodes for the software upgrade including at least one upgraded search system data node,
receive, during the software upgrade, transaction data for a transaction processed by the commerce platform system, and receiving search requests to be executed by the search system cluster;
perform ingestion of all historical transaction data comprising a dual write of the transaction data comprising:
storing and indexing the transaction data in the current search system data nodes; and
storing and indexing the transaction data separately from the current search system data nodes in the at least one upgraded search system data node, and
process the search requests by the search system cluster against both the current search system data nodes and the at least one upgraded search system data node until the software upgrade is determined to be complete when first search results from the current search system data nodes are compared and
match second search results from the at least one upgraded search system data node; and
in response to determining that the software upgrade is complete, decommissioning at least the current search system data nodes and processing new search requests against the at least one upgraded search system data node.
1. A method comprising:
allocating, by one or more processors, within a current search system cluster at least one search system data node for an upgraded search system,
the upgraded search system including at least one upgraded search system data node;
initiating, by the one or more processors, on a master node of the current search system cluster an upgrade from the current search system cluster to the upgraded search system;
ingesting, by the one or more processors, a first transaction data packet into the at least one upgraded search system data node,
the first transaction data packet ingested into a current search system data node of the current search system cluster before allocating the at least one search system data node for the upgraded search system; and
ingesting, by the one or more processors, a second transaction data packet into the current search system data node within the current search system cluster and into the at least one upgraded search system data node within the current search system cluster,
the second transaction data packet received after allocating the at least one search system data node for the upgraded search system;
comparing, by the one or more processors, first search results returned using the current search system data node with second search results returned using the at least one upgraded search system data node; and
responsive to the first search results matching the second search results, decommissioning, by the one or more processors, the current search system data node.
2. The method of claim 1, further comprising:
in response to a first search result returned from the current search system cluster not matching a second search result returned from the upgraded search system, deallocating, by the one or more processors, the at least one upgraded search system data node.
3. The method of claim 1, further comprising:
ingesting, by the one or more processors, historical transaction data to the at least one upgraded search system data node; and
when ingesting of the historical transaction data to the at least one upgraded search system data node is complete and the upgrade is determined to be complete,
decommissioning, by the one or more processors, at least the current search system data node and processing new search requests using the at least one upgraded search system data node.
4. The method of claim 3, further comprising:
accessing, by the one or more processors, one or more historical transaction data from a search system snapshot; and
ingesting, by the one or more processors, accessed historical transaction data comprising storing and indexing the accessed historical transaction data in the at least one upgraded search system data node.
5. The method of claim 3, wherein the upgrade is determined to be complete further comprises:
determining, by the one or more processors, that all historical transaction data has been ingested by the at least one upgraded search system data node;
in response to at least in part all historical transaction data being ingested by the at least one upgraded search system data node, processing, by the one or more processors, one or more new search requests against both the current search system data node and the at least one upgraded search system data node;
comparing, by the one or more processors, first search results returned using the current search system data node with second search results returned using the at least one upgraded search system data node; and
when the first search results match the second search results, determining, by the one or more processors, that the upgrade is complete.
6. The method of claim 5, wherein comparing the first search results returned using the current search system data node with the second search results returned using the at least one upgraded search system data node, further comprises:
receiving, by the one or more processors, a search request for a specific transaction data; and
determining, by the one or more processors, a search results match when the specific transaction data is returned in both the first search results and the second search results.
7. The method of claim 5, wherein comparing the first search results returned using the current search system data node with the second search results returned using the at least one upgraded search system data node, further comprises:
receiving, by the one or more processors, a search request for a ranked listing of search results; and
determining, by the one or more processors, a search results match when a first ranked search result returned using the current search system data node has a threshold amount of similarity to a second ranked search result returned using the at least one upgraded search system data node.
8. The method of claim 5, wherein comparing the first search results returned using the current search system data node with the second search results returned using the at least one upgraded search system data node, further comprises:
comparing, by the one or more processors, search results obtained using the current search system data node and using the at least one upgraded search system data node over a period of time; and
when the search results match over a threshold period of time, determining, by the one or more processors that the first search results match the second search results.
9. The method of claim 2, further comprising:
restarting, by the one or more processors, the upgrade by allocating at least a second set of one or more search system data nodes for the upgrade including at least one second upgraded search system data node.
10. The method of claim 4, further comprises:
receiving, by the one or more processors, at least one request to delete identified transaction data from a data store of transaction records;
transforming, by the one or more processors, the at least one request to delete the identified transaction data to an insertion of the identified transaction data with a deletion flag set to true;
ingesting, by the one or more processors, the identified transaction data with the deletion flag, including storing and indexing the identified transaction data, by the at least one upgraded search system data node; and
when the upgrade is determined to be complete, performing, by the one or more processors, garbage collection to remove any transaction data from the at least one upgraded search system data node with a corresponding deletion flag set to true.
11. The method of claim 1, further comprising:
performing an in-place installation of the upgrade on the master node.
12. The method of claim 1, wherein the first transaction data packet and the second transaction data packet are generated by the one or more processors and comprise data generated during financial transactions performed by the one or more processors on behalf of one or more merchant systems.
13. A system comprising:
one or more processors; and
a computer-readable, non-transitory storage medium containing instructions that, when executed by the one or more processors, cause the one or more processors to perform a method comprising:
allocating, by one or more processors, within a current search system cluster at least one search system data node for an upgraded search system, the upgraded search system including at least one upgraded search system data node;
initiating on a master node of the current search system cluster an upgrade from the current search system cluster to the upgraded search system;
ingesting a first transaction data packet into the at least one upgraded search system data node, the first transaction data packet ingested into a current search system data node of the current search system cluster before allocating the at least one search system data node for the upgraded search system; and
ingesting a second transaction data packet into the current search system data node within the current search system cluster and into the at least one upgraded search system data node within the current search system cluster,
the second transaction data packet received after allocating the at least one search system data node for the upgraded search system;
comparing, by the one or more processors, first search results returned using the current search system data node with second search results returned using the at least one upgraded search system data node; and
responsive to the first search results matching the second search results, decommissioning, by the one or more processors, the current search system data node.
14. The system of claim 13, wherein the method further comprises:
in response to a first search result returned from the current search system cluster not matching a second search result returned from the upgraded search system, deallocating the at least one upgraded search system data.
15. The system of claim 13, wherein the method further comprises:
ingesting historical transaction data to the at least one upgraded search system data node; and
when ingesting of the historical transaction data to the at least one upgraded search system data node is complete and the upgrade is determined to be complete, decommissioning at least the current search system data node and processing new search requests using the at least one upgraded search system data node.
16. The system of claim 15, wherein the method further comprises:
accessing one or more historical transaction data from a search system snapshot; and
ingesting accessed historical transaction data comprising storing and indexing the accessed historical transaction data in the at least one upgraded search system data node.
17. The system of claim 15, wherein the upgrade is determined to be complete further comprises:
determining that all historical transaction data has been ingested by the at least one upgraded search system data node;
in response to at least in part all historical transaction data being ingested by the at least one upgraded search system data node, processing one or more new search requests against both the current search system data node and the at least one upgraded search system data node;
comparing first search results returned using the current search system data node with second search results returned using the at least one upgraded search system data node; and
when the first search results match the second search results, determining that the upgrade is complete.
18. The system of claim 17, wherein comparing the first search results returned using the current search system data node with the second search results returned using the at least one upgraded search system data node, further comprises:
receiving a search request for a specific transaction data; and determining a search results match when the specific transaction data is returned in both the first search results and the second search results.
19. The system of claim 17, wherein comparing the first search results returned using the current search system data node with the second search results returned using the at least one upgraded search system data node, further comprises:
receiving a search request for a ranked listing of search results; and
determining a search results match when a first ranked search result returned using the current search system data node has a threshold amount of similarity to a second ranked search result returned using the at least one upgraded search system data node.
20. A computer-readable, non-transitory storage medium containing instructions that, when executed by one or more processors, cause the one or more processors to perform a method comprising:
allocating, by one or more processors, within a current search system cluster at least one search system data node for an upgraded search system, the upgraded search system including at least one upgraded search system data node;
initiating on a master node of the current search system cluster an upgrade from the current search system cluster to the upgraded search system;
ingesting a first transaction data packet into the at least one upgraded search system data node, the first transaction data packet ingested into a current search system data node of the current search system cluster before allocating the at least one search system data node for the upgraded search system; and
ingesting a second transaction data packet into the current search system data node within the current search system cluster and into the at least one upgraded search system data node within the current search system cluster,
the second transaction data packet received after allocating the at least one search system data node for the upgraded search system;
comparing, by the one or more processors, first search results returned using the current search system data node with second search results returned using the at least one upgraded search system data node; and
responsive to the first search results matching the second search results, decommissioning, by the one or more processors, the current search system data node.
13. A system comprising:
one or more processors; and
a computer-readable, non-transitory storage medium containing instructions that, when executed by the one or more processors, cause the one or more processors to perform a method comprising:
allocating, by one or more processors, within a current search system cluster at least one search system data node for an upgraded search system, the upgraded search system including at least one upgraded search system data node;
initiating on a master node of the current search system cluster an upgrade from the current search system cluster to the upgraded search system;
ingesting a first transaction data packet into the at least one upgraded search system data node, the first transaction data packet ingested into a current search system data node of the current search system cluster before allocating the at least one search system data node for the upgraded search system; and
ingesting a second transaction data packet into the current search system data node within the current search system cluster and into the at least one upgraded search system data node within the current search system cluster,
the second transaction data packet received after allocating the at least one search system data node for the upgraded search system;
comparing, by the one or more processors, first search results returned using the current search system data node with second search results returned using the at least one upgraded search system data node; and
responsive to the first search results matching the second search results, decommissioning, by the one or more processors, the current search system data node.
“Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before.” See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals.
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 of this title, 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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37CPR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-4, 9, 11-12, 13-16 and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over
Brewer, Eric A.: "Lessons from Giant-Scale Services", (IEEE INTERNET COMPUTING, JULY - AUGUST 2001 (Year: 2001), hereafter “Brewer”), in view of
LANDER et al.: "ZERO DOWN TIME UPGRADE FOR A MULTI-TENANT IDENTITY AND DATA SECURITY MANAGEMENT CLOUD SERVICE", (U.S. Patent Application Publication US 20180039494 A1, DATE PUBLISHED 2018-02-08 and DATE FILED 2017-07-27, hereafter "LANDER"), and further in view of
ZIZLAVSKY et al.: "NODE DE-DUPLICATION IN NETWORK MONITORING SYSTEM ", (Japan Patent Application Publication JP 2015092666 A, DATE PUBLISHED 2015-05-14 and DATE FILED 2014-11-04, hereafter "ZIZLAVSKY ").
As per claim 1, Brewer teaches a method comprising:
allocating, by one or more processors, within a current search system cluster at least one search system data node for an upgraded search system (See Page 51, right column, lines 2-8, and Page 54, right column - Big flip, DQ (data per query) normally scales linearly with the number of nodes, which means a small test cluster is a good predictor for DQ changes on the production system. For example, Inktomi has been able to use four-node clusters to predict performance improvements on 100-node clusters due to software optimizations (software upgrade). updating the cluster one half at a time by taking down and upgrading half the nodes at once. During the “flip,” we atomically switch all traffic to the upgraded half using a layer-4 switch. Here using the cluster sets of 4 or 100 nodes for software upgrade test teaches the 4 or 100 nodes allocated and the upgraded half cluster of nodes assuming traffic when the rest half taken down for testing teaches the upgraded nodes and taking down the nodes also teaches allocating the nodes),
the upgraded search system including at least one upgraded search system data node (See Page 51, right column, lines 2-8, and Page 54, right column - Big flip, DQ (data per query) normally scales linearly with the number of nodes, which means a small test cluster is a good predictor for DQ changes on the production system. For example, Inktomi has been able to use four-node clusters to predict performance improvements on 100-node clusters due to software optimizations (software upgrade). updating the cluster one half at a time by taking down and upgrading half the nodes at once. During the “flip,” we atomically switch all traffic to the upgraded half using a layer-4 switch. Here the upgraded half teaches the upgraded search system data node);
initiating, by the one or more processors, on a master node of the current search system cluster an upgrade from the current search system cluster to the upgraded search system (See Page 47, right column and Page 53, right column – the load manager provides a level of indirection between the service’s external name and the servers’ physical names (IP addresses) to preserve the external name’s availability in the presence of server faults. The load manager balances load among active servers. Traffic might flow through proxies or firewalls before the load manager. Here the load manager teaches the master node for the hiding down nodes for balancing the load).
As per “ingesting, by the one or more processors, a first transaction data packet into the at least one upgraded search system data node”, Brewer teaches upgraded search system data node as described above.
However, Brewer does not explicitly teach ingesting, by the one or more processors, ingesting, by the one or more processors, a first transaction data packet into the data node, the at least one upgraded search system data node (See [0111], Scaling is accomplished by adding more slices when the application is running, while data for the transaction is stored at a persistence layer where more copies can be added when needed).
It would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to combine LANDER’s teaching with Brewer because Brewer is dedicated to infrastructure services (internet-based systems) that provide instant messaging and wireless services, LANDER is dedicated to identity management in a cloud system, and a combined teaching would have provided a more secure access to Brewer’s internet-based systems.
Brewer in view of LANDER further teaches the following:
the first transaction data packet ingested into a current search system data node of the current search system cluster before allocating the at least one search system data node for the upgraded search system (See LANDER: [0004], the system performs the identity management service by the current version of the microservice using tenant data stored in a database, and the system then determines an upgrade to be applied to the microservice, and deploys a second topology that implements the upgrade. The second topology includes a new version of the microservice and routes requests in the second topology. The system tests the new version of the microservice in the second topology using test data stored in the database, promotes the second topology, and drains and shuts down the first topology.);
ingesting, by the one or more processors, a second transaction data packet into the current search system data node within the current search system cluster and into the at least one upgraded search system data node within the current search system cluster (See Brewer: Page 54, right column, Big flip: update the cluster one half at a time by taking down and upgrading half the nodes at once. During the “flip,” we atomically switch all traffic to the upgraded half using a layer-4 switch. After waiting for connections to the old half to dissipate (the switch only affects new connections), we then upgrade the second half and bring those nodes back into use),
the second transaction data packet received after allocating the at least one search system data node for the upgraded search system (See LANDER: [0111], Scaling is accomplished by adding more slices when the application is running, while data for the transaction is stored at a persistence layer where more copies can be added when needed; and Brewer: Page 54, right column, Big flip: update the cluster one half at a time by taking down and upgrading half the nodes at once. During the “flip,” we atomically switch all traffic to the upgraded half using a layer-4 switch. After waiting for connections to the old half to dissipate (the switch only affects new connections), we then upgrade the second half and bring those nodes back into use).
Brewer in view of LANDER does not explicitly teach comparing, by the one or more processors, first search results returned using the current search system data node with second search results returned using the at least one upgraded search system data node.
However, in the same endeavor, ZIZLAVSKY teaches comparing, by the one or more processors, first search results returned using the current search system data node with second search results returned using the at least one upgraded search system data node (See ZIZLAVSKY: Pages 6-7, when a user attempts to capture search results for a scheduled search profile. In such cases, some embodiments operate on potentially stale information collected during the search and continuously collect that information for all monitored nodes. It may be necessary to compare it with new information that is being developed. Accordingly, deduplication according to certain embodiments occurs during a search operation that compares searched nodes with each other; and retrieving search results to compare the search results with existing nodes being monitored by the system.).
It would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to combine ZIZLAVSKY’s teaching with Brewer in view of LANDER because Brewer is dedicated to infrastructure services (internet-based systems) that provide instant messaging and wireless services, LANDER is dedicated to identity management in a cloud system, ZIZLAVSKY is dedicated to network traffic monitoring, analysis, and/or reporting, more specifically for node deduplication of physical nodes monitored by a network monitoring system, and a combined teaching would have allowed Brewer in view of LANDER to remove duplicated for network system efficiency and data consistency .
Brewer in view of LANDER and further in view of ZIZLAVSKY further teaches the following:
responsive to the first search results matching the second search results, decommissioning, by the one or more processors, the current search system data node (See ZIZLAVSKY: Page 6, compares searched nodes with each other so that duplicates are removed, and / or duplicate nodes are identified and removed.).
As per claim 2, Brewer in view of LANDER and further in view of ZIZLAVSKY teaches the method of claim 1, further comprising:
in response to a first search result returned from the current search system cluster not matching a second search result returned from the upgraded search system, deallocating, by the one or more processors, the at least one upgraded search system data node and the at least one upgraded search system data node (See Brewer: Page 54, right column, Big flip: update the cluster one half at a time by taking down and upgrading half the nodes at once. During the “flip,” we atomically switch all traffic to the upgraded half using a layer-4 switch. After waiting for connections to the old half to dissipate (the switch only affects new connections), we then upgrade the second half and bring those nodes back into use. Here the dissipating teaches deallocating).
As per claim 3, Brewer in view of LANDER and further in view of ZIZLAVSKY teaches the method of claim 1, further comprising:
ingesting, by the one or more processors, historical transaction data to the at least one upgraded search system data node (See Brewer: Page 54, right column, Big flip: update the cluster one half at a time by taking down and upgrading half the nodes at once. During the “flip,” we atomically switch all traffic to the upgraded half using a layer-4 switch. After waiting for connections to the old half to dissipate (the switch only affects new connections), we then upgrade the second half and bring those nodes back into use. Here the dissipating teaches deallocating; and LANDER: [0111], Scaling is accomplished by adding more slices when the application is running, while data for the transaction is stored at a persistence layer where more copies can be added when needed); and
when ingesting of the historical transaction data to the at least one upgraded search system data node is complete and the upgrade is determined to be complete (See LANDER: [0111] and [0211], Scaling is accomplished by adding more slices when the application is running, while data for the transaction is stored at a persistence layer where more copies can be added when needed.; and if a user is logged in a browser against the old topology, their request gets transparently transferred to the new topology since both topologies work with cloud gate, and any cloud gate security artifacts such as tokens, keys, and certificates issued in topology A also work against topology B. For the tokens held within in-memory cache of topology A, since the tokens do not exist in topology B, cloud gate performs a retry to acquire new tokens and validate them against the same client ID.),
decommissioning, by the one or more processors, at least the current search system data node and processing new search requests using the at least one upgraded search system data node (See ZIZLAVSKY: Pages 6-7, when a user attempts to capture search results for a scheduled search profile. In such cases, some embodiments operate on potentially stale information collected during the search and continuously collect that information for all monitored nodes. It may be necessary to compare it with new information that is being developed. Accordingly, deduplication according to certain embodiments occurs during a search operation that compares searched nodes with each other; and retrieving search results to compare the search results with existing nodes being monitored by the system; and LANDER: [0004] and [0212]-[0212], The system then determines an upgrade to be applied to the microservice, and deploys a second topology that implements the upgrade. The second topology includes a second stateless middle tier including a new version of the microservice. The second topology further includes a second web tier configured to route requests in the second topology; and When a session is established in topology A with a session SSO, a compatible retry is performed in topology B to re-establish the connection so that the same session can continue and there are no glitches from the user perspective and a topology is stood up on the fly, it identifies whether it is established as a test system or as a production system. In one embodiment, the traffic system and the code are not tied up with a specific version/topology).
As per claim 4, Brewer in view of LANDER and further in view of ZIZLAVSKY teaches the method of claim 3, further comprising:
accessing, by the one or more processors, one or more historical transaction data from a search system snapshot (See Brewer: Page 54, right column, Big flip: update the cluster one half at a time by taking down and upgrading half the nodes at once. During the “flip,” we atomically switch all traffic to the upgraded half using a layer-4 switch. After waiting for connections to the old half to dissipate (the switch only affects new connections), we then upgrade the second half and bring those nodes back into use. Here the dissipating teaches deallocating; and LANDER: [0111], Scaling is accomplished by adding more slices when the application is running, while data for the transaction is stored at a persistence layer where more copies can be added when needed); and
ingesting, by the one or more processors, accessed historical transaction data comprising storing and indexing the accessed historical transaction data in the at least one upgraded search system data node (See Brewer: Page 54, right column, Big flip: update the cluster one half at a time by taking down and upgrading half the nodes at once. During the “flip,” we atomically switch all traffic to the upgraded half using a layer-4 switch. After waiting for connections to the old half to dissipate (the switch only affects new connections), we then upgrade the second half and bring those nodes back into use).
As per claim 9, Brewer in view of LANDER and further in view of ZIZLAVSKY teaches the method of claim 2, further comprising:
restarting, by the one or more processors, the upgrade by allocating at least a second set of one or more search system data nodes for the upgrade including at least one second upgraded search system data node (See Brewer: Page 54, right column, both the new and old versions to coexist on the node. System administrators can do a controlled reboot (at worst) to upgrade the node within the normal mean-time-to-repair; and upgrading during off-peak hours, we can reduce the yield impact. In practice, this requires a staging area because the upgrades all occur at the same time and thus need to be highly automated.).
As per claim 11, Brewer in view of LANDER and further in view of ZIZLAVSKY teaches the method of claim 1, further comprising:
performing an in-place installation of the upgrade on the master node (See LANDER: [0193], a typical installation that has many more servers. Failover and failback are more efficient the more servers that are present in each cluster and the impact of a server failure on a cluster is lessened).
As per claim 12, Brewer in view of LANDER and further in view of ZIZLAVSKY teaches the method of claim 1, wherein the first transaction data packet and the second transaction data packet are generated by the one or more processors and comprise data generated during financial transactions performed by the one or more processors on behalf of one or more merchant systems (See LANDER: [0004], the identity management service by the current version of the microservice using tenant data stored in a database. The system then determines an upgrade to be applied to the microservice and deploys a second topology that implements the upgrade ).
As per claims 13-16, the claims recite a system comprising:
one or more processors (See Brewer: Page 47, servers CPUs reads on the processor); and
a computer-readable, non-transitory storage medium containing instructions that, when executed by the one or more processors, cause the one or more processors (See Brewer: Page 47, Servers are the system’s workers, combining CPU, memory, and disks into an easy-to-replicate unit) to perform the seps as recited in the methods of the claims 1-4, and as rejected under 35 U.S.C. § 103 for being unpatentable over Brewer in view of LANDER and further in view of ZIZLAVSKY, respectively.
Accordingly, claims 13-16 are rejected along the same rationale that rejected claims 1-4, respectively.
As per claim 20, the claim recites a computer-readable, non-transitory storage medium containing instructions that, when executed by one or more processors, cause the one or more processors (See Brewer: Page 47, Servers are the system’s workers, combining CPU, memory, and disks into an easy-to-replicate unit) to perform the seps as recited in the method of the claim 1, and as rejected under 35 U.S.C. § 103 for being unpatentable over Brewer in view of LANDER and further in view of ZIZLAVSKY.
Accordingly, claim 20 is rejected along the same rationale that rejected claim 1.
Allowable Subject Matter
Claims 5-8, 10 and 17-19 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, and an approved terminal disclaimer filed against U.S. Patent 12292880 that was issued 07/08/2025 to the parent application 17899381of the instant application.
Related Prior Arts
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure can be found in the PTO-892 Notice of Reference Cited.
Conclusion
THIS ACTION IS MADE FINAL. 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.
Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner. SEE MPEP 2141.02 [R-5] VI. PRIOR ART MUST BE CONSIDERED IN ITS ENTIRETY, INCLUDING DISCLOSURES THAT TEACH AWAY FROM THE CLAIMS: A prior art reference must be considered in its entirety, i.e., as a whole, including portions that would lead away from the claimed invention. W.L. Gore & Associates, Inc. v. Garlock, Inc., 721 F.2d 1540, 220 USPQ 303 (Fed. Cir. 1983), cert. denied, 469 U.S. 851 (1984) In re Fulton, 391 F.3d 1195, 1201, 73 USPQ2d 1141, 1146 (Fed. Cir. 2004). >See also MPEP §2123.
In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KUEN S LU whose telephone number is (571)272-4114. The examiner can normally be reached on M-F, 8-19, Mid-Flex 2 hours.
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, Mr. Aleksandr Kerzhner can be reached on 571-270-1760. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
KUEN S LU /Kuen S Lu/
Art Unit 2165
Primary Patent Examiner
September 5, 2026
Prosecution Insights