Prosecution Insights
Last updated: April 19, 2026
Application No. 18/206,768

DECENTRALIZED NETWORK FOR SEARCH FOR VEHICLES

Non-Final OA §101§103
Filed
Jun 07, 2023
Examiner
LADONI, AHOORA
Art Unit
3689
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Capital One Services LLC
OA Round
3 (Non-Final)
0%
Grant Probability
At Risk
3-4
OA Rounds
3y 0m
To Grant
0%
With Interview

Examiner Intelligence

Grants only 0% of cases
0%
Career Allow Rate
0 granted / 13 resolved
-52.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
3y 0m
Avg Prosecution
30 currently pending
Career history
43
Total Applications
across all art units

Statute-Specific Performance

§101
36.8%
-3.2% vs TC avg
§103
39.6%
-0.4% vs TC avg
§102
15.7%
-24.3% vs TC avg
§112
6.0%
-34.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 13 resolved cases

Office Action

§101 §103
DETAILED ACTION 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 12/01/2025 has been entered. Status of Claims Claims 1, 3, 4, 7, 8, 10, 11, 14, 15, 17, 18, and 21-29 submitted on 12/01/2025 are pending and have been examined. Claims 1, 3, 4, 8, 10, 11, 15, 17, and 18 have been amended. Claims 2, 5, 6, 9, 12, 13, 16, 19, and 20 have been cancelled. Claims 21-29 are newly added. 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 . Priority No foreign priority or domestic benefit was claimed by the applicant and the application has been examined with respect to its filing date of 06/07/2023. Claim Objections Claim 8 is objected to because of the following informalities: Claim 8 recites “the second period of time I based on…” on page 4 of the claims submitted on 12/01/2025. For purposes of clarity on the record and compact prosecution, Examiner will interpret the limitation as “the second period of time [[I]]is based on…” Appropriate correction is required. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1, 3, 4, 7, 8, 10, 11, 14, 15, 17, 18, and 21-29 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without significantly more. The claims recite an abstract idea. This judicial exception is not integrated into a practical application. The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Step 1 Claims 1, 3, 4, 7, and 21-23 are directed to a process, claims 8, 10, 11, 14, and 24-26 are directed to an article of manufacture, and claims 15, 17, 18, and 27-29 are directed to a machine (see MPEP 2106.03). Step 2A, Prong 1 Claim 1, taken as representative, recites at least the following limitations that recite an abstract idea: a method for performing a search using a plurality of decentralized entities in a system without a central repository, the method comprising: receiving, from a client, a search request for information about a vehicle; queuing, the search request into a first queue configured to store the search request for a first period of time, wherein the first period of time is based on asynchronous dispatch of at least two of the plurality of decentralized entities; for each entity of the plurality of decentralized entities, wherein the decentralized entities comprise one or more search entities and one or more physical search entities, the one or more search entities, and the one or more physical search entities: transmitting, the search request to the respective entity, wherein the respective entity is configured to be dispatched based on the search request; receiving, respective retrieved information about the vehicle from the dispatched respective entity; and queuing, the respective retrieved information into a second queue configured to store retrieved information for a second period of time, wherein the second period of time is based on the retrieved information being received from a dispatched entity asynchronously from another retrieved information received from another dispatched entity; removing, the search request from the first queue, based on the first period of time and the dispatching of each entity of the plurality of decentralized entities; generating, a graphical user interface (GUI) with each retrieved information stored in the second queue about the vehicle; removing, the each retrieved information from the second queue, based on the second period of time and the generating the GUI: and transmitting, the GUI to the client for display. The above limitation, under its broadest reasonable interpretation, falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas, enumerated in MPEP 2106.04(a)(2)(II), in that it recites a commercial interaction. Claims 8 and 15 recites similar limitations as claim 1. Thus, under Prong 1 of Step 2A, claims 1, 8, and 15 recite an abstract idea. Step 2A, Prong 2 Claim 1 includes the following additional elements that are bolded: a computer implemented method for performing a search using a plurality of decentralized entities in a system without a central repository, the method comprising: receiving, by one or more computing devices and from a client device, a search request for information about a vehicle; queuing, by the one or more computing devices, the search request into a first queue configured to store the search request for a first period of time, wherein the first period of time is based on asynchronous dispatch of at least two of the plurality of decentralized entities; for each entity of the plurality of decentralized entities, wherein the decentralized entities comprise one or more computerized search entities and one or more physical search entities, the one or more computerized search entities including at least one of a computer or a database, and the one or more physical search entities including at least one of a robot, an autonomous vehicle, or an aerial drone: transmitting, by the one or more computing devices, the search request to the respective entity, wherein the respective entity is configured to be dispatched based on the search request; receiving, by the one or more computing devices, respective retrieved information about the vehicle from the dispatched respective entity; and queuing, by the one or more computing devices, the respective retrieved information into a second queue configured to store retrieved information for a second period of time, wherein the second period of time is based on the retrieved information being received from a dispatched entity asynchronously from another retrieved information received from another dispatched entity; removing, by the one or more computing devices, the search request from the first queue, based on the first period of time and the dispatching of each entity of the plurality of decentralized entities; generating, by the one or more computing devices, a graphical user interface (GUI) with each retrieved information stored in the second queue about the vehicle; removing, by the one or more computing devices, the each retrieved information from the second queue, based on the second period of time and the generating the GUI: and transmitting, by the one or more computing devices, the GUI to the client device for display. Claims 8 and 15 include the same additional elements as claim 1. In addition, claim 8 includes additional elements such as a non-transitory computer readable medium having instructions stored thereon that, when executed by at least one computing device of a system without a central repository, causes the at least one computing device to perform operations for performing a search using a plurality of decentralized entities, the operations comprising. In addition, claim 15 includes a computing system without a central repository, wherein the computing system is configured to perform a search using a plurality of decentralized entities, the computing system comprising: one or more memories; and at least one processor, each coupled to at least one of the one or more memories. The additional elements recited in claims 1, 8, and 15 merely invoke such elements as a tool to perform the abstract idea and generally link the use of the abstract idea to a particular technological environment of computers (see MPEP 2106.05(f) and MPEP 2106.05(h). These additional elements are described at a high level in Applicant’s specification without any meaningful detail about their structure or configuration (see Figs. 1 and 4 and ¶¶0040-0041). As such, under Prong 2 of Step 2A, when considered both individually and as a whole, the additional elements do not integrate the judicial exception into a practical application and, thus, claims 1, 8, and 15 are directed to an abstract idea. Step 2B As noted above, while the recitation of the additional elements in independent claims 1, 8, and 15 are acknowledged, claims 1, 8, and 15 merely invoke such additional elements as a tool to perform the abstract idea and generally link the use of the abstract idea to a particular technological environment (see MPEP 2106.05(f) and MPEP 2106.05(h)). Even when considered as an ordered combination, the additional elements of claim 1, 8, and 15 do not add anything that is not already present when they are considered individually. Therefore, under Step 2B, there are no meaningful limitations in claims 1, 8, and 15 that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself (see MPEP 2106.05). As such, independent claims 1, 8, and 15 are ineligible. Dependent claims 3, 4, 10, 11, 17, 18, 22, 23, 25, 26, 28, and 29 when analyzed as a whole, are held to be patent ineligible under 35 U.S.C. 101 because they do not add “significantly more” to the abstract idea. More specifically, dependent claims 3, 4, 10, 11, 17, 18, 22, 23, 25, 26, 28, and 29 merely further define the abstract limitations of claims 1, 8, and 15 or provide further embellishments of the limitations recited in independent claims 1, 8, and 15. Claims 3, 4, 10, 11, 17, 18, 22, 23, 25, 26, 28, and 29 do not introduce any further additional elements. Thus, dependent claims 3, 4, 10, 11, 17, 18, 22, 23, 25, 26, 28, and 29 are ineligible. Furthermore, it is noted that certain dependent claims recite additional elements supplemental to those recited in independent claims 1, 8, and 15: a mobile software application (claims 7 and 14) and an application programming interface (claims 21, 24, and 27). However, these elements do not integrate the abstract idea into a practical application because they merely amount to using a computer to apply the abstract idea to a particular technological environment or field of use and thus do not act to integrate the abstract idea into a practical application of the abstract idea. Additionally, the additional elements do not amount to significantly more because they merely amount to using a computer to apply the abstract idea and amount to no more than a general link of the use of the abstract idea to a particular technological environment. Thus, dependent claims 7, 14, 21, 24, 27 are ineligible. 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, 3, 4, 7, 8, 10, 11, 14, 15, 17, 18, 21, 22, 24, 25, 27, and 28 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cumberland et al. (US 2016/0225045 A1) in view of Simoudis et al. (US 12,002,309 B2). Regarding Claim 1, Cumberland et al., hereinafter, Cumberland, discloses a computer implemented method for performing a search using a plurality of decentralized entities in a system without a central repository, the method comprising (Figs. 1 and 4; ¶0041[The central communication server 104 determines which of the Vendor C-D devices 110c-d are located within the particular geographic area or are associated with the particular geographic area, e.g., when the Vendor C retail location is within the particular geographic area and, during time period T.sub.B, sends a request for a manual inventory inquiry to the determined devices. The central communication server 104 may send the request for the manual inventory inquiry to vendors which do not have electronic inventory databases or which have electronic inventory databases that are not integrated with the central communication server 104.] in view of ¶0031[The central communication server may retrieve the inventory information from a central server, from multiple servers that are each maintained for a particular retailer, from a device for an entity, e.g., a person or a robot, physically located at a retail location, or a combination of any two or more of these]; ¶0012 of the instant specification states that “does not attempt to aggregate information into a central database or repository. Rather, the system allows the decentralized entities to search for the data requested directly from the physical locations, computers, databases, dealerships, etc. that are selling the vehicles”, Examiner notes that a system without a repository for product availability of all associated vendors is comparable to the system without a central repository as described in the specification of the applicant): receiving, by one or more computing devices and from a client device, a search request for information about a product (¶0048[For instance, the second device 114 may include an inventory application specific to the central communication server 104 that allows the second device 114 to receive search results from the central communication server 104 and present the search results to a user, e.g., the same user who requested the search results with the first device 102]); queuing, by the one or more computing devices, the search request into a first queue configured to store the search request for a first period of time, wherein the first period of time is based on asynchronous dispatch of at least two of the plurality of decentralized entities (¶0045[one or more of the Vendor C-D devices 110c-d may be included in an automated search device, e.g., a robot. The robot may receive the request for a manual inventory inquiry, determine where the specific product is typically located in the retail location, and scan bar codes of products at the retail location to determine whether or not the specific product is in stock.] in view of ¶0082[If at least one of the vendors for which results have been received has the requested commerce object in inventory, the process asynchronously receives and aggregates search results into groups (412) and ¶0077[The central communication server may place any vendor retail locations that are currently not open in the second group. In some examples, the central communication server may determine that some of the vendor retail locations in the third group will be open within a maximum search time period, and wait to send an inventory inquiry to those vendor retail locations once the respective vendor retail locations are open.]); for each entity of the plurality of decentralized entities, wherein the decentralized entities comprise one or more computerized search entities and one or more physical search entities, the one or more computerized search entities including at least one of a computer or a database, and the one or more physical search entities including at least one of a robot, an autonomous vehicle, or an aerial drone (Fig. 1; ¶¶0029-0031[the central communication server accesses databases for some retailers and may request a manual inventory inquiry for other retailers and provides inventory information to the consumer… The central communication server may retrieve the inventory information from a central server, from multiple servers that are each maintained for a particular retailer, from a device for an entity, e.g., a person or a robot, physically located at a retail location, or a combination of any two or more of these]): transmitting, by the one or more computing devices, the search request to the respective entity, wherein the respective entity is configured to be dispatched based on the search request (Fig. 1; ¶¶0030-0031[the consumer may search for a television using their desktop computer, request information from a central communication server about what retail locations have the television in stock, and then receive and view inventory information on his smart phone from the central communication server, e.g., via text messaging or a mobile application… The central communication server may retrieve the inventory information from a central server, from multiple servers that are each maintained for a particular retailer, from a device for an entity, e.g., a person or a robot, physically located at a retail location, or a combination of any two or more of these. The inventory information is for multiple different retailers that each may have the requested product, e.g., television, in stock. The inventory information may include stock levels, e.g., when the consumer requests multiple of the same product.] in view of ¶0043[The Vendor C-D devices 110c-d each receives a respective request and prompt an entity to perform a manual search for the specific product or type of product.]; Examiner notes that prompting an entity to perform a search is comparable to dispatching an entity); receiving, by the one or more computing devices, respective retrieved information about the product from the dispatched respective entity (Fig. 1; ¶0043[The smart phone may receive input from the employee indicating whether or not the product is in stock, the amount of the product at the Vendor D retail location, if the Vendor D retail location has any comparable products in stock, or a combination of two or more of these.] in view of ¶0103[The central communication server allows the other server to provide product inventory information to one or more users that request the product inventory information, e.g., for different products, from the other server.]); and by the one or more computing devices, the respective retrieved information retrieved information, wherein the retrieved information being received from a dispatched entity asynchronously from another retrieved information received from another dispatched entity (Fig. 1; ¶0103[The central communication server allows the other server to provide product inventory information to one or more users that request the product inventory information, e.g., for different products, from the other server.] in view of ¶0082[If at least one of the vendors for which results have been received has the requested commerce object in inventory, the process asynchronously receives and aggregates search results into groups] and ¶0031[The central communication server may retrieve the inventory information from a central server, from multiple servers that are each maintained for a particular retailer, from a device for an entity, e.g., a person or a robot, physically located at a retail location, or a combination of any two or more of these]); by the one or more computing devices, the search request, based on the dispatching of each entity of the plurality of decentralized entities (Fig. 1; ¶0103[The central communication server allows the other server to provide product inventory information to one or more users that request the product inventory information, e.g., for different products, from the other server.] in view of ¶0082[If at least one of the vendors for which results have been received has the requested commerce object in inventory, the process asynchronously receives and aggregates search results into groups] and ¶0031[The central communication server may retrieve the inventory information from a central server, from multiple servers that are each maintained for a particular retailer, from a device for an entity, e.g., a person or a robot, physically located at a retail location, or a combination of any two or more of these]); generating, by the one or more computing devices, a graphical user interface (GUI) with each retrieved information (Figs. 1 and 3; ¶0060[FIG. 3 is an example of a mobile device user interface 300 for displaying inventory search results. For instance, the mobile device may receive search results from the central communication server 104 as the search results become available and present the search results in the mobile device user interface 300.]); by the one or more computing devices, the each retrieved information, based on the generating the GUI (Figs. 1 and 3; ¶0060[FIG. 3 is an example of a mobile device user interface 300 for displaying inventory search results. For instance, the mobile device may receive search results from the central communication server 104 as the search results become available and present the search results in the mobile device user interface 300.]): and transmitting, by the one or more computing devices, the GUI to the client device for display (Figs. 1-3; ¶¶0060-0063[FIG. 3 is an example of a mobile device user interface 300 for displaying inventory search results… the mobile device will periodically receive data from the central communication server 104 and use the data to present messages about product inventory updates on a display]). Although Cumberland discloses receiving a search request about a product, Cumberland does not explicitly disclose request for information about a vehicle. Although Cumberland discloses receiving information about a product from dispatched entities, Cumberland does not explicitly disclose receiving information about a vehicle. Although Cumberland discloses retrieved information being received from dispatched entities, Cumberland does not explicitly disclose queuing, into a second queue configured to store for a second period of time, the second period of time is based on the retrieved information being received. Although Cumberland discloses a search request and dispatch of entities, Cumberland does not explicitly disclose removing, from the first queue based on the first period of time and the dispatching. Although Cumberland discloses generating a GUI with retrieved information, Cumberland does not explicitly disclose information stored in the second queue about the vehicle. Although Cumberland discloses a search request and dispatch of entities, Cumberland does not explicitly disclose removing, from the second queue based on the second period of time and the generating. However, Simoudis et al., hereinafter, Simoudis, teaches receiving information about a vehicle, queuing information for a period of time, storing information in a queue, and removing information from a queue (Col. 21, lines 13-45[For instance, a requesting application (e.g., insurance application) may send to the OEM system associated with a target vehicle (or group of vehicles) a request indicating the type of data and the frequency of such data are needed from the target vehicle… Upon receiving the request, the data orchestrator may push the request to a queue and send back a response message to the OEM system to acknowledge receipt of the request. The OEM system may then send a message to the requesting application indicating the request has been logged… in addition to passing the request/response message, the OEM system/application may send a message to the data orchestrator instructing the data orchestrator to delete the transmission request from the queue when a transmission period is completed (e.g., upon receiving a completion message from the data orchestrator). The data orchestrator may then delete the entry from the queue and send a message to the OEM system indicating the entry is deleted]). The method of Simoudis is applicable to the method of Cumberland as they share characteristics and capabilities, namely, they are both targeted to generating and managing data. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the search request and dispatch of entities as disclosed by Cumberland to include queuing information about a vehicle and removing information from a queue as taught by Simoudis. One of ordinary skill in the art would have been motivated to expand the method of Cumberland in order to determine which of (which portion of) the vehicle data is to be communicated to which data center or third-party entity, and when such data is transmitted (Col. 2, lines 39-41). Regarding Claim 3, Cumberland in view of Simoudis teaches the method of claim 1, Cumberland further discloses wherein the respective retrieved information received by the one or more computing devices and from a subset of the decentralized entities is received asynchronously (¶0045[one or more of the Vendor C-D devices 110c-d may be included in an automated search device, e.g., a robot. The robot may receive the request for a manual inventory inquiry, determine where the specific product is typically located in the retail location, and scan bar codes of products at the retail location to determine whether or not the specific product is in stock.] in view of ¶0082[If at least one of the vendors for which results have been received has the requested commerce object in inventory, the process asynchronously receives and aggregates search results into groups (412) and ¶0077[The central communication server may place any vendor retail locations that are currently not open in the second group. In some examples, the central communication server may determine that some of the vendor retail locations in the third group will be open within a maximum search time period, and wait to send an inventory inquiry to those vendor retail locations once the respective vendor retail locations are open.]). Regarding Claim 4, Cumberland in view of Simoudis teaches the method of claim 1, Cumberland further discloses wherein the respective retrieved information received by the one or more computing devices and from a subset of the decentralized entities is received in real-time (¶0069[the central communication server searches the central database, or another database, for vendor retail locations to contact regarding product inventory information for the requested commerce object. Some of these vendor retail locations may have inventory data available in real-time] in view of Claim 1[performing real-time searching for inventory data of the requested commerce object in the central database that has been maintained with up-to-date information about potential vendors' respective inventories via data integration by communicating with the central database in response to receiving the information from the first user device identifying the requested commerce object for which available inventory is sought]). Regarding Claim 7, Cumberland in view of Simoudis teaches the method of claim 1, Cumberland further discloses wherein the search request is received via a mobile software application installed on the client device (Fig. 1; ¶0062[In response to the presentation of the confirmation message, the mobile device may receive input 304 indicating that a user of the mobile device would like to receive product inventory updates on the mobile device. For instance, when the confirmation message indicates that a response of “Go” opts in to receiving product inventory updates, the mobile device may receive data indicating user input 304 of “Go,” e.g., through a software or hardware keyboard or voice input.] in view of ¶0048[For instance, the second device 114 may include an inventory application specific to the central communication server 104 that allows the second device 114 to receive search results from the central communication server 104 and present the search results to a user, e.g., the same user who requested the search results with the first device 102]). Regarding Claim 8, Cumberland discloses a non-transitory computer readable medium having instructions stored thereon that (Fig. 6; ¶¶0133-0137[The processor 652 can execute instructions within the computing device 650, including instructions stored in the memory 664.]), when executed by at least one computing device of a system without a central repository, causes the at least one computing device to perform operations for performing a search using a plurality of decentralized entities, the operations comprising (Figs. 1 and 4; ¶0041[The central communication server 104 determines which of the Vendor C-D devices 110c-d are located within the particular geographic area or are associated with the particular geographic area, e.g., when the Vendor C retail location is within the particular geographic area and, during time period T.sub.B, sends a request for a manual inventory inquiry to the determined devices. The central communication server 104 may send the request for the manual inventory inquiry to vendors which do not have electronic inventory databases or which have electronic inventory databases that are not integrated with the central communication server 104.] in view of ¶0031[The central communication server may retrieve the inventory information from a central server, from multiple servers that are each maintained for a particular retailer, from a device for an entity, e.g., a person or a robot, physically located at a retail location, or a combination of any two or more of these]; ¶0012 of the instant specification states that “does not attempt to aggregate information into a central database or repository. Rather, the system allows the decentralized entities to search for the data requested directly from the physical locations, computers, databases, dealerships, etc. that are selling the vehicles”, Examiner notes that a system without a repository for product availability of all associated vendors is comparable to the system without a central repository as described in the specification of the applicant): receiving, from a client device, a search request for information about a product (¶0048[For instance, the second device 114 may include an inventory application specific to the central communication server 104 that allows the second device 114 to receive search results from the central communication server 104 and present the search results to a user, e.g., the same user who requested the search results with the first device 102]); queuing the search request into a first queue configured to store the search request for a first period of time, wherein the first period of time is based on asynchronous dispatch of at least two of the plurality of decentralized entities (¶0045[one or more of the Vendor C-D devices 110c-d may be included in an automated search device, e.g., a robot. The robot may receive the request for a manual inventory inquiry, determine where the specific product is typically located in the retail location, and scan bar codes of products at the retail location to determine whether or not the specific product is in stock.] in view of ¶0082[If at least one of the vendors for which results have been received has the requested commerce object in inventory, the process asynchronously receives and aggregates search results into groups (412) and ¶0077[The central communication server may place any vendor retail locations that are currently not open in the second group. In some examples, the central communication server may determine that some of the vendor retail locations in the third group will be open within a maximum search time period, and wait to send an inventory inquiry to those vendor retail locations once the respective vendor retail locations are open.]); for each entity of the plurality of decentralized entities, wherein the decentralized entities comprise one or more computerized search entities and one or more physical search entities, the one or more computerized search entities including at least one of a computer or a database, and the one or more physical search entities including at least one of a robot, an autonomous vehicle, or an aerial drone (Fig. 1; ¶¶0029-0031[the central communication server accesses databases for some retailers and may request a manual inventory inquiry for other retailers and provides inventory information to the consumer… The central communication server may retrieve the inventory information from a central server, from multiple servers that are each maintained for a particular retailer, from a device for an entity, e.g., a person or a robot, physically located at a retail location, or a combination of any two or more of these]): transmitting the search request to the respective entity, wherein the respective entity is configured to be dispatch based on the search request (Fig. 1; ¶¶0030-0031[the consumer may search for a television using their desktop computer, request information from a central communication server about what retail locations have the television in stock, and then receive and view inventory information on his smart phone from the central communication server, e.g., via text messaging or a mobile application… The central communication server may retrieve the inventory information from a central server, from multiple servers that are each maintained for a particular retailer, from a device for an entity, e.g., a person or a robot, physically located at a retail location, or a combination of any two or more of these. The inventory information is for multiple different retailers that each may have the requested product, e.g., television, in stock. The inventory information may include stock levels, e.g., when the consumer requests multiple of the same product.] in view of ¶0043[The Vendor C-D devices 110c-d each receives a respective request and prompt an entity to perform a manual search for the specific product or type of product.]; Examiner notes that prompting an entity to perform a search is comparable to dispatching an entity); receiving respective retrieved information about the product from the dispatch respective entity (Fig. 1; ¶0043[The smart phone may receive input from the employee indicating whether or not the product is in stock, the amount of the product at the Vendor D retail location, if the Vendor D retail location has any comparable products in stock, or a combination of two or more of these.] in view of ¶0103[The central communication server allows the other server to provide product inventory information to one or more users that request the product inventory information, e.g., for different products, from the other server.]); the respective retrieved information retrieved information, wherein the retrieved information being received from a dispatched entity asynchronously from another retrieved information received from another dispatched entity (Fig. 1; ¶0103[The central communication server allows the other server to provide product inventory information to one or more users that request the product inventory information, e.g., for different products, from the other server.] in view of ¶0082[If at least one of the vendors for which results have been received has the requested commerce object in inventory, the process asynchronously receives and aggregates search results into groups] and ¶0031[The central communication server may retrieve the inventory information from a central server, from multiple servers that are each maintained for a particular retailer, from a device for an entity, e.g., a person or a robot, physically located at a retail location, or a combination of any two or more of these]); the search request, based on the dispatching of each entity of the plurality of decentralized entities (Fig. 1; ¶0103[The central communication server allows the other server to provide product inventory information to one or more users that request the product inventory information, e.g., for different products, from the other server.] in view of ¶0082[If at least one of the vendors for which results have been received has the requested commerce object in inventory, the process asynchronously receives and aggregates search results into groups] and ¶0031[The central communication server may retrieve the inventory information from a central server, from multiple servers that are each maintained for a particular retailer, from a device for an entity, e.g., a person or a robot, physically located at a retail location, or a combination of any two or more of these]); generating a graphical user interface (GUI) with each retrieved information (Figs. 1 and 3; ¶0060[FIG. 3 is an example of a mobile device user interface 300 for displaying inventory search results. For instance, the mobile device may receive search results from the central communication server 104 as the search results become available and present the search results in the mobile device user interface 300.]); the each retrieved information, based on the generating the GUI (Figs. 1 and 3; ¶0060[FIG. 3 is an example of a mobile device user interface 300 for displaying inventory search results. For instance, the mobile device may receive search results from the central communication server 104 as the search results become available and present the search results in the mobile device user interface 300.]): and transmitting the GUI to the client device for display (Figs. 1-3; ¶¶0060-0063[FIG. 3 is an example of a mobile device user interface 300 for displaying inventory search results… the mobile device will periodically receive data from the central communication server 104 and use the data to present messages about product inventory updates on a display]). Although Cumberland discloses receiving a search request about a product, Cumberland does not explicitly disclose request for information about a vehicle. Although Cumberland discloses receiving information about a product from dispatched entities, Cumberland does not explicitly disclose receiving information about a vehicle. Although Cumberland discloses retrieved information being received from dispatched entities, Cumberland does not explicitly disclose queuing into a second queue configured to store for a second period of time, the second period of time is based on the retrieved information being received. Although Cumberland discloses a search request and dispatch of entities, Cumberland does not explicitly disclose removing from the first queue based on the first period of time and the dispatching. Although Cumberland discloses generating a GUI with retrieved information, Cumberland does not explicitly disclose information stored in the second queue about the vehicle. Although Cumberland discloses a search request and dispatch of entities, Cumberland does not explicitly disclose removing from the second queue based on the second period of time and the generating. However, Simoudis teaches receiving information about a vehicle, queuing information for a period of time, storing information in a queue, and removing information from a queue (Col. 21, lines 13-45[For instance, a requesting application (e.g., insurance application) may send to the OEM system associated with a target vehicle (or group of vehicles) a request indicating the type of data and the frequency of such data are needed from the target vehicle… Upon receiving the request, the data orchestrator may push the request to a queue and send back a response message to the OEM system to acknowledge receipt of the request. The OEM system may then send a message to the requesting application indicating the request has been logged… in addition to passing the request/response message, the OEM system/application may send a message to the data orchestrator instructing the data orchestrator to delete the transmission request from the queue when a transmission period is completed (e.g., upon receiving a completion message from the data orchestrator). The data orchestrator may then delete the entry from the queue and send a message to the OEM system indicating the entry is deleted]). The system of Simoudis is applicable to the system of Cumberland as they share characteristics and capabilities, namely, they are both targeted to generating and managing data. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the search request and dispatch of entities as disclosed by Cumberland to include queuing information about a vehicle and removing information from a queue as taught by Simoudis. One of ordinary skill in the art would have been motivated to expand the system of Cumberland in order to determine which of (which portion of) the vehicle data is to be communicated to which data center or third-party entity, and when such data is transmitted (Col. 2, lines 39-41). Regarding Claim 10, Cumberland in view of Simoudis teaches the non-transitory computer readable medium of claim 8, Cumberland further discloses wherein the respective retrieved information received from a subset of the decentralized entities is received asynchronously (¶0045[one or more of the Vendor C-D devices 110c-d may be included in an automated search device, e.g., a robot. The robot may receive the request for a manual inventory inquiry, determine where the specific product is typically located in the retail location, and scan bar codes of products at the retail location to determine whether or not the specific product is in stock.] in view of ¶0082[If at least one of the vendors for which results have been received has the requested commerce object in inventory, the process asynchronously receives and aggregates search results into groups (412) and ¶0077[The central communication server may place any vendor retail locations that are currently not open in the second group. In some examples, the central communication server may determine that some of the vendor retail locations in the third group will be open within a maximum search time period, and wait to send an inventory inquiry to those vendor retail locations once the respective vendor retail locations are open.]). Regarding Claim 11, Cumberland in view of Simoudis teaches the non-transitory computer readable medium of claim 8, Cumberland further discloses wherein the respective retrieved information received from a subset of the decentralized entities is received in real-time (¶0069[the central communication server searches the central database, or another database, for vendor retail locations to contact regarding product inventory information for the requested commerce object. Some of these vendor retail locations may have inventory data available in real-time] in view of Claim 1[performing real-time searching for inventory data of the requested commerce object in the central database that has been maintained with up-to-date information about potential vendors' respective inventories via data integration by communicating with the central database in response to receiving the information from the first user device identifying the requested commerce object for which available inventory is sought]). Regarding Claim 14, Cumberland in view of Simoudis teaches the non-transitory computer readable medium of claim 8, Cumberland further discloses wherein the search request is received via a mobile software application installed on the client device (Fig. 1; ¶0062[In response to the presentation of the confirmation message, the mobile device may receive input 304 indicating that a user of the mobile device would like to receive product inventory updates on the mobile device. For instance, when the confirmation message indicates that a response of “Go” opts in to receiving product inventory updates, the mobile device may receive data indicating user input 304 of “Go,” e.g., through a software or hardware keyboard or voice input.] in view of ¶0048[For instance, the second device 114 may include an inventory application specific to the central communication server 104 that allows the second device 114 to receive search results from the central communication server 104 and present the search results to a user, e.g., the same user who requested the search results with the first device 102]). Regarding Claim 15, Cumberland discloses a computing system without a central repository, wherein the computing system is configured to perform a search using a plurality of decentralized entities, the computing system comprising (Figs. 1 and 4; ¶0041[The central communication server 104 determines which of the Vendor C-D devices 110c-d are located within the particular geographic area or are associated with the particular geographic area, e.g., when the Vendor C retail location is within the particular geographic area and, during time period T.sub.B, sends a request for a manual inventory inquiry to the determined devices. The central communication server 104 may send the request for the manual inventory inquiry to vendors which do not have electronic inventory databases or which have electronic inventory databases that are not integrated with the central communication server 104.] in view of ¶0031[The central communication server may retrieve the inventory information from a central server, from multiple servers that are each maintained for a particular retailer, from a device for an entity, e.g., a person or a robot, physically located at a retail location, or a combination of any two or more of these]; ¶0012 of the instant specification states that “does not attempt to aggregate information into a central database or repository. Rather, the system allows the decentralized entities to search for the data requested directly from the physical locations, computers, databases, dealerships, etc. that are selling the vehicles”, Examiner notes that a system without a repository for product availability of all associated vendors is comparable to the system without a central repository as described in the specification of the applicant): one or more memories (Fig. 6; ¶¶0133-0137[The processor 652 can execute instructions within the computing device 650, including instructions stored in the memory 664.]); and at least one processor, each coupled to at least one of the one or more memories and configured to (Fig. 6; ¶¶0133-0137): receive, from a client device, a search request for information about a product (¶0048[For instance, the second device 114 may include an inventory application specific to the central communication server 104 that allows the second device 114 to receive search results from the central communication server 104 and present the search results to a user, e.g., the same user who requested the search results with the first device 102]); queue the search request into a first queue configured to store the search request for a first period of time, wherein the first period of time is based on asynchronous dispatch of at least two of the plurality of decentralized entities (¶0045[one or more of the Vendor C-D devices 110c-d may be included in an automated search device, e.g., a robot. The robot may receive the request for a manual inventory inquiry, determine where the specific product is typically located in the retail location, and scan bar codes of products at the retail location to determine whether or not the specific product is in stock.] in view of ¶0082[If at least one of the vendors for which results have been received has the requested commerce object in inventory, the process asynchronously receives and aggregates search results into groups (412) and ¶0077[The central communication server may place any vendor retail locations that are currently not open in the second group. In some examples, the central communication server may determine that some of the vendor retail locations in the third group will be open within a maximum search time period, and wait to send an inventory inquiry to those vendor retail locations once the respective vendor retail locations are open.]); for each entity of the plurality of decentralized entities, wherein the decentralized entities comprise one or more computerized search entities and one or more physical search entities, the one or more computerized search entities including at least one of a computer or a database, and the one or more physical search entities including at least one of a robot, an autonomous vehicle, or an aerial drone (Fig. 1; ¶¶0029-0031[the central communication server accesses databases for some retailers and may request a manual inventory inquiry for other retailers and provides inventory information to the consumer… The central communication server may retrieve the inventory information from a central server, from multiple servers that are each maintained for a particular retailer, from a device for an entity, e.g., a person or a robot, physically located at a retail location, or a combination of any two or more of these]): transmit the search request to the respective entity, wherein the respective entity is configured to be dispatched based on the search request (Fig. 1; ¶¶0030-0031[the consumer may search for a television using their desktop computer, request information from a central communication server about what retail locations have the television in stock, and then receive and view inventory information on his smart phone from the central communication server, e.g., via text messaging or a mobile application… The central communication server may retrieve the inventory information from a central server, from multiple servers that are each maintained for a particular retailer, from a device for an entity, e.g., a person or a robot, physically located at a retail location, or a combination of any two or more of these. The inventory information is for multiple different retailers that each may have the requested product, e.g., television, in stock. The inventory information may include stock levels, e.g., when the consumer requests multiple of the same product.] in view of ¶0043[The Vendor C-D devices 110c-d each receives a respective request and prompt an entity to perform a manual search for the specific product or type of product.]; Examiner notes that prompting an entity to perform a search is comparable to dispatching an entity); receive respective retrieved information about the product from the dispatched respective entity (Fig. 1; ¶0043[The smart phone may receive input from the employee indicating whether or not the product is in stock, the amount of the product at the Vendor D retail location, if the Vendor D retail location has any comparable products in stock, or a combination of two or more of these.] in view of ¶0103[The central communication server allows the other server to provide product inventory information to one or more users that request the product inventory information, e.g., for different products, from the other server.]); and the respective retrieved information retrieved information, wherein the retrieved information being received from a dispatched entity asynchronously from another retrieved information received from another dispatched entity (Fig. 1; ¶0103[The central communication server allows the other server to provide product inventory information to one or more users that request the product inventory information, e.g., for different products, from the other server.] in view of ¶0082[If at least one of the vendors for which results have been received has the requested commerce object in inventory, the process asynchronously receives and aggregates search results into groups] and ¶0031[The central communication server may retrieve the inventory information from a central server, from multiple servers that are each maintained for a particular retailer, from a device for an entity, e.g., a person or a robot, physically located at a retail location, or a combination of any two or more of these]); the search request, based on the dispatch of each entity of the plurality of decentralized entities (Fig. 1; ¶0103[The central communication server allows the other server to provide product inventory information to one or more users that request the product inventory information, e.g., for different products, from the other server.] in view of ¶0082[If at least one of the vendors for which results have been received has the requested commerce object in inventory, the process asynchronously receives and aggregates search results into groups] and ¶0031[The central communication server may retrieve the inventory information from a central server, from multiple servers that are each maintained for a particular retailer, from a device for an entity, e.g., a person or a robot, physically located at a retail location, or a combination of any two or more of these]); generate a graphical user interface (GUI) with each retrieved information (Figs. 1 and 3; ¶0060[FIG. 3 is an example of a mobile device user interface 300 for displaying inventory search results. For instance, the mobile device may receive search results from the central communication server 104 as the search results become available and present the search results in the mobile device user interface 300.]); the each retrieved information, based on the generation of the GUI (Figs. 1 and 3; ¶0060[FIG. 3 is an example of a mobile device user interface 300 for displaying inventory search results. For instance, the mobile device may receive search results from the central communication server 104 as the search results become available and present the search results in the mobile device user interface 300.]): and transmit the GUI to the client device for display (Figs. 1-3; ¶¶0060-0063[FIG. 3 is an example of a mobile device user interface 300 for displaying inventory search results… the mobile device will periodically receive data from the central communication server 104 and use the data to present messages about product inventory updates on a display]). Although Cumberland discloses receiving a search request about a product, Cumberland does not explicitly disclose request for information about a vehicle. Although Cumberland discloses receiving information about a product from dispatched entities, Cumberland does not explicitly disclose receiving information about a vehicle. Although Cumberland discloses retrieved information being received from dispatched entities, Cumberland does not explicitly disclose queue into a second queue configured to store for a second period of time, the second period of time is based on the retrieved information being received. Although Cumberland discloses a search request and dispatch of entities, Cumberland does not explicitly disclose remove from the first queue based on the first period of time and the dispatching. Although Cumberland discloses generating a GUI with retrieved information, Cumberland does not explicitly disclose information stored in the second queue about the vehicle. Although Cumberland discloses a search request and dispatch of entities, Cumberland does not explicitly disclose remove from the second queue based on the second period of time and the generating. However, Simoudis teaches receiving information about a vehicle, queuing information for a period of time, storing information in a queue, and removing information from a queue (Col. 21, lines 13-45[For instance, a requesting application (e.g., insurance application) may send to the OEM system associated with a target vehicle (or group of vehicles) a request indicating the type of data and the frequency of such data are needed from the target vehicle… Upon receiving the request, the data orchestrator may push the request to a queue and send back a response message to the OEM system to acknowledge receipt of the request. The OEM system may then send a message to the requesting application indicating the request has been logged… in addition to passing the request/response message, the OEM system/application may send a message to the data orchestrator instructing the data orchestrator to delete the transmission request from the queue when a transmission period is completed (e.g., upon receiving a completion message from the data orchestrator). The data orchestrator may then delete the entry from the queue and send a message to the OEM system indicating the entry is deleted]). The system of Simoudis is applicable to the system of Cumberland as they share characteristics and capabilities, namely, they are both targeted to generating and managing data. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the search request and dispatch of entities as disclosed by Cumberland to include queuing information about a vehicle and removing information from a queue as taught by Simoudis. One of ordinary skill in the art would have been motivated to expand the system of Cumberland in order to determine which of (which portion of) the vehicle data is to be communicated to which data center or third-party entity, and when such data is transmitted (Col. 2, lines 39-41). Regarding Claim 17, Cumberland in view of Simoudis teaches the computing system of claim 15, Cumberland further discloses wherein the respective retrieved information received from a subset of the decentralized entities is received asynchronously (¶0045[one or more of the Vendor C-D devices 110c-d may be included in an automated search device, e.g., a robot. The robot may receive the request for a manual inventory inquiry, determine where the specific product is typically located in the retail location, and scan bar codes of products at the retail location to determine whether or not the specific product is in stock.] in view of ¶0082[If at least one of the vendors for which results have been received has the requested commerce object in inventory, the process asynchronously receives and aggregates search results into groups (412) and ¶0077[The central communication server may place any vendor retail locations that are currently not open in the second group. In some examples, the central communication server may determine that some of the vendor retail locations in the third group will be open within a maximum search time period, and wait to send an inventory inquiry to those vendor retail locations once the respective vendor retail locations are open.]). Regarding Claim 18, Cumberland in view of Simoudis teaches the computing system of claim 15, Cumberland further discloses wherein the respective retrieved information received from a subset of the decentralized entities is received in real-time (¶0069[the central communication server searches the central database, or another database, for vendor retail locations to contact regarding product inventory information for the requested commerce object. Some of these vendor retail locations may have inventory data available in real-time] in view of Claim 1[performing real-time searching for inventory data of the requested commerce object in the central database that has been maintained with up-to-date information about potential vendors' respective inventories via data integration by communicating with the central database in response to receiving the information from the first user device identifying the requested commerce object for which available inventory is sought]). Regarding Claim 21, Cumberland in view of Simoudis teaches the method of claim 1, Cumberland further discloses the transmitting the search request to the respective entity (Fig. 1; ¶¶0030-0031 in view of ¶0043), the operations further comprising: notifying, by the one or more computing devices, the respective entity via an application programming interface (Figs. 1 and 4; ¶0108[the central communication server may send messages to the mobile device using a notification service of the mobile device, a specific inventory application installed on the mobile device, or both. In some implementations, the central communication server may validate the mobile device to ensure that the mobile device should be associated with the vendor retail location.] in view of ¶0095[the central communication server may use an application programming interface (API) to communicate with the other server. For instance, the other server may use a method or a message format from the API to provide the central communication server with a request message about the requested commerce object for which available inventory is sought and the geographical area in which inventory information is requested.]). Regarding Claim 22, Cumberland in view of Simoudis teaches the method of claim 1, Cumberland further discloses wherein the one or more physical search entities are configured to identify one or more products by scanning one of a quick response (QR) code, tag, vehicle identification number, or radio frequency identification (RFID) chip (¶0032[When an entity performs a determination of whether or not a particular item is in stock, or the amount of inventory in stock, the entity may use a bar code scanner, a mobile device, e.g., with an inventory application, or another method.]). Although Cumberland discloses identifying products by scanning, Cumberland does not explicitly disclose identifying vehicles. However, Simoudis teaches receiving information about a vehicle (Col. 21, lines 13-45[For instance, a requesting application (e.g., insurance application) may send to the OEM system associated with a target vehicle (or group of vehicles) a request indicating the type of data and the frequency of such data are needed from the target vehicle… Upon receiving the request, the data orchestrator may push the request to a queue and send back a response message to the OEM system to acknowledge receipt of the request. The OEM system may then send a message to the requesting application indicating the request has been logged… in addition to passing the request/response message, the OEM system/application may send a message to the data orchestrator instructing the data orchestrator to delete the transmission request from the queue when a transmission period is completed (e.g., upon receiving a completion message from the data orchestrator). The data orchestrator may then delete the entry from the queue and send a message to the OEM system indicating the entry is deleted]). The method of Simoudis is applicable to the method of Cumberland as they share characteristics and capabilities, namely, they are both targeted to generating and managing data. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the search request and dispatch of entities as disclosed by Cumberland to include queuing information about a vehicle and removing information from a queue as taught by Simoudis. One of ordinary skill in the art would have been motivated to expand the method of Cumberland in order to determine which of (which portion of) the vehicle data is to be communicated to which data center or third-party entity, and when such data is transmitted (Col. 2, lines 39-41). Regarding Claim 24, Cumberland in view of Simoudis teaches the non-transitory computer readable medium of claim 8, Cumberland further discloses the transmitting the search request to the respective entity comprising: notifying the respective entity via an application programming interface (Figs. 1 and 4; ¶0108[the central communication server may send messages to the mobile device using a notification service of the mobile device, a specific inventory application installed on the mobile device, or both. In some implementations, the central communication server may validate the mobile device to ensure that the mobile device should be associated with the vendor retail location.] in view of ¶0095[the central communication server may use an application programming interface (API) to communicate with the other server. For instance, the other server may use a method or a message format from the API to provide the central communication server with a request message about the requested commerce object for which available inventory is sought and the geographical area in which inventory information is requested.]). Regarding Claim 25, Cumberland in view of Simoudis teaches the non-transitory computer readable medium of claim 8, Cumberland further discloses wherein the one or more physical search entities are configured to identify one or more products by scanning one of a quick response (QR) code, tag, vehicle identification number, or radio frequency identification (RFID) chip (¶0032[When an entity performs a determination of whether or not a particular item is in stock, or the amount of inventory in stock, the entity may use a bar code scanner, a mobile device, e.g., with an inventory application, or another method.]). Although Cumberland discloses identifying products by scanning, Cumberland does not explicitly disclose identifying vehicles. However, Simoudis teaches receiving information about a vehicle (Col. 21, lines 13-45[For instance, a requesting application (e.g., insurance application) may send to the OEM system associated with a target vehicle (or group of vehicles) a request indicating the type of data and the frequency of such data are needed from the target vehicle… Upon receiving the request, the data orchestrator may push the request to a queue and send back a response message to the OEM system to acknowledge receipt of the request. The OEM system may then send a message to the requesting application indicating the request has been logged… in addition to passing the request/response message, the OEM system/application may send a message to the data orchestrator instructing the data orchestrator to delete the transmission request from the queue when a transmission period is completed (e.g., upon receiving a completion message from the data orchestrator). The data orchestrator may then delete the entry from the queue and send a message to the OEM system indicating the entry is deleted]). The system of Simoudis is applicable to the system of Cumberland as they share characteristics and capabilities, namely, they are both targeted to generating and managing data. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the search request and dispatch of entities as disclosed by Cumberland to include queuing information about a vehicle and removing information from a queue as taught by Simoudis. One of ordinary skill in the art would have been motivated to expand the system of Cumberland in order to determine which of (which portion of) the vehicle data is to be communicated to which data center or third-party entity, and when such data is transmitted (Col. 2, lines 39-41). Regarding Claim 27, Cumberland in view of Simoudis teaches the computing system of claim 15, Cumberland further discloses wherein to transmit the search request to the respective entity, the at least one processor is further configured to: notify the respective entity via an application programming interface (Figs. 1 and 4; ¶0108[the central communication server may send messages to the mobile device using a notification service of the mobile device, a specific inventory application installed on the mobile device, or both. In some implementations, the central communication server may validate the mobile device to ensure that the mobile device should be associated with the vendor retail location.] in view of ¶0095[the central communication server may use an application programming interface (API) to communicate with the other server. For instance, the other server may use a method or a message format from the API to provide the central communication server with a request message about the requested commerce object for which available inventory is sought and the geographical area in which inventory information is requested.]). Regarding Claim 28, Cumberland in view of Simoudis teaches the computing system of claim 15, Cumberland further discloses wherein the one or more physical search entities are configured to identify one or more products by scanning one of a quick response (QR) code, tag, vehicle identification number, or radio frequency identification (RFID) chip (¶0032[When an entity performs a determination of whether or not a particular item is in stock, or the amount of inventory in stock, the entity may use a bar code scanner, a mobile device, e.g., with an inventory application, or another method.]). Although Cumberland discloses identifying products by scanning, Cumberland does not explicitly disclose identifying vehicles. However, Simoudis teaches receiving information about a vehicle (Col. 21, lines 13-45[For instance, a requesting application (e.g., insurance application) may send to the OEM system associated with a target vehicle (or group of vehicles) a request indicating the type of data and the frequency of such data are needed from the target vehicle… Upon receiving the request, the data orchestrator may push the request to a queue and send back a response message to the OEM system to acknowledge receipt of the request. The OEM system may then send a message to the requesting application indicating the request has been logged… in addition to passing the request/response message, the OEM system/application may send a message to the data orchestrator instructing the data orchestrator to delete the transmission request from the queue when a transmission period is completed (e.g., upon receiving a completion message from the data orchestrator). The data orchestrator may then delete the entry from the queue and send a message to the OEM system indicating the entry is deleted]). The system of Simoudis is applicable to the system of Cumberland as they share characteristics and capabilities, namely, they are both targeted to generating and managing data. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the search request and dispatch of entities as disclosed by Cumberland to include queuing information about a vehicle and removing information from a queue as taught by Simoudis. One of ordinary skill in the art would have been motivated to expand the system of Cumberland in order to determine which of (which portion of) the vehicle data is to be communicated to which data center or third-party entity, and when such data is transmitted (Col. 2, lines 39-41). Claim(s) 23, 26, and 29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cumberland in view of Simoudis in view of Milne et al. (US 2023/0315271 A1). Regarding Claim 23, Cumberland in view of Simoudis teaches the method of claim 1, Cumberland further discloses wherein the GUI is configured to filter the each retrieved information (¶0051[the central communication server 104, the central database 106, or both, may filter a list of potential vendors, vendor retail locations, or both using data that indicates which products or types of products are available or historically have been available at particular vendors or vendor retail locations]). Although Cumberland discloses filtering received information, Cumberland in view of Simoudis teaches the does not explicitly teach filtering based on input from the client device. However, Milne et al., hereinafter, Milne, teaches filtering information based on input from a client device (¶0080[Upon reception of the inputs, the circuitry 202 of the electronic device 102 may be configured to select one or more content filters from a plurality of content filters. Based on first inputs and the selected content filter(s), the circuitry 202 may prepare content. Specifically, the content may be prepared based on application of the selected filter(s) on the first inputs. By way of example, and not limitation, the plurality of content filters may include a filter to replace a color scheme used in the first inputs with a user-defined color scheme associated with the electronic device 102, a filter to change thickness of lines used in the first inputs, a filter to omit one or more inputs of the first inputs for the preparation of the content, a filter to edit the one or more inputs of the first inputs for the preparation of the content, and a filter to add one or more labels in the content to indicate a source of the first inputs.]). The method of Milne is applicable to the method of Cumberland in view of Simoudis as they share characteristics and capabilities, namely, they are all targeted to generating and managing data. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the filtering of retrieved information as taught by Cumberland in view of Simoudis to include filtering information based on user input as taught by Milne. One of ordinary skill in the art would have been motivated to expand the method of Cumberland in view of Simoudis in order to join and exchange information in a meeting session (¶0003). Regarding Claim 26, Cumberland in view of Simoudis teaches the non-transitory computer readable medium of claim 8, Cumberland further discloses wherein the GUI is configured to filter the each retrieved information (¶0051[the central communication server 104, the central database 106, or both, may filter a list of potential vendors, vendor retail locations, or both using data that indicates which products or types of products are available or historically have been available at particular vendors or vendor retail locations]). Although Cumberland discloses filtering received information, Cumberland in view of Simoudis teaches the does not explicitly teach filtering based on input from the client device. However, Milne teaches filtering information based on input from a client device (¶0080[Upon reception of the inputs, the circuitry 202 of the electronic device 102 may be configured to select one or more content filters from a plurality of content filters. Based on first inputs and the selected content filter(s), the circuitry 202 may prepare content. Specifically, the content may be prepared based on application of the selected filter(s) on the first inputs. By way of example, and not limitation, the plurality of content filters may include a filter to replace a color scheme used in the first inputs with a user-defined color scheme associated with the electronic device 102, a filter to change thickness of lines used in the first inputs, a filter to omit one or more inputs of the first inputs for the preparation of the content, a filter to edit the one or more inputs of the first inputs for the preparation of the content, and a filter to add one or more labels in the content to indicate a source of the first inputs.]). The system of Milne is applicable to the system of Cumberland in view of Simoudis as they share characteristics and capabilities, namely, they are all targeted to generating and managing data. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the filtering of retrieved information as taught by Cumberland in view of Simoudis to include filtering information based on user input as taught by Milne. One of ordinary skill in the art would have been motivated to expand the system of Cumberland in view of Simoudis in order to join and exchange information in a meeting session (¶0003). Regarding Claim 29, Cumberland in view of Simoudis teaches the computing system of claim 15, Cumberland further discloses wherein the GUI is configured to filter the each retrieved information (¶0051[the central communication server 104, the central database 106, or both, may filter a list of potential vendors, vendor retail locations, or both using data that indicates which products or types of products are available or historically have been available at particular vendors or vendor retail locations]). Although Cumberland discloses filtering received information, Cumberland in view of Simoudis teaches the does not explicitly teach filtering based on input from the client device. However, Milne teaches filtering information based on input from a client device (¶0080[Upon reception of the inputs, the circuitry 202 of the electronic device 102 may be configured to select one or more content filters from a plurality of content filters. Based on first inputs and the selected content filter(s), the circuitry 202 may prepare content. Specifically, the content may be prepared based on application of the selected filter(s) on the first inputs. By way of example, and not limitation, the plurality of content filters may include a filter to replace a color scheme used in the first inputs with a user-defined color scheme associated with the electronic device 102, a filter to change thickness of lines used in the first inputs, a filter to omit one or more inputs of the first inputs for the preparation of the content, a filter to edit the one or more inputs of the first inputs for the preparation of the content, and a filter to add one or more labels in the content to indicate a source of the first inputs.]). The system of Milne is applicable to the system of Cumberland in view of Simoudis as they share characteristics and capabilities, namely, they are all targeted to generating and managing data. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the filtering of retrieved information as taught by Cumberland in view of Simoudis to include filtering information based on user input as taught by Milne. One of ordinary skill in the art would have been motivated to expand the system of Cumberland in view of Simoudis in order to join and exchange information in a meeting session (¶0003). Response to Arguments Applicant’s arguments on pages 10-16 of the remarks filed 12/01/2025, with respect to the previous 35 USC § 101 rejections have been fully considered but are not persuasive. Applicant argues on pages 10-12 of the remarks that the amended claims do not recite any methods of organizing human activity. Examiner respectfully disagrees. According to the MPEP 2106.04, the question of whether a claim is “directed to” a judicial exception in Step 2A is now evaluated using a two-prong inquiry. Prong One asks if the claim “recites” an abstract idea, law of nature, or natural phenomenon. Under that prong, the mere inclusion of a judicial exception such as a method of organizing human activity in a claim means that the claim “recites” a judicial exception (see MPEP 2106.04 [“The mere inclusion of a judicial exception such as a mathematical formula (which is one of the mathematical concepts identified as an abstract idea in MPEP § 2106.04(a)) in a claim means that the claim "recites" a judicial exception under Step 2A Prong One.”]). Additionally, MPEP 2106.04 instructs examiners to refer to the groupings of abstract ideas enumerated in MPEP 2106.04(a)(2) (i.e., mathematical concepts, certain methods of organizing human activities, and mental processes) in order to identify abstract ideas. As noted above and in the previous office action, the claims recite performing vehicle transactions over the web. This is an abstract idea because it is a concept of business relations which makes it a method of organizing human activity (i.e., one of the groupings of abstract ideas enumerated in MPEP 2106.04(a)(2)). Furthermore, “data queries, queues, and dispatch of decentralized entities” are also part of the abstract idea and do not integrate the abstract idea into a practical application nor provide a technical improvement. Applicant further argues on pages 12-14 of the remarks that the amended claims integrate the abstract idea into a practical application and provide a technical improvement. Examiner respectfully disagrees. A method for performing a search using a plurality of decentralized entities in a system without a central repository, the method comprising: receiving, from a client, a search request for information about a vehicle; queuing, the search request into a first queue configured to store the search request for a first period of time, wherein the first period of time is based on asynchronous dispatch of at least two of the plurality of decentralized entities; for each entity of the plurality of decentralized entities, wherein the decentralized entities comprise one or more search entities and one or more physical search entities, the one or more search entities, and the one or more physical search entities: transmitting, the search request to the respective entity, wherein the respective entity is configured to be dispatched based on the search request; receiving, respective retrieved information about the vehicle from the dispatched respective entity; and queuing, the respective retrieved information into a second queue configured to store retrieved information for a second period of time, wherein the second period of time is based on the retrieved information being received from a dispatched entity asynchronously from another retrieved information received from another dispatched entity; removing, the search request from the first queue, based on the first period of time and the dispatching of each entity of the plurality of decentralized entities; generating, a graphical user interface (GUI) with each retrieved information stored in the second queue about the vehicle; removing, the each retrieved information from the second queue, based on the second period of time and the generating the GUI: and transmitting, the GUI to the client for display are all part of the abstract idea. The mere execution of the abstract idea on generic components which are recited and described in the specification at a high level and as generic does not overcome the rejection. Such components are a computer, computing devices, computerized entities, database, robot, autonomous vehicle, aerial drone, memory, and processors which are described as generic in Figs. 1, 4, and ¶0006, ¶¶0040-0041 of the instant specification. Furthermore, combining searching methods and aggregating the results to provide an up-to-date result, obtaining inventory data from physical locations and dealerships, accumulating different search requests, maintaining search requests, dispatching to retrieve information based on the search requests and presenting results to a user are also part of the abstract. Applicant argues on pages 14-16 of the remarks that the amended claims are not well-understood, routine, or conventional. Examiner respectfully disagrees. the additional elements fail to provide significantly more also because the claim simply appends well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception. For example, the additional elements of claims 1, 11, and 20 utilize operations the courts have held to be well-understood, routine, and conventional (see: MPEP 2106.05(d)(II)), including at least: receiving or transmitting data over a network, storing or retrieving information from memory, presenting offers Accordingly, Examiner maintains that the invention is directed to a judicial exception without significantly more. The claims recite an abstract idea. This judicial exception is not integrated into a practical application. The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Thus the 35 USC §101 rejections are maintained. Applicant’s arguments on pages 16-19 of the remarks filed 12/01/2025, with respect to the previous 35 USC § 103 rejections have been fully considered but are moot in view of the new 103 rejection of the amended claims. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to AHOORA LADONI whose email is Ahoora.Ladoni@uspto.gov and telephone number is (703) 756-5617. The examiner can normally be reached M-F 0900–1700 ET. Examiner interviews are available via telephone, in-person and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. 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/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. /AHOORA LADONI/Examiner, Art Unit 3689 /VICTORIA E. FRUNZI/Primary Examiner, Art Unit 3689 2/20/2026
Read full office action

Prosecution Timeline

Jun 07, 2023
Application Filed
Aug 15, 2023
Response after Non-Final Action
Apr 09, 2025
Non-Final Rejection — §101, §103
Jul 15, 2025
Response Filed
Sep 12, 2025
Final Rejection — §101, §103
Oct 09, 2025
Applicant Interview (Telephonic)
Oct 10, 2025
Examiner Interview Summary
Dec 01, 2025
Request for Continued Examination
Dec 11, 2025
Response after Non-Final Action
Feb 20, 2026
Non-Final Rejection — §101, §103 (current)

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
0%
Grant Probability
0%
With Interview (+0.0%)
3y 0m
Median Time to Grant
High
PTA Risk
Based on 13 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month