DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10/14/2025 has been entered.
Status of Claims
This office action is in response to applicant’s amendments to application number 18/296,037 filed on 2/3/2026, in which Claims 1-12 are presented for examination. The applicant amends Claim 1 and 10 and cancels Claims 8 and 11.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. EP22167175.3, filed on 04/07/2022.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/05/2023 has been received and considered.
Response to Arguments
Applicant's arguments, see pgs. 2 and 19, filed 2/3/2026, with respect to the abstract have been fully considered and are persuasive. Therefore, the objection to the abstract set forth in the office action of 11/13/2025 has been withdrawn.
In light of the amendments to the claims and for consistency of the claim language, a new objection to Claim 9 and new rejections under 35 U.S.C. 112(b) are introduced. Further details are provided below.
Applicant’s arguments, see pgs. 7-12, filed 2/3/2026, with respect to rejection of Claims 1-12 under 35 U.S.C. 101 have been fully considered but they are not persuasive.
Applicant argues that the functionality performed by the API affirms that Claim 1 is directed to operations performed beyond the human mind and user interaction, by reciting using an API response to detect real-time changes and automatically update an order using API communication. Applicant states that the amended functionality can only be performed with hardware and software of a computing system. Additionally, applicant argues that the amendments to Claim 1 also provides an improvement to technology, or a technical field, by identifying that the API’s aid the method of service order completion and performing automatic updates, which goes beyond, by ensuring that a vehicle operator and a service provider are dynamically updated. Finally, Applicant argues that the API functionality solves a problem by providing real-time and automatic updates, integrated by the computing machine recited in Claim 1.
Examiner respectfully disagrees. As stated in MPEP 2106.05(a), for the claim language to identify an improvement, the language must identify details or steps that go beyond automation of a manual task, “[f]or example, in McRO, the court relied on the specification’s explanation of how the particular rules recited in the claim enabled the automation of specific animation tasks that previously could only be performed subjectively by humans, when determining that the claims were directed to improvements in computer animation instead of an abstract idea. McRO, 837 F.3d at 1313-14, 120 USPQ2d at 1100-01.” A human mind can detect a change in the estimated arrival time and further, a person can use the detected change in estimated arrival time to update a previously requested service order, therefore using an API to automatically perform updates to a service order, as recited in the amended claim language, only automates a manual process and does not provide an improvement to the order updating process. Therefore, Examiner maintains the rejection of Claims 1-12 under 35 U.S.C. 101 set forth in the office action of 11/13/2025 and in light of the amendments, an updated rejection for Claims 1-7, 9-10, and 12 under 35 U.S.C. 101 is provided. Further details are provided below.
Applicant’s arguments, see pgs. 3-6 and 12-17, filed 2/3/2026, with respect to rejection of Claims 1-12 under 35 U.S.C. 103 have been fully considered but are moot because they are directed towards the amendments in Claims 1 and 10. Therefore, Examiner maintains the rejection of Claims 1-12 under 35 U.S.C. set forth in the office action of 11/13/2025. In light of the amendments a new rejection of Claims 1-7, 9-10, and 12 under 35 U.S.C. 103 is made, however, Examiner would like to address Applicant’s arguments. Further details are provided below.
Applicant argues that Davies and Yien are silent regarding the amended language for detecting a changed estimated or determined arrival time based on the API response and that Mimassi does not teach using an API. Applicant similarly argues that Davies and Yien do not teach an API with the capability for automatically updating the service order to the service provider with an updated arrival time, and again, Mimassi is silent regarding the amended language.
Examiner respectfully disagrees. The amended claim language of Claim 1 and 10 applies the same language of cancelled Claims 8 and 11, “[the system is arranged for] updating the service order with a new estimated arrival time for the host vehicle to the service provider in response to a changed estimated or determined arrival time” and adds “based on an API response, detecting” and “automatically updating the service order, via the one or more APIs.” The broadest reasonable interpretation of the updated claim language is detecting a change in the vehicle arriving at a service provider and automatically updating the service order based on the updated arrival time, using an API, but does not require “automatically updating the service order to the service provider” from the vehicle. The original rejection of cancelled Claims 8 and 11 relied on [Mimassi, pg. 10, Claim 1], which describes a system capable of tracking a user’s location and updating an order based on an updated time of arrival, by periodically querying the customer’s location and estimating the time of arrival. Although Mimassi does not do this via an API, Davies teaches using an API stored in the vehicle for the purposes of service orders and Yien teaches using an API to update service orders. More specifically, [Davies, pg. 7, paras 0074-0075], discusses tracking the location of a service provider and providing updates to a user, which demonstrates the capability to of the API to communicate changes and update requests, such as providing updated estimated time of arrival. Further details are provided in the updated rejection below.
Claim Objections
Claim 9 is objected to because of the following informalities:
Claim 9 depends from cancelled Claim 8. For examination purposes, Claim 9 will be read as depending from Claim 1.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-7, 9-10, and 12 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 (line 10) recites “the at least one service provider” and Claim 1 (line 16), Claim 3 (line 3), Claim 4 (line 3), and Claim 10 (line 20) recite “the service provider.” Similarly, Claim 1 (line 15), Claim 4 (line 1), Claim 5 (line 1), Claim 6 (line 1), Claim 7 (line 1), and Claim 10 (line 19) recite “the service order.” Claim 1 (lines) and Claim 10 (lines) do discuss “available service providers” and “at least one service order,” however, the subsequent uses of “service provider” and “service order” do not follow this same naming convention. Therefore, there is insufficient antecedent basis for this limitation in the claims. For examination purposes and consistency among the claims, Claim 1 (line 10) will be read as “at least one service provider” and Claim 1 (line 16), Claim 3 (line 3), Claim 4 (line 3), and Claim 10 (line 20) will be read as “the at least one service provider.” Similarly, Claim 1 (line 15), Claim 4 (line 1), Claim 5 (line 1), Claim 6 (line 1), Claim 7 (line 1), and Claim 10 (line 19) will be read as “the at least one service order.” Further, based on Claim 1 (line 15), Claim 9 (line 3), will be read as “the at least one updated service order.”
Claims 2 and 12 are rejected by dependency on Claims 1 and 10, respectively.
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-7, 9-10 and 12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1. (Currently Amended) A method for providing service to a vehicle operator, wherein the method comprises:
determining a starting destination, a target destination, and a route there between for a host vehicle; [mental process]
determining available service providers along the route; [mental process]
sending a request via one or more application programming interfaces (APIs) for at least one service order, [post-solution activity, generally linking] the one or more APIs executing on a processor of the host vehicle [apply it], and communicating specific host vehicle information or host vehicle operator information to the at least one service provider along the route [post-solution activity, generally linking];
receiving, via the one or more APIs, an API response to the at least one service order, the API response including a confirmation status of the at least one service order [post-solution activity, generally linking]; [[and]]
based on the API response [data gathering]detecting a changed estimated or determined arrival time [mental process]; and
automatically updating the service order, via the one or more APIs, with a new estimated arrival time for the host vehicle to the service provider in response to detecting the changed estimated or determined arrival time [post-solution activity, generally linking].
101 Analysis – Step 1: Statutory Category – Yes
The claim recites a method for providing service to a vehicle operator comprising steps for determining a route and available service providers, transmitting a service order request, receiving and providing a service order confirmation status, and updating the service order based on a changed estimated arrival time.
Step 2A Prong One Evaluation: Judicial Exception – Yes – Abstract Idea
The claim recites mental processes, as bolded above. These limitations, as drafted, are simple processes that, under their broadest reasonable interpretation, could be performed in the human mind. For example, a person wishing to travel from a start destination to a target destination could form a route in their mind and identify service providers known to this route and further monitor changes in the estimated arrival time to the service provider. They would not be restricted by the claim limitations to perform these steps.
Additionally, the claim recites a method of organizing human activity. These limitations, as drafted and given their broadest reasonable interpretation, provide a method of managing behavior or interactions between people. The limitations describe a user communicating a request or an updated request to a service provider and a service provider responding to the request.
Step 2A Prong Two Evaluation: Practical Application – No
This judicial exception is not integrated into a practical application because the additional element (as marked above) do not impose any meaningful limit on the judicial exception.
Sending a service order request, interacting with a service provider to communicate host vehicle and operator information and receive a confirmation, providing a confirmation status, and automatically updating the service order are recited at a high level and are a form of insignificant post-solution activity.
The API used to complete these steps is recited at a high level and amounts to nothing more than generally linking the abstract idea to a particular technological environment or field of use.
Receiving information from an API is recited at a high level, and amounts to mere data gathering, which is a form of insignificant extra-solution activity.
The processor and user interface merely act as generic computers used to apply and automate the abstract ideas.
Step 2B Evaluation:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional claim elements, as stated for Step 2A Prong Two, do no more than generally linking the abstract idea to a particular technological environment or field of use, provide extra-solution activity, and provide application of the abstract idea, and does not provide an inventive concept.
Sending a service order request, interacting with a service provider to communicate host vehicle and operator information and receive a confirmation, providing a confirmation status, and automatically updating the service order are considered insignificant post-solution activity. The specification recites [pgs. 11-12, lines 25-35 and lines 1-8], “application programming interfaces, APls, which specify how software components may interact with each other. […] The API of the vehicle operator service system 1 may be configured to interact with an API of an associated service provider to enable the sending of data to the service provider API in the form of a message [… which] may be generated from text input […] to the vehicle operator service system 1 […]. In some cases, pre-recorded voice and optionally video instructions may be provided to the vehicle operator service system API to be transmitted to the service provided API. In some examples, a direct connection between the vehicle operator service system API and the service provider API may be established to enable instantaneous (or near instantaneous) transfer of [… and] live interaction between the service provider API and that of the vehicle operator service system 1,” and does not provide any indication that sending the order request (via API) and communicating information to the service provider is anything other than the standard method of using APIs to communicate information and requests between different systems. Additionally, the specification recites [pg. 16, lines 3-10] “The service orders may be sent and received via a processing unit and communication system with an API (application programming interface). If the service orders are accepted […] an affirmative confirmation status is sent from communication means associated with the charging station E and restaurant D to the host vehicle or a system thereof. The confirmation status may be provided to the vehicle operator via a user interface […] or via a voice message,” and does not provide any indication that receiving the order confirmation and providing the confirmation status is anything other than the standard method for receiving and displaying data. Finally, the specification recites [pg. 10, lines 27-31], “Thus, a service order indicative of a electrical charging station booking, initially scheduled with a duration between 15:00 and 15:40, may be manually or automatically updated with a new service order or request for the time slot 15:20-16:00 if it is determined or estimated that the estimated arrival time to the service provider is delayed from 15:00 to 15:20, e.g. due to traffic jam,” and does not provide any indication that automatically updating the service order is anything other than submitting a request to change the service order based on an updated estimated arrival time. Therefore, the specification indicates that sending a service order request, interacting with a service provider to communicate host vehicle and operator information and receive a confirmation, providing a confirmation status, and automatically updating the service order are well‐understood, routine, and conventional functions as they are claimed in a merely generic manner.
Independent Claim 10 does not recite any further limitations that cause the claims to be patent eligible. Rather, the limitations of the claim are directed toward a system for performing the method of Claim 1, and does not integrate the judicial exception into a practical application. Therefore, Claim 10 is not patent eligible under same rationale as provided for Claim 1.
Dependent Claims 2-7, 9 and 12 do not recite any further limitations that cause the claims to be patent eligible. The limitations of the dependent claims further narrow the abstract idea, and thus can also be performed as a mental process, in the human mind. Therefore, dependent Claims 2-7, 9 and 12 are not patent eligible under the same rationale as provided for in the rejection of independent Claim 1 and Claim 10.
Therefore, Claims 1-7, 9-10 and 12 are ineligible under 35 USC §101.
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.
The factual inquiries 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 nonobviousness.
Claims 1-3 and 5-7 are rejected under 35 U.S.C. 103 as being unpatentable over Delorme et al., WO 97/48065 (hereinafter "Delorme"), in view of DeLuca et al., PG Pub US-2020/0217679-A1 (hereinafter "DeLuca"), Davies et al., PG Pub US-2018/0336611-A1 (hereinafter "Davies"), and Mimassi, PG Pub US-2021/0158407-A1 (hereinafter "Mimassi").
Regarding Claim 1, Delorme discloses: (Currently Amended) A method for providing service to a vehicle operator. See [Delorme, pgs. 101-102, lines 30-33/1-2, Claim 25], which describes the method in which the user is provided a travel route including user selected POI along the route, "assembling and displaying […] a user-customized travelog for preview […], said travelog including […] selected POIs […] along said user-defined travel route," where the user is further described as being a vehicle operator (see for example: [Delorme, pg. 66, line 7] "the user of an in-vehicle embodiment"), and the POIs are further described as services, see for example: [Delorme, pg. 12, lines 6-12], “[…] POI types of the CARPS database may be selected for example from […] restaurants, […], ferries, and […] other geographical landmarks, etc. […].”
Delorme further discloses: wherein the method comprises: determining a starting destination, a target destination, and a route there between for a host vehicle. See [Delorme, pg. 1, lines 15-16], where the invention is described as a “travel planning guide for determining a route between a user selected travel origin and travel destination” and [Delorme, pg. 11, lines 6-8], where the routes are described as multiple types, including for vehicles, “transportation routes depicted on the electronic maps may include all forms of transportation routes for example selected from the group consisting of vehicle, […].”
Delorme further discloses: determining available service providers along the route. See [Delorme, pg. 1, lines 18-20], where the defined software allows the user to select POIs along the route, “the user can also select among a plurality of types of geographically locatable points of interest (POIs) […] along the travel route.” POIs are described as service providers as identified above, see again [Delorme, pg. 12, lines 6-12].
Delorme does not disclose: sending a request via one or more application programming interfaces (APIs) for at least one service order, the one or more APIs executing on a processor of the host vehicleand communicating specific host vehicle information or host vehicle operator information to the at least one service provider along the route; receiving, via the one or more APIs, an API response to the at least one service order, the API response including a confirmation status of the at least one service order; [[and]] based on the API responsedetecting a changed estimated or determined arrival time; and automatically updating the service order, via the one or more APIs, with a new estimated arrival time for the host vehicle to the service provider in response to detecting the changed estimated or determined arrival time.
However, Deluca teaches: a request […] for at least one service order, […], and communicating specific host vehicle information or host vehicle operator information to the at least one service provider along the route. See [Deluca, pg. 6, col 2, para 0046], where the directional guidance system can reserve locations, such as orders, “the system for providing directional guidance for an electric vehicle 100 may also be configured for automatically reserving the use of a location of interest. Reserving the use may include automatically making a reservation, an appointment, purchasing a ticket, obtaining admission, placing an order, and the like.” See [Deluca, pg. 4, col 2, para 0035], which describes the integration of user preferences and vehicle information, “the receiving module 132 may be configured for receiving user information data from, for example, […] the receiving module 132 receives user preferences from users through the user device” and [Deluca, pg. 2, col 1, paras 18-19], “a system for considering relevant locations of interest, availability of charging stations, and charge data in determining route options for an electric vehicle. [...] The system for providing directional guidance [...] may obtain vehicle information (such as current charge levels, historical vehicle needs [... and ...] The electric vehicle system 110 may track and store [...] electric motor data, charging data, driving data, [...] driving preferences of users, and the like.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Delorme with Deluca to include the capability to request a service order based on user and vehicle information, and along the travel route. Doing so would allow the user to align route planning and stops to their preferences and improve interest at and time spent at trip stops [Deluca, pg. 2, col 1, para 0015] and to optimize the total trip process [Deluca, pg. 2, col 1, para 0017].
Deluca further teaches using an application programming interface (API) to communicate between the different parts of the guidance system, which sends the order, however Deluca does not explicitly teach: sending a request via one or more application programming interfaces (APIs) for at least one service order, the one or more APIs executing on a processor of the host vehicleand […]; receiving, via the one or more APIs, an API response to the at least one service order, the API response including a confirmation status of the at least one service order; [[and]] based on the API responsedetecting a changed estimated or determined arrival time; and automatically updating the service order, via the one or more APIs, with a new estimated arrival time for the host vehicle to the service provider in response to detecting the changed estimated or determined arrival time. See [Deluca, pg. 3, col 1, paras 0023-0024], which explains that the mapping platform may include sensors or systems to provide maps and may be part of the vehicle or user device, and it may be an API, “The system for providing directional guidance for an electric vehicle 100 may include a mapping platform 111. The mapping platform 111 may include one or more navigational sensors and systems to provide digital maps, in one embodiment. The mapping platform 111 may be included as part of the electric vehicle, such as part of the electric vehicle system 110, the user device 113, or it may be a separate system. The mapping platform 111 may be a mapping application programming interface (API).” See also [Deluca, pg. 4, col, 2, paras 0034-0035], which explains that the receiving module may receive information from the mapping platform via an API or from the user device, “[…] the receiving module may receive charging location coordinates from the mapping platform 111, from an API, for example. The receiving module 132 may provide information received by the computer system 120 from the mapping platform 111 to be stored in the data repository 125. [0035] Still further, the receiving module 132 may be configured for receiving user information data from, for example, the user device 113.”
However, Mimassi teaches: detecting a changed estimated or determined arrival time; and automatically updating the service order, […], with a new estimated arrival time for the host vehicle to the service provider in response to detecting the changed estimated or determined arrival time. See [Mimassi, pg. 10, col 1, Claim 1], which describes the system capability to track the user’s location and update the preparation time of the order, “receive a customer order at one of the selected business enterprise locations, and for that business location: receive periodic updates of the current location of the customer based on periodic queries to the customer's mobile device; estimate an updated time of arrival based on each periodic update; and adjust a start time for preparation of the customer order for the good or service based on the updated time of arrival.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Delorme with Mimassi to include updating the estimated time of arrival. Doing so also accounts for, improvements relating to placing orders, [Mimassi, Fig. 3], where “time for pickup” and “food preparation times” are considered “customer preferences” and “efficiency factors,” respectively. This further allows the service provider to adjust food preparation time and schedule the order so that it is ready for customer’s arrival [Mimassi, Fig 6].
However, Davies teaches: sending a request via one or more application programming interfaces (APIs) for at least one service order, the one or more APIs executing on a processor of the host vehicle, […] and […]; receiving, via the one or more APIs, an API response to the at least one service order, the API response including a confirmation status of the at least one service order; [[and]] based on the API responsedetecting a change[…]; and [automatically updating the service order,] via the one or more APIs, […]. See [Davies, pg. 3, paras 0040 and 0043], which describe the computer system for communicating service requests between a service requestor and a service provider, which includes computing devices on vehicles that can contain a processor, “[0040] Furthermore, one or more aspects described herein may be implemented through the use of instructions that are executable by one or more processors. These instructions may be carried on a computer-readable medium. […]. Computers, terminals, network-enabled devices (e.g., mobile devices such as cell phones) are all examples of machines and devices that utilize processors, memory, and instructions stored on computer-readable media. […]. [0043] FIG. 1 is a block diagram illustrating an example network computer system 100 in communication with service requester and service provider devices, […]. The network computer system 100 can implement or manage a network service […] that connects service requesters with service providers that are available to fulfill the service requests that service requesters transmit to the network computer system 100. An on-demand provisioning server 130 managing the network service can enable service requesters to submit requests over one or more networks 150 through a service requester application executing on the service requester devices 110. The network service processes and transmits the requests to appropriate service providers by way of a service provider application executing on the service provider devices 120. As used herein, a service requester device 110 and a service provider device 120 can comprise computing devices with functionality to execute designated applications corresponding to the network service managed by the network computer system 100. In many examples, service requester devices 110 and service provider devices 120 can comprise mobile computing devices, such as smartphones, tablet computers, virtual reality or augmented reality headsets, on-board computing systems of vehicles, and the like. Example network services can comprise delivery of food or products, package mailing, shopping, construction, plumbing, home repair, housing or apartment sharing, etc., or can include transportation arrangement services. In an example using transport arrangement services, the service requesters are prospective passengers to be picked up and transported, and the service providers are drivers who transport the service requesters.” See also [Davies, pg. 4, para 0046], which explains that the computer system utilizes servers to exchange data between the service requestor and service provider, using communication over a wireless network using an interface or an API, “According to examples, service interfaces on the on-demand provisioning server 130 and breakpoint server 140 enable the network computer system 100 to exchange data with the service requester devices 110 and the service provider devices 120 over the network 150. For example, the service interfaces can use one or more network resources to exchange communications over one or more wireless networks (e.g., a cellular transceiver, a WLAN transceiver, etc.). The service interfaces can include or implement an externally-facing application programming interface (API) to communicate data with the service requester devices 110 and the service provider devices 120. The externally-facing API can provide access to the on-demand provisioning server 130 or the breakpoint server 140 via secure channels over the network 150 through any number of methods, including web-based forms, programmatic access via restful APIs, Simple Object Access Protocol (SOAP), remote procedure call (RPC), scripting access, etc.” See also [Davies, pg. 8, para 0081], which explains that the network service interacts with the system to provide a confirmation from the service provider to the service requestor, “Once the provider selection engine 460 selects a service provider, the provider interface 420 can transmit the service request data to the selected service provider's device. In addition to the service location and ETA data, the provider interface 420 can transmit requester information, such as a name and photograph of the service requester. Upon receiving the service invitation, the service provider can either accept or reject the invitation. Rejection of the invitation can cause the provider selection engine 460 to determine another service provider from the candidate set of service providers to fulfill the service request. However, if the service provider accepts (e.g., via an acceptance input), then the acceptance input is transmitted back to the on-demand network service 400, which generates and transmits a confirmation of the service provider to the service requester.” Finally see [Davies, pgs. 6-7, paras 0072-0075], which explains that the system has the capability to track and communicate changes, for example, an arrival time of the service provider to the service requestor for providing transportation services, using the on-demand network service, “[0072] FIG. 4 is a block diagram illustrating an on-demand network service 400, in accordance with examples described herein. The on-demand network service 400 can include a provider management interface 420 to communicate over one or more networks with a service provider application running on a service provider device. According to examples, service providers register with the on-demand network service 400 to receive service invitations through the service provider application to fulfill service requests submitted by the service requesters. In an example using transport services, the service requesters are prospective passengers to be picked up and transported, and the service providers are drivers who transport the service requesters. [0073] […]. [0074] In accordance with various examples, the service provider device transmits a provider status, which can include the provider mode, the current location of the service provider, and other provider information, over the network to the provider interface 420. […]. The service provider application can continually update the provider status on a regular schedule or in response to provider input to the service provider device, location changes determined by GPS, service steps performed, etc. The provider interface 420 stores the provider status in a provider datastore 440 (e.g., a database or data structure) accessible by a provider selection engine 460 that processes incoming service requests in order to select service providers to fulfill the service requests. [0075] The on-demand network service 400 can include a service requester interface 410 to communicate with service requester devices over one or more networks via a service requester application. In one implementation, the service requester application can enable the service requester to scroll through various service types. In response to a selection of a particular service type, the on-demand network service 400 can provide estimated time to arrival (ETA) data on a user interface of the service requester application that indicates the shortest ETA of nearby service providers for the service type and/or the locations of nearby service providers for that service type.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Delorme with Davies to include sending requests or updates and receiving confirmation between a service provider and a requestor, using an API. Doing so allows the service provider to receive user-specified data and provides a way for the provider to interact with the system to accept or decline a request [Davies, pg. 1, para 0002], including accounting for service provider breaks or offline periods and coordinating if the request is within an available timeframe [Davies, pg. 2, para 0017]. Additionally, using an API provides a designated application that can be used from a user’s mobile device [Davies, pg. 1, para 0014]. In summary, the coordinated communication between a service provider and a service requestor allows for control, stability, and automation of the scheduling process to provide a better service interaction [Davies, pg. 2, paras 0018-0019].
Regarding Claim 2, Delorme as modified teaches the limitations of Claim 1.
Delorme further discloses: (Previously Presented) […] estimated arrival time […] and/or estimated departure time for the host vehicle from the selected service provider. See [Delorme, FIGURE 1J and FIGURE 1K], which show the route’s list of different types waypoints, associated arrival and departure times, and description [Delorme, pg. 26, lines 12-14], “FIGURE 1J and 152 in FIGURE 1K. Travel Plan list boxes are a form of routing computation output including a list of waypoints, routes, compass directions, nearby town, time and distance estimates for route segments and the overall route.” See also [Delorme, Claim 9, pg. 95, lines 21-23] which also states, “the CARPS […] wherein said waypoints of said electronic maps comprise information including said transportation routes entering and leaving said respective nodes.”
Delorme does not disclose: (Previously Presented) […] wherein the specific host vehicle information, comprises estimated arrival time for the host vehicle at the selected service provider.
However, Deluca teaches: (Previously Presented) […] wherein the specific host vehicle information, comprises estimated arrival time for the host vehicle at the selected service provider. See [Deluca, pg. 6, col 2, para 0046], which describes the placing the automatic reservation accounting for predicted arrival time, "the system […] may automatically make a reservation at the restaurant for the time the user is predicted to arrive at the restaurant, purchase a ticket to a movie of interest to the user at the time the user is predicted to arrive at the movie theater, […]."
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Delorme with Deluca to include estimated arrival time as part of the vehicle information. Doing so would allow the user to align route planning and stops to their preferences and improve interest at and time spent at trip stops [Deluca, pg. 2, col 1, para 0015] and to optimize the total trip process [Deluca, pg. 2, col 1, para 0017].
Regarding Claim 3, Delorme as modified teaches the limitations of Claim 1.
Delorme does not disclose: (Previously Presented) […] wherein the specific host vehicle information comprises information related to host vehicle energy supply need upon arrival at the service provider.
However, Deluca teaches: (Previously Presented) […] wherein the specific host vehicle information comprises information related to host vehicle energy supply need upon arrival at the service provider. See [Deluca, pg. 2, col 1, paras 18-19], which describes a system considering vehicle information which includes information related to charge data and vehicle energy needs, “a system for considering relevant locations of interest, availability of charging stations, and charge data in determining route options for an electric vehicle. [...] The system for providing directional guidance [...] may obtain vehicle information (such as current charge levels, historical vehicle needs [...]_ [...] The electric vehicle system 110 may track and store [...] electric motor data, charging data, driving data, [...] driving preferences of users, and the like.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Delorme with Deluca to include information regarding vehicle energy need upon arrival. Doing so would allow the user to align route planning and stops to their preferences and improve interest at and time spent at trip stops [Deluca, pg. 2, col 1, para 0015] and to optimize the total trip process [Deluca, pg. 2, col 1, para 0017].
Regarding Claim 5, Delorme as modified by teaches the limitations of Claim 1.
Delorme does not disclose: (Previously Presented) […] wherein the service order comprises a restaurant table reservation to a service provider represented as a restaurant.
However, Deluca teaches: (Previously Presented) […] wherein the service order comprises a restaurant table reservation to a service provider represented as a restaurant. See [Deluca, pg. 6, col 2, para 0046], which describes the capability to automatically make reservations at a restaurant, “the system for providing directional guidance for an electric vehicle 100 may automatically make a reservation at the restaurant for the time the user is predicted to arrive at the restaurant[...].”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Delorme with Deluca to include a reservation for a restaurant table. Doing so would allow the user to align route planning and stops to their preferences and improve interest at and time spent at trip stops [Deluca, pg. 2, col 1, para 0015] and to optimize the total trip process [Deluca, pg. 2, col 1, para 0017].
Regarding Claim 6, Delorme as modified teaches the limitations of Claim 5.
Delorme does not disclose: (Previously Presented) […] wherein the service order comprises information on selected food and/or drink items, previously selected by the vehicle operator.
However, Mimassi teaches: (Previously Presented) […] wherein the service order comprises information on selected food and/or drink items, previously selected by the vehicle operator. See [Mimassi, pg. 4, col 1, para 0038], which describes the capability to enter preferences, “a customer en-route to a destination, customers will connect to the customer portal 130 to pre-enter a variety of preferences and other information [...] to suggest restaurants, menu items, and routing options that meet the customer's preferences.” And see [Mimassi, pg. 4, col 2, para 0040], which describes the capability to submit an order both manually and atomically, considering these user preferences, “the option will be compatible with his or her preferences [...] In some embodiments, an application on the customer's mobile device 131 may dial the phone number of the chosen restaurant for the customer to place the order. In some embodiments, the optimization server 110 will contact the restaurant through the restaurant portal 140 to automatically enter an order.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Delorme with Mimassi to include ordering food, as opposed to a table reservation, but still based on user preferences. Doing so would allow users to stop and order food for pickup, along their destination, using an automated method which reduces the time and effort it takes to find and select food along their route and to the user’s preference [Mimassi, pg. 1, col 1, para 0003].
Regarding Claim 7, Delorme as modified teaches the limitations of Claim 1.
Delorme further discloses: (Previously Presented) […] wherein the service order comprises a ferry […] for a host vehicle ferry ride along at least a part of the route between the starting destination and the target destination. See [pg. 11, lines 6-8], which describes transportation routes to include a variety POIs, or waypoints, such as ferry stops, “may include all forms of transportation routes for example [...] ferry routes […]” and also [pg. 95, lines 25-27, claim 10], “the CARPS of Claim 1 wherein said POIs are selected from a group consisting of restaurants, hotels/motels, cities, municipalities, settlements, routes, transportation services such as airports, ferries, […].”
Delorme does not disclose: (Previously Presented) […] wherein the service order comprises a […] booking.
However, Deluca teaches: (Previously Presented) […] wherein the service order comprises a […] booking. See again [Deluca, pg. 6, col 2, para 0046], which describes reserving various types of services, including purchasing a ticket.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Delorme with Deluca to include the capability to purchase a ticket for the ferry stop. Similarly to Claim 1, which discusses initiating a service order along the travel route, doing so would allow the user to minimize the steps required to plan and execute a route and improve the efficiency of trip driving [Deluca, pg. 2, col 1, para 0017].
Claims 4 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Delorme, Deluca, Davies, and Mimassi, further in view of Luke et al., US-2013/0030580-A1 (herein “Luke”).
Regarding Claim 4, Delorme as modified teaches the limitations of Claim 3.
Delorme does not disclose: (Previously Presented) […] wherein the service order comprises a booking for electric charging of the host vehicle during a time duration which starts upon arrival at the service provider and ends upon departure from the service provider.
However, Luke teaches: (Previously Presented) […] wherein the service order comprises a booking for electric charging of the host vehicle. See [Luke, pg. 3, col 1, paras 0025/0026], which explains that the system tracks service orders for portable electric charging, “the method may further comprise: receiving, by the system for reserving portable electrical energy storage devices.” See also [Luke, pg. 10, paras 0102-0103], which describe the reservation that gets stored for charging the vehicle, "[0102] The user may then select a location indicated on the displayed map (e.g., via a touch screen or other interface enabling selection of the indicated locations) at which to reserve one or more available portable electrical energy storage devices. This reservation is stored in a database of reservations maintained centrally by the collection, charging and distribution machine management system 302 and/or locally at the selected collection, charging and distribution machine. […]. [0103] The reservation may be for a limited time or have other restrictions. After the limited time elapses and the user has not removed the reserved portable electrical energy storage device at the selected collection, charging and distribution machine, the portable electrical energy storage device then becomes available and this available status is updated in the collection, charging and distribution machine management system 302 and/or the selected collection, charging and distribution machine system."
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Delorme with Luke to include a booking for electric charging. Doing so would support the increasing field of electric vehicle transportation [Luke, pg. 1, col 2, para 0006], including by supporting easily recharging batteries with limited driving range as the technology develops [Luke, pg. 2, para 0010] through availability and accessibility to charging resources [Luke, pg. 2, paras 0014-0016].
However, Deluca teaches: (Previously Presented) […] electric charging of the host vehicle during a time duration which starts upon arrival at the service provider and ends upon departure from the service provider. See [Deluca, pg. 2, col 1, paras 18-19], as stated above for Claim 3, which describes a system considering vehicle information which includes information related to charge data and also [Deluca, pg. 5, col 1, para 0039], which describes a charging schedule to show length of charge stops along their route, “the charging schedule may recommend how long users should charge an electric vehicle at certain charging locations along a route.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Delorme with Deluca to include a time duration for charging. Doing so would allow the user to align route planning and stops to their preferences and improve interest at and time spent at trip stops [Deluca, pg. 2, col 1, para 0015] and to optimize the total trip process [Deluca, pg. 2, col 1, para 0017].
Regarding Claim 9, Delorme as modified teaches the limitations of Claim 8.
Delorme does not disclose: (Previously Presented) […] wherein the method further comprises: providing confirmation status of the at least one updated service order to the user interface.
However, Luke teaches: (Previously Presented) […] wherein the method further comprises: providing confirmation status of the at least one updated service order to the user interface. See [Luke, pgs. 10-11, col 2-1, para 0105], which describes updating a reservation display based on real-time data, “[a] change notification may be provided on a mobile device of the user or other device based on location of the user, time or planned trip. The […] system 302 notifies the user, based on the user's planned trip, the user's upcoming portable electrical energy storage device exchange destination based on time and current location. For example, a mobile device application utilizes an alarm and/or vibrator function of the mobile device to notify user of their planned upcoming exchange based on real time GPS location.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modify Delorme with Luke to include the capability to receive an updated reservation confirmation on a user interface. Doing so would allow the user to proceed on their route with confirmation of the remaining time until their reservation to ensure they make the reservation at the defined time [Luke, pg. 4, col 2, para 0040].
Claims 10 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Mimassi, in view of Davies and Yien et al., Patent No. US-11,295,322-B1 (hereinafter “Yien”).
Regarding Claim 10, Mimassi discloses: (Currently Amended) […] A vehicle operator service system. See [Mimassi, Fig. 1 and pg. 4, col 1, para 0037], "an automated en-route business establishment selection, ordering, and routing system" and [Mimassi, pg. 3, col 1, para 0028] "the use case of drivers."
Mimassi further discloses: a processing unit. See [Mimassi, Fig 2.] food prep optimization subsystem.
And a communication system. See [Mimassi, Fig 2.] food preparation scheduler.
And: a navigation system. See [Mimassi, Fig 2 and pg. 5, col 1, para 0043] an "optimization engine [… comprises…] a route optimization subsystem and restaurant selection subsystem."
And: a user interface. See [Mimassi, Fig 1.], "customer mobile devices."
Mimassi further discloses: the navigation system is arranged to determine a driving route. See [Mimassi, pg. 5, col 1, para 0044], which describes the route optimizing subsystem which generates routes, "a route optimizer 222, which obtains traffic data from the traffic data retriever 221 and map data from the map data retriever 223, and calculates an optimal route."
And: between a host vehicle starting destination, see [Mimassi, Fig. 2] which shows, the route optimization system, uses information from the restaurant selection subsystem, which contains a customer tracking engine that [Mimassi, pg. 5., col 1, para 0043] tracks the starting destination, as a customer location, "the customer tracking engine 211 keeps track of the customer's current location by querying the customer's mobile device."
And: and a host vehicle target destination, and arranged to determine the available service providers along the driving route. See [Mimassi, Fig. 2] which shows the restaurant selection subsystem also contains a restaurant selection subsystem and engine and see [Mimassi, pg. 5, col 1, para 0047], which explains the restaurant selection engine generates the restaurant selection options based on user preferences, entered via the user interface, and finally generates the target destination, as a restaurant location, "the restaurant selection engine 214 obtains restaurant location data 215 and […] then uses optimization algorithms to determine [and present] recommendations to the customer about restaurants and food items meeting the customer's preferences […] then sends the information about the selected restaurant to a route optimizer."
Mimassi further discloses: input related to specific host vehicle information or host vehicle operator information provided via the user interface. See again [Mimassi, pg. 4, col 1, para 0038], which describes the capability to enter preferences through the customer portal and [Mimassi, pg. 10, col 1, Claim 1], which describes the system capability to track the user’s location using the user’s mobile device and update the preparation time of the order, where the user can be a driver of a vehicle. In summary, see [Mimassi, Figs. 1-2 and pg. 4, col 1, para 0038] which shows the optimization engine, containing the above-mentioned portals, subsystems, and data, pulls the data from a database, "in the use case of a customer en-route to a destination, customers will connect to the customer portal 130 to pre-enter a variety of preferences and other information that will be stored in a database 150, and used by the optimization engine 200.”
Mimassi further discloses: the processing unit is arranged to, in response to input. See the input data as described above acquired through the user interface. See also [Mimassi, Fig. 2] which shows the food preparation optimization subsystem receiving the food order information and see [Mimassi, pg. 5, col 2, para 0047], which further explains the food preparation optimization subsystem, comprising the food preparation scheduler, can receive this data from the customer tracking and restaurant selection subsystem, also described above, "the restaurant selection engine 214 sends food order information 241 to a food preparation scheduler 242 (which may be running on the optimization server 110 […]).”
Mimassi further discloses: […] send a request for at least one service order, via the communication system . See again [Mimassi, pg. 5, col 2, para 0047], which explains the food preparation optimization subsystem can further output a request to schedule the order, via the food preparation scheduler, “a food preparation scheduler […], which calculates a food preparation start time determined by comparing the food's preparation time as retrieved from a database 150 with the customer's expected arrival time as determined by the route optimizer 222.” See again [Mimassi, Fig 2.], which shows the processing unit, "a food prep optimization subsystem," combined with a communication system, "a food preparation scheduler." Finally, see [Mimassi, Fig. 1], which shows the optimization engine (containing "the food prep optimization subsystem" and the "food preparation scheduler"), communicates with the "restaurant portal" and "restaurant computer," [Mimassi, pg. 5, col 2, para 0040], which manages the order at the restaurant, "the optimization server 110 will contact the restaurant through the restaurant portal 140 to automatically enter an order into the restaurant's computer 141."
Mimassi further discloses: the processing unit further arranged to detect a changed estimated or determined arrival time, wherein the vehicle operator service system is arranged to automatically update the service order, […], with a new estimated arrival time for a host vehicle (H) to the service provider in response to a changed estimated or determined arrival time. See [Mimassi, pg. 10, Claim 1], which describes the system receiving the order and tracking the customer’s location to adjust the preparation time to align with the arrival time, “receive a customer order at one of the selected business enterprise locations, and for that business location: receive periodic updates of the current location of the customer […]; estimate an updated time of arrival based […]; and adjust a start time for preparation of the customer order for the good or service based on the updated time of arrival.”
Mimassi does not explicitly disclose: […] the processing unit comprises one or more application programming interfaces (APIs) executing on the processing unit and specifying interactions with available service providers; […]; the processing unit is arranged to, […], via the one or more APIs [send a request for at least one service order], and via the one or more APIs receive an API response to the at least one service order, the API response including a confirmation status of the at least one service order; and the processing unit further arranged to detect a change…] and [… automatically update the service order], via the one or more APIs […].
However, Yien teaches: one or more application programming interfaces (APIs) [...] specifying interactions with available service providers. See [Yien, cols 6-7, lines 48-67 and 1-10], which describe a system for communicating between a service provider and a user using an API and specifies the ways in which the API can be used to define the interaction between the provider and the user, through messages, "FIG. 1 illustrates an example architecture 100 in which the techniques discussed herein may be implemented. The architecture 100 includes a service provider 102 that communicates with one or more users 104 [...] of applications such as a third-party management service, buyers at merchant locations, and so on, one or more merchants 106 [...], one or more third-party services 108 (hereinafter "an order and delivery service 108," [...], "a reservation service 108[...], [...], an "ecommerce service", [...]), [...]. The third-party services 108 may include services offered by the service provider 102, for example for delivery, reservation, recommendations, inventory, [...]. In some instances, the service provider 102 may provide one or more Application Programming Interfaces (APIs) 114 to enable the user 104 and/or the merchant 106 to access the services provided by the service provider 102. An API can be implemented as a Push API, Pull API or a combination of both. Accordingly, each of the applications can create or share API endpoints to receive or send updates or both. For example, the Push API enables sending of a push message to a web application a push service, sometimes asynchronously. An application server can send a push message at any time, even when a web application or user agent is inactive." See also [Yien, col 9, lines 18-64], which further describes the forms of interactions through the API including an online shopping cart and a display, or user interface, for providing messages, selection options, or status updates, "For example, the acquisition device may communicate with the merchants via the service provider 102 through the one or more APIs 114 while placing an order with the merchant 106. In particular, an individual [...] may place an item in an online shopping cart for purchase and indicate an interest in having the item delivered. In response, the acquisition device may send a request to the service provider 102 via the one or more APIs 114 for information regarding delivery, reservation, or content management. [...]. The acquisition device may display information of the delivery proposal via the item acquisition user interface 120(a) for acceptance or rejection. As illustrated in FIG. 1, an estimated amount of time to deliver the item and a delivery cost is presented at 122 in the acquisition user interface 120(a) of the acquisition device. The individual may accept the delivery proposal and cause the order to be placed by selecting a button 124 (e.g., a selectable control). Further, the acquisition device may communicate with the service provider 102 via the one or more APIs 114 to obtain status updates regarding a delivery of the item ordered by another third-party service or another user. [...]. The service provider 102 may determine a status of delivery of the item and send the status of delivery to the acquisition device. The status of delivery may be displayed via the item acquisition interface 120(b). The status may be determined and/or provided to the acquisition device upon request from the acquisition device (e.g., in response to a message sent through the one or more APIs 114), periodically, and/or upon the occurrence of another event. As illustrated in FIG. 1, the item acquisition interface 120(b) may include a button 126 (e.g., a selectable control) which, when selected, displays a map that shows a current location of the assigned third-party service device, a route traveled by the assigned third-party service device, a route yet to be taken by the assigned third-party service device to pick up or deliver the item, and so on."
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Delorme with Yien to use an API for specifying the interaction between the service provider and service requestor. Doing so allows for an automated method for a user's request to be received, distributed, and responded to by various service providers using an existing user interface [Yien, col 1, lines 7-37], by providing a common interface that can optimize various forms of interactions [Yien, col 2, lines 7-31].
However, Davies teaches: […] the processing unit comprises one or more application programming interfaces (APIs) executing on the processing unit […]; […]; the processing unit is arranged to, […], via the one or more APIs [send a request for at least one service order], and via the one or more APIs receive an API response to the at least one service order, the API response including a confirmation status of the at least one service order; and the processing unit further arranged to detect a change…] and [… automatically update the service order], via the one or more APIs […]. See again [Davies, pg. 3, paras 0040 and 0043], which describe the computer system for communicating service requests between a service requestor and a service provider, which includes computing devices on vehicles that can contain a processor. Also see again [Davies, pg. 4, para 0046], which explains that the computer system utilizes servers to exchange data between the service requestor and service provider, using communication over a wireless network using an interface or an API. Also see again [Davies, pg. 8, para 0081], which explains that the network service interacts with the system to provide a confirmation from the service provider to the service requestor. Finally see [Davies, pgs. 6-7, paras 0072-0075], which explains that the system has the capability to track and communicate changes, for example, an arrival time of the service provider to the service requestor for providing transportation services, using the on-demand network service.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Delorme with Davies to include sending requests or updates and receiving confirmation between a service provider and a requestor, using an API. Doing so allows the service provider to receive user-specified data and provides a way for the provider to interact with the system to accept or decline a request [Davies, pg. 1, para 0002], including accounting for service provider breaks or offline periods and coordinating if the request is within an available timeframe [Davies, pg. 2, para 0017]. Additionally, using an API provides a designated application that can be used from a user’s mobile device [Davies, pg. 1, para 0014]. In summary, the coordinated communication between a service provider and a service requestor allows for control, stability, and automation of the scheduling process to provide a better service interaction [Davies, pg. 2, paras 0018-0019].
Regarding Claim 12, Mimassi as modified teaches the limitations of Claim 10.
Mimassi further discloses: (Previously Presented) […] a host vehicle, wherein the vehicle comprises a vehicle operator service system according to claim 10. See [Mimassi, pgs. 9-10, cols 2-1, para 0074], which describe the system to be used on in-vehicle devices, “it should be appreciated that some or all components illustrated may be combined, […] into a single hardware device (for instance, in mobile devices such as smartphones, video game consoles, in-vehicle computer systems such as navigation or multimedia systems in automobiles, or other integrated hardware devices).”
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ERIN MARIE HARTMANN whose telephone number is (571)272-5309. The examiner can normally be reached M-F 7-5.
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, Kito Robinson can be reached at (571) 270-3921. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/E.M.H./Examiner, Art Unit 3664
/KITO R ROBINSON/Supervisory Patent Examiner, Art Unit 3664
Prosecution Insights