DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Amendment filed 10/20/2025 has been entered. Claims 1-20 are pending.
Applicant’s arguments with respect to the rejections of claims 1-20 in view of Selvam (US 2019/0011931 A1), Smaili (US 2021/0182454 A1), and Kobayashi (US 2022/0113737 A1) have been considered but they are not persuasive. Specifically, Applicant argues that Selvam fails to disclose or suggest “instantiating one or more AV bots ... configured based on one or more AV parameters including at least one of an open door status, a seat occupancy status, or an internal health state and performing, using the one or more AV bots, a test on the fleet management system.” However, Fig. 3 and par. [0040] of Selvam disclose ride data including a number of passengers, which corresponds with a seat occupancy status, in a ride is inputted in the simulation system in order to simulate/test the fleet management system. Applicant further argues that the disclosed parameters in Selvam relate to high-level fleet data rather than specific internal vehicle states. However, other than parameters relating to high-level fleet data, Selvam also discloses parameters relating to each autonomous vehicle of the fleet, e.g. par. [0040] discloses “In an embodiment, data describing fleet constraints 308 may describe various limitations placed on autonomous vehicles in an autonomous vehicle fleet ... In an embodiment, ride data 312 may describe aspects of all “rides” in the geography; for example, rides matched by a dynamic transportation matching system and/or autonomous matching system. This may include data about number of passengers, ETAs, revenue/expenses/profits per ride, times associated with rides (start, end, duration), miles traveled to/from/during a ride, etc.” – Ride data is understood by one of ordinary skill in the art to be pertained to a ride for a specific vehicle rather than high-level fleet data. Therefore, the rejections of claims 1-20 under 35 U.S.C. 103 are maintained.
Applicant' s arguments with respect to the rejection of claim 1 regarding the limitation “after performing the test on the fleet management system, deleting, by the bot orchestrator, the one or more AV bots based on a pre-determined schedule” have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6, 8-13, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Selvam et al. (US 2019/0011931 A1), in view of Smaili et al. (US 2021/0182454 A1), and further in view of Anderson et al. (US 2019/0050269 A1).
Regarding claim 1 and similarly cited claims 8 and 15, Selvam teaches:
An apparatus (Fig. 8, [0066] “computer system 800 may be used to implement any of the systems, devices, or methods described herein.”) comprising:
at least one memory ([0070] “system 800 may include storage subsystem 810 including various computer readable storage media 808, such as hard disk drives, solid state drives (including RAM-based and/or flash-based SSDs), or other storage devices.”); and
at least one processor coupled to the at least one memory ([0070] “system 800 may include storage subsystem 810 including various computer readable storage media 808, such as hard disk drives, solid state drives (including RAM-based and/or flash-based SSDs), or other storage devices. In various embodiments, computer readable storage media 808 can be configured to store software, including programs, code, or other instructions, that is executable by a processor to provide functionality described herein.”), the at least one processor configured to:
receive, at a fleet management system ([0018] “autonomous ride matching system 102”), a first dispatch request, the first dispatch request indicating a first pick-up location for a first ridehailing request ([0018] “A requestor 108 may use a ride matching requestor application 110 on a requestor computing device 104 to request a ride at a specified pick-up location. The request may be transmitted over a communication network 108 to the autonomous ride matching system 102.”);
send, from the fleet management system, via a vehicle communication system ([0019] “communication network 108”), a first dispatch command to an autonomous vehicle (AV), wherein the first dispatch command is configured to cause the AV to navigate to the first pick-up location and to provide entry to a passenger associated with the first dispatch request ([0019] “The autonomous ride matching system 102 may identify available autonomous vehicles that are within a predetermined distance and/or expected pickup time away from the requestor 112 . The ride matching system 102 may send the ride request to autonomous vehicle 106 which may then proceed upon a route to the pickup location provided by requestor 108.”);
receive, at a bot orchestrator ([0019] “autonomous fleet simulation system 114”; Fig. 2, [0034] “autonomous fleet simulator 216”; or Fig. 3 “autonomous fleet simulation system 302”), a first provisioning request ([0019] “the autonomous fleet simulation system may take a number of inputs collected from the autonomous fleet and/or from administrators...”; [0034] The autonomous fleet simulation model may describe and utilize data, such as data gathered by requestor computing device 204, client computing device 224, and autonomous computing device 226, as well as current and historical data stores associated with autonomous matching system 202.”), the first provisioning requesting specifying one or more AV parameters comprising at least a seat occupancy status ([0040] “autonomous fleet simulation system 302 can pull production level data from computing devices 304, for example autonomous computing devices 226, autonomous matching system 202, etc. ... In an embodiment, ride data 312 may describe aspects of all “rides” in the geography; for example, rides matched by a dynamic transportation matching system and/or autonomous matching system. This may include data about number of passengers ...” – Fig. 3 shows ride data 312 obtained from computing devices 304 is inputted into the autonomous fleet simulation system 302 and data about number of passengers indicate seat occupancy status) or an internal health state ([0039] “For example, a maintenance schedule may mandate that engine oil of an autonomous vehicle is changed every 3,000 miles traveled. The autonomous fleet simulator 216 may model a maintenance schedule that changes engine oil every 4,000 miles in order to determine effects on variables such as supply, revenue, miles traveled between maintenance incidents, etc.”);
instantiate, by the bot orchestrator, one or more AV bots (AV bots corresponds with simulated AVs in a fleet) based on the provisioning request, wherein the one or more AV bots are configured based on the one or more AV parameters ([0019] “The autonomous fleet simulation system may then use these inputs to create an autonomous model that simulates the autonomous fleet deployment. Using this model, various optimizations can be determined for the behavior of the autonomous vehicle fleet. The optimizations may be based on vehicle utilization (i.e., a percent of time a vehicle is used for a ride or a mileage of a vehicle that is from conducting a ride), time with passenger versus time empty, cost per mile, or other performance metrics.”; [0035] “An embodiment simulates “rides” to these and other types of facilities in order to determine an optimized schedule that, in an embodiment, minimizes a total number of miles traveled by an autonomous vehicle fleet. Based on the simulated rides, instructions for the actual autonomous vehicle fleet may be sent and implemented in actual practice.”);
performing, using the one or more AV bots, a test on the fleet management system ([0035] “An embodiment simulates “rides” to these and other types of facilities in order to determine an optimized schedule that, in an embodiment, minimizes a total number of miles traveled by an autonomous vehicle fleet. Based on the simulated rides, instructions for the actual autonomous vehicle fleet may be sent and implemented in actual practice.”), wherein performing the test comprises:
receive, at the fleet management system, a second dispatch request, the second dispatch request indicating a second pick-up location for a second ridehailing request ([0018] “A requestor 108 may use a ride matching requestor application 110 on a requestor computing device 104 to request a ride at a specified pick-up location. The request may be transmitted over a communication network 108 to the autonomous ride matching system 102. In some embodiments, autonomous ride matching system 102 may manage both autonomous and non-autonomous vehicles”); and
send, from the fleet management system, via the vehicle communication system, a second dispatch command to the one or more AV bots ([0034] “The autonomous fleet simulation model may describe and utilize ... current ... data stores associated with autonomous matching system 202.”; [0035] “An embodiment simulates “rides” to these and other types of facilities in order to determine an optimized schedule that, in an embodiment, minimizes a total number of miles traveled by an autonomous vehicle fleet. Based on the simulated rides, instructions for the actual autonomous vehicle fleet may be sent and implemented in actual practice.”),
after performing the test on the fleet management system, deleting, by the bot orchestrator, the one or more AV bots ([0053] “At step 510, an updated autonomous fleet simulation model is determined by the autonomous fleet simulator ... For example, a modification to a number of autonomous vehicles may be simulated in the model ...” – Modification to a number of simulated autonomous vehicles/AV bots may include deleting the simulated autonomous vehicles/AV bots).
Selvam does not specifically teach wherein the second dispatch command is configured to provide the second pick-up location to the one or more AV bots.
However, in the same field of endeavor, Smaili teaches:
send, from the fleet management system, via the vehicle communication system, a second dispatch command to the one or more AV bots ([0101] “The vendor integration platform 410 can include provide APIs that allow external systems to submit requests to, and receive responses from, the simulation system 420. The vendor integration platform 410 can validate requests before passing the requests to the simulation system 420 to ensure that all requests meet the requirements of the simulation system 420.”), wherein the second dispatch command is configured to provide the second pick-up location to the one or more AV bots ([0091] “The parameters for a vehicle service simulation may include parameters that define a vehicle service-flow. For example, data defining a vehicle service-flow may define a dispatch of a vehicle service to an instance of a simulated autonomous vehicle. Data defining the vehicle service-flow may also include data instructing the instance of the simulated autonomous vehicle to accept or reject the service request. The data may additionally include data indicative of service-flow updates and/or location updates. The data may indicate a route from a pick-up location to a drop-off location in example embodiments.”; [0104] “For example, if a rider is needed to simulate a particular scenario, the actor simulator 442 can programmatically generate events as needed based on predefined scenario data. For example, if the predefined scenario data includes a rider submitting a ride request, the actor simulator 442 can automatically generate that event or cause the event to be generated at a time dictated by the predefined scenario.”).
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 teachings of Selvam to provide a second dispatch command including a second pick-up location to the one or more AV bots, as taught by Smaili, in order to perform testing or simulating operation of the AV bots using the second pick-up location, thus determining how an autonomous vehicle operates in real time.
Neither Selvam nor Smaili specifically teaches deleting, by the bot orchestrator, the one or more AV bots based on a pre-determined schedule.
However, in the same field of endeavor, Anderson teaches:
deleting the one or more AV bots based on a pre-determined schedule ([0060] “the virtual machine 270 deletes the virtual bot 110 and/or the hypervisor 350 deletes the virtual machine 270 hosting the virtual bot 110 in response to certain condition(s) (e.g., completion of the tasks defined by the instruction set 205, expiration of a time, etc.).”; [0110] “Example 4 includes the apparatus of Example 2, wherein the copy of the bot is to delete the copy of the bot from the hypervisor after an amount of time.”).
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 teachings of Selvam, in view of Smaili, to delete the one or more AV bots based on a predetermined schedule, as taught by Anderson, in order to remove AV bots that are not being used, thus reducing operating cost of the system.
Regarding claim 2 and similarly cited claims 9 and 16, Selvam does not specifically teach receive, at the bot orchestrator, a deletion request specifying deletion of a subset of the one or more AV bots.
However, Smaili teaches receive, at the bot orchestrator, a deletion request specifying deletion of a subset of the one or more AV bots ([0082] “The command line interface can be configured to manage test accounts (e.g., third party/vendor accounts, vehicle accounts, simulated user accounts, driver accounts, etc.). For example, the command line interface can be configured to create, delete, inspect, etc. data fields for test simulations/accounts to be utilized for simulation testing ... The OTT system 212 can also include a graphical user interface (e.g., OTT GUI 218) that allows a user to create simulated service assignments, visualize simulated service assignments, vehicles).
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 teachings of Selvam, in view of Smaili and Anderson, to receive a deletion request specifying deletion of a subset of the one or more AV bots, as taught by Smaili, in order to allow a user to select a specific number of AV bots for testing/simulating.
Regarding claim 3 and similarly cited claims 10 and 17, Selvam further teaches wherein the one or more AV parameters comprise route or location of the one or more AV bots ([0040] “certain autonomous vehicles may only be authorized or configured to operate within a sub-area of the overall geographic area serviced by the autonomous vehicle fleet (e.g., within a certain neighborhood of San Francisco, only on certain streets, etc.)”).
Regarding claim 4 and similarly cited claims 11 and 18, Selvam does not specifically teach wherein the at least one processor is further configured to: receive, at a remote assistance system, a request for assistance for the one or more AV bots.
However, Smaili teaches wherein the at least one processor is further configured to: receive, at a remote assistance system ([0108]-[0109] “remote operator simulation system 422”), a request for assistance for the one or more AV bots ([0109] “ In these scenarios, the remote operator simulation system can, based on information received from the simulation testing service 440 (such as a request for remote assistance from a simulated autonomous vehicle or a prompt to provide an event from the scenario simulator 446), generate one or more events as part of a simulation. “).
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 teachings of Selvam, in view of Smaili and Anderson, to receive a request for assistance for the one or more AV bots, as taught by Smaili, in order to allow a remote operator to perform testing/simulation of the AV bots.
Regarding claim 5 and similarly cit3ed claims 12 and 19, Selvam does not specifically teach wherein the request for assistance is sent from the fleet management system via the vehicle communication system.
However, Smaili teaches:
wherein the request for assistance is sent from the fleet management system via the vehicle communication system ([0101] “ The vendor integration platform 410 can be a self-driving platform gateway that receives communication from all autonomous vehicles that provide services for the service entity. The vendor integration platform 410 can include provide APIs that allow external systems to submit requests to, and receive responses from, the simulation system 420.”; [0109] “In these scenarios, the remote operator simulation system can, based on information received from the simulation testing service 440 (such as a request for remote assistance from a simulated autonomous vehicle or a prompt to provide an event from the scenario simulator 446), generate one or more events as part of a simulation. In some examples, the specific events generated by one or more simulated remote operators can be determined by a user running the simulation (e.g., ... an external (or third-party) user communicating from the external testing system 402 via the vendor integration platform 410.”; Fig. 4 also shows requests received at the vendor integration platform 410 is transmitted to the simulation testing service 440 which is then transmitted to the remote operator simulation system 422).
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 teachings of Selvam, in view of Smaili and Anderson, to send the request for assistance from the fleet management system via the vehicle communication system, as taught by Smaili, in order to provide remote assistance to the autonomous vehicles.
Regarding claim 6 and similarly cited claims 13 and 20, Selvam does not specifically teach wherein the request for assistance is received by a remote operator at a remote location.
However, Smaili teaches wherein the request for assistance is received by a remote operator at a remote location ([0109] “ the specific events generated by one or more simulated remote operators can be determined by a user running the simulation (e.g., either an internal user communicating through the internal testing system 450 or an external (or third-party) user communicating from the external testing system 402 via the vendor integration platform 410.”).
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 teachings of Selvam, in view of Smaili and Anderson, to receive a request for assistance by a remote operator at a remote location, as taught by Smaili, in order to allow the remote operator to perform assistance by testing/simulating the autonomous vehicle in specific scenarios.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Selvam et al. (US 2019/0011931 A1), in view of Smaili et al. (US 2021/0182454 A1) and Anderson et al. (US 2019/0050269 A1), and further in view of Kobayashi et al. (US 2022/0113737 A1).
Regarding claim 7 and similarly cited claim 14, Selvam, Smaili, and Anderson do not specifically teach wherein the at least one processor is further configured to: receive, at a remote assistance system, a second request for assistance for the AV.
However, in the same field of endeavor, Kobayashi teaches:
wherein the at least one processor is further configured to: receive, at a remote assistance system, a request for assistance for the AV ([0053] “When the remote assistance request determination portion 34 determines that remote assistance should be requested, the remote assistance request determination portion 34 transmits a remote assistance request to the vehicle remote assistance server 10. The remote assistance request determination portion 34 transmits identification information on the autonomous vehicle 2, the vehicle positional information, and the external environment information to the vehicle remote assistance server 10 together with the remote assistance request.”).
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 teachings of Selvam, in view of Smaili and Anderson, to receive a request for assistance for the AV at a remote assistance system, as taught by Kobayashi, in order to allow a remote operator to provide a remote operation of the autonomous vehicle.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NHI Q BUI whose telephone number is (571)272-3962. The examiner can normally be reached Monday - Friday: 8:00am-5:00pm EST.
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, KHOI TRAN can be reached at (571) 272-6919. 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.
/NHI Q BUI/Examiner, Art Unit 3656 /KHOI H TRAN/Supervisory Patent Examiner, Art Unit 3656