DETAILED ACTION
This is the Second First Office Action on the Merits and is directed towards claims 2-21 as amended and/or filed on 10/22/2025.
Upon consideration of the 02/17/2026 IDS the previous notice of allowable subject matter of claims 2-21 is hereby withdrawn as set forth more fully below.
EXAMINERS NOTE: IT APPEARS THAT ON 10/22/2025 APPLICANT INADVERTANTLY FILED A RESPONSE IN THIS APPLICATION THAT WAS DESTINED FOR APPLICATION 18/130,772. AS SUCH, WHILE THE EXAMINER CONSIDERED THE 10/22/2025 IDS AS ATTACHED HERETO, THE EXAMINER DID NOT CONSIDER THE 10/22/2025 CLAIMS OR ARGUMENTS AS THEY ARE DIRECTED TOWARDS A DIFFERENT APPLICATION, I.E. APPLICATION 18/130,772.
THE CLAIMS AND ARGUMENTS SUBMITTED ON 10/22/2025 WILL NOT BE ENTERED AS THEY ARE DIRECTED TOWARDS A DIFFERENT APPLICATION.
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 allowance or after an Office action under Ex Parte Quayle, 25 USPQ 74, 453 O.G. 213 (Comm'r Pat. 1935). 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, prosecution in this application has been reopened pursuant to 37 CFR 1.114. Applicant's submission filed on 02/17/2026 has been entered.
Notice of Pre-AIA or AIA Status
Priority is claimed as set forth below, accordingly the earliest POSSIBLE effective filing date is April 11, 2018 (20180411).
The present application, effectively filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
This application is a continuation application of U.S. Application Serial No. 16/381,839, filed April 11, 2019, which is based on and claims priority to United States Provisional Application 62/656,143 having a filing date of April 11, 2018 and United States Provisional Application 62/729,087 having a filing date of September 10, 2018 (“Parent Application(s)”). See MPEP §201.07[R-08.2017]. In accordance with MPEP §609.02 [R-07.2015] Section A. 2 and MPEP §2001.06(b)[R-08.2017] (last paragraph), the Examiner has reviewed and considered the prior art cited in the Parent Application. Also in accordance with MPEP §2001.06(b) [R-08.2017] (last paragraph), all documents cited or considered ‘of record’ in the Parent Application are now considered cited or ‘of record’ in this application. Additionally, Applicant(s) are reminded that a listing of the information cited or ‘of record’ in the Parent Application need not be resubmitted in this application unless Applicants desire the information to be printed on a patent issuing from this application. See MPEP §609.02 [R-07.2015] Section A. 2. Finally, Applicants are reminded that the prosecution history of the Parent Application is relevant in this application. See e.g., Microsoft Corp. v. Multi-Tech Sys., Inc., 357 F.3d 1340, 1350, 69 USPQ2d 1815, 1823 (Fed. Cir. 2004) (holding that statements made in prosecution of one patent are relevant to the scope of all sibling patents).
Information Disclosure Statement
As required by M.P.E.P. 609 [R-07.2015], Applicant's 02/17/2026 submission(s) of Information Disclosure Statement(s) is/are acknowledged by the Examiner and the reference(s) cited therein has/have been considered in the examination of the claim(s) now pending. A copy of the submitted PTOL-1449(s) initialed and dated by the Examiner is/are attached to the instant Office action.
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 2-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
The claim(s) recite(s) with regard to claim 2, An autonomous vehicle, comprising:
a vehicle computing system positioned onboard the autonomous vehicle, the vehicle computing system being programmed to perform operations comprising:
executing a first vehicle client associated with a first vehicle service entity;
executing a second vehicle client associated with a second vehicle service entity different than the first vehicle service entity;
receiving, from a first service entity computing system, a first vehicle service assignment, the first vehicle service assignment being received by the vehicle computing system via the first vehicle client, the first vehicle service assignment describing a first user of the first vehicle service entity and a description of a first transportation service to be performed by the autonomous vehicle for the first user of the first vehicle service entity;
controlling at least one control of the autonomous vehicle to execute a first vehicle service described by the first vehicle service assignment receiving, from a second service entity computing system, a second vehicle service assignment, the second vehicle service assignment being received by the vehicle computing system via the second vehicle client, the second vehicle service assignment describing a first user of the second vehicle service entity and a description of a second transportation service to be performed by the autonomous vehicle for the first user of the second vehicle service entity;
and controlling at least one control of the autonomous vehicle to execute a second vehicle service described by the second vehicle service assignment.
This judicial exception is not integrated into a practical application because the claim is directed to an abstract idea with additional generic computer elements, that do not add a meaningful limitation to the abstract idea because they amount to simply implementing the abstract idea on a computer in an autonomous vehicle. Further the claim is directed to a method of using a naturally occurring correlation, and the data gathering steps required to use the correlation do not add a meaningful limitation to the method as they are insignificant extra-solution activity and is nothing more than an attempt to generally link the product of nature to a particular technological environment. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional limitations only store and retrieve information in memory, which are well-understood, routine, conventional computer functions as recognized by the court decisions listed in MPEP § 2106.05(d).
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 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 2-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20210223051 A1 to HOCHBERG; Omry et al. (hereinafter Hochberg) in view of US 20190180236 A1 to Greenberger; Jeremy A. et al. (hereinafter Greenberger) and further in view of MPEP 2144.04.
Regarding claims 1, 14 and 21 HOCHBERG teaches in for example the Figure(s) reproduced immediately below:
PNG
media_image1.png
478
636
media_image1.png
Greyscale
PNG
media_image2.png
722
530
media_image2.png
Greyscale
PNG
media_image3.png
670
446
media_image3.png
Greyscale
PNG
media_image4.png
632
442
media_image4.png
Greyscale
PNG
media_image5.png
477
658
media_image5.png
Greyscale
PNG
media_image6.png
522
491
media_image6.png
Greyscale
PNG
media_image7.png
481
651
media_image7.png
Greyscale
PNG
media_image8.png
501
660
media_image8.png
Greyscale
PNG
media_image9.png
714
495
media_image9.png
Greyscale
and associated descriptive texts an autonomous vehicle, (a method of operation and non-transitory machine readable medium causing a vehicle system to perform operations) comprising (see for example para:
“[0099] Memory 320 may be a volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other type of storage device or tangible or non-transitory computer-readable medium that stores one or more program(s) 330 such as server apps 332 and operating system 334, and data 340. Common forms of non-transitory media include, for example, a flash drive, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM or any other flash memory, NVRAM, a cache, a register, any other memory chip or cartridge, and networked versions of the same.”):
a vehicle computing system positioned onboard the autonomous vehicle, the vehicle computing system being programmed to perform operations comprising (as explained in for example para:
“[0085] FIG. 2 is a diagram illustrating the components of an example mobile communications device 200 associated with a ridesharing management system, such as system 100 as shown in FIG. 1, in accordance with some embodiments of the present disclosure. Mobile communications device 200 may be used to implement computer programs, applications, methods, processes, or other software to perform embodiments described in the present disclosure, such as mobile communications devices 120A-120F. For example, user devices 120A-120C, driver devices 120D and 120E, and driving-control device 120F may respectively be installed with a user side ridesharing application, and a corresponding driver side ridesharing application.”):
executing a first vehicle client associated with a first vehicle service entity ( as explained in for example para:
“[0159] As shown in fo example timeline 740, for a particular rideshare vehicle, ridesharing management server 150 may receive a first request and a second request and assign both to the particular rideshare vehicle. In example timeline 710, the first user may have an additional rider, one or more pieces of luggage, and/or a physical condition that uses 3 seats of capacity rather than 1. Accordingly, because ridesharing management server 150 may implement a threshold block when the capacity of the particular rideshare vehicle reaches 3, the third user is re-assigned to another rideshare vehicle on account of the threshold block activated upon pick-up of the first user.“);
receiving, from a first service entity computing system, a first vehicle service assignment, the first vehicle service assignment being received by the vehicle computing system via the first vehicle client (see para:
“[0110] At step 411, ridesharing management server 150 may receive a first ride request from a first wireless communication of a first user, for example, a request from user 130A sent through user device 120A. The first ride request may include a first starting point and a first desired destination. A ride request may refer to a request from a user needing transportation service from a certain location to another. A starting point may refer to a current location of the user, as input by the user through an input device of an associated user device, or as determined by a location service application installed on the user device. In some embodiments, the starting point may be a location different from the current location of the user, for example, a location where the user will subsequently arrive at (e.g., entrance of a building). A desired destination may refer to a location where the user requests to be taken to.”),
the first vehicle service assignment describing a first user of the first vehicle service entity and a description of a first transportation service to be performed by the autonomous vehicle for the first user of the first vehicle service entity (see for example para:
“[0111] In some embodiments, the actual pick-up location and the actual drop-off location may be different from the starting point and the desired destination. For example, the pick-up location may be of a certain distance from the starting point, where the user may be directed to for pick-up. By encouraging the user to walk to a pick-up location nearby, consistent with some embodiments, the vehicle may more easily and quickly locate the user without excessive detour, or causing excessive delay for users who are in the vehicle. Similarly, by encouraging the user to walk from a drop-off location different from but within a certain distance from the desired destination, the vehicle may be able to accommodate subsequent pick-ups, or arrive at the subsequent pick-up locations more quickly. The vehicle ridesharing service management system may provide incentives or rewards for the user who are willing to walk a certain distance. For example, the ridesharing management system may offer certain discounts based on the number and distances of the walks involved in a particular ride. Alternatively, the ridesharing management system may offer ride credits corresponding to the number and distance of the walks undertaken by the user during his rides. The user may use the credits for subsequent ride payment, or redeem the credit for money, free rides, or other rewards. Further, advantages of such embodiments may include more efficient vehicle use and management, more user flexibility, and less air pollution associated with vehicle use.”);
And controlling at least one control of the autonomous vehicle to execute a first vehicle service described by the first vehicle service assignment (as shown in Fig. 1 and explained in for example para:
“[0074] FIG. 1 is a diagram illustrating an example ridesharing management system, in which various implementations as described herein may be practiced, according to some embodiments of the present disclosure. As shown in FIG. 1, ridesharing management system 100 includes one or more mobile communications devices 120A-120F (collectively referred to as mobile communications devices 120), a network 140, a ridesharing management server 150, and a database 170. The plurality of mobile communications devices 120A-120F may further include a plurality of user devices 120A-120C associated with users 130A-130C respectively, a plurality of driver devices 120D and 120E associated with drivers 130D and 130E, and a driving-control device 120F associated with an autonomous vehicle 130F. Consistent with some embodiments of the present disclosure, ridesharing management server 150 may communicate with driving-control device 120F to direct autonomous vehicle 130F to pick-up and drop-off users 130A-130C. In one example, autonomous vehicles capable of detecting objects on the road and navigate to designated locations may be utilized for providing ridesharing services.”).
Hochberg does not appear to expressly disclose executing a second vehicle client associated with a second vehicle service entity different than the first vehicle service entity;
receiving, from a second service entity computing system, a second vehicle service assignment, the second vehicle service assignment being received by the vehicle computing system via the second vehicle client, the second vehicle service assignment describing a first user of the second vehicle service entity and a description of a second transportation service to be performed by the autonomous vehicle for the first user of the second vehicle service entity;
and controlling at least one control of the autonomous vehicle to execute a second vehicle service described by the second vehicle service assignment.
In analogous art Greenberger teaches in for example, the figures below:
PNG
media_image10.png
539
679
media_image10.png
Greyscale
PNG
media_image11.png
636
476
media_image11.png
Greyscale
PNG
media_image12.png
601
488
media_image12.png
Greyscale
PNG
media_image13.png
488
590
media_image13.png
Greyscale
PNG
media_image14.png
673
482
media_image14.png
Greyscale
PNG
media_image15.png
595
580
media_image15.png
Greyscale
And associated descriptive texts executing a second vehicle client associated with a second vehicle service entity different than the first vehicle service entity (as shown in the figures above the vehicle can be used by the first client as a rideshare and the second client as a delivery vehicle as explained in para:
“[0006] Ride sourcing, also known as ridesharing, dynamic ridesharing, ad-hoc ridesharing, on-demand ridesharing, and dynamic carpooling, is a service that arranges human passenger rides or human transportation on a short notice or prescheduled basis by a human driver in a traditional vehicle. This type of carpooling generally makes use of three recent technological advances: GPS navigation devices to determine a driver's route and arrange the ride, smartphones for a traveler to request a ride from wherever they happen to be, and social networks to establish trust and accountability between drivers and passengers. These elements are coordinated through a ride sourcing network service, which can instantaneously handle passenger payments, routes, and matching available drivers and passengers using optimization algorithms.
[0007] Ride sourcing is promoted as a way to better utilize the empty seats in most traditional passenger vehicles, thus lowering fuel usage and transport costs. Ride sourcing can serve areas not covered by a public transit system and act as a transit feeder service. Ride sourcing is capable of serving one-time trips, not only recurrent commute trips or prescheduled trips.”);
receiving, from a second service entity computing system, a second vehicle service assignment, the second vehicle service assignment being received by the vehicle computing system via the second vehicle client, the second vehicle service assignment describing a first user of the second vehicle service entity and a description of a second transportation service to be performed by the autonomous vehicle for the first user of the second vehicle service entity (in Fig. 14 and para:
“[0171] FIG. 14 illustrates a method 750 for product retention and sale within ARV 402, according to one or more embodiments. Method 700 may be implemented by systems 100, 200, and/or 300, in conjunction with platform 400, to receive a product from a seller that is subsequently purchased and provided to a ride source person from a compartment 441 of ARV 402. In method 750, the compartment 441 may serve as a temporary compartment where a product or other item from a ride source seller is housed within the compartment 441 and purchased by a subsequent ride source buyer.”);
and controlling at least one control of the autonomous vehicle to execute a second vehicle service described by the second vehicle service assignment (in fig. 13 and para:
“[0170] Method 700 may continue with providing subsequent ride source tasks or product delivery tasks according to the reconciled schedule (block 732). For example, upon the retrieval of products from compartment 441, compartment scheduling system 445 may add compartment 441 to the queue of available compartments that are currently available for product delivery or available for compartment rental. In this way, the ARV 402 accomplishes the product fulfilment and ride source request and is then able to provide others ride source rides and/or product deliveries. Method 700 may end at block 732.”).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the package delivery disclosed in Greenberger with the autonomous vehicle taught in HOCHBERG with a reasonable expectation of success because it would have “increased customer satisfaction” as taught by Greenberger Para(s):
“[0003] The potential benefits of autonomous vehicles include reduced mobility and infrastructure costs, increased safety, increased mobility, and increased customer satisfaction. Specifically a significant reduction in traffic collisions; the resulting injuries; and related costs, including less need for insurance. Autonomous vehicles are predicted to increase traffic flow; provided enhanced mobility, relieve travelers from driving and navigation chores; lower fuel consumption; significantly reduce needs for parking space and facilitate business models for transportation as a service, especially via the sharing economy.”.
While it is considered that the prior art teaches the claimed limitations as explained above, if Applicant is of the opinion that the prior art does not appear to teach the “arrangement of parts” then resort may be had to the MPEP section 2144.04.VI.C. Rearrangement of Parts
In re Japikse, 181 F.2d 1019, 86 USPQ 70 (CCPA 1950) (Claims to a hydraulic power press which read on the prior art except with regard to the position of the starting switch were held unpatentable because shifting the position of the starting switch would not have modified the operation of the device.); In re Kuhle, 526 F.2d 553, 188 USPQ 7 (CCPA 1975) (the particular placement of a contact in a conductivity measuring device was held to be an obvious matter of design choice). [AltContent: rect]
As is here, the particular placement of the components and where the software is running, such as on a server or in the vehicle itself would have been an obvious matter of design choice motivated by one of ordinary skill in order to perform the method when not connected to a server.
Regarding claims 3 and 16 and the limitations further comprising: receiving a plurality of vehicle service assignments, the plurality of vehicle service assignments comprising the first vehicle service assignment; and determining to execute the first vehicle service assignment (see the obviousness to combine and the rejection of corresponding parts of claim 2 above incorporated herein by reference and especially HOCHBERG figs. 4A. and B. and para:
“[0130] At step 419, ridesharing management server 150 may receive a second ride request from a second user. In some embodiments, the second user request may be a street hailing request received directly by the vehicle while the first user is still inside, namely, before dropping off the first user. The vehicle may then undertake the second ride request, if the first user permits subsequent pick-ups. In some embodiments, the driver of the vehicle may input the second ride request information through a driver device, for example, driver device 120D associated with driver 130D. The input may inform ridesharing management server 150 that the vehicle has undertaken a second ride request, or may further include the pick-up location and destination information of the second user. Ridesharing management server 150 may then accordingly determine whether to assign additional pick-ups to the same vehicle, and may further send direction information guiding the vehicle to the second user's destination.”).
Regarding claims 4 and 15 and the limitation further comprising accessing data associated with the plurality of vehicle service assignments,
the determining to execute the first vehicle service assignment being based at least in part on the data associated with the plurality of vehicle service assignments (see the obviousness to combine and the rejection of corresponding parts of claim 3 above incorporated herein by reference and especially HOCHBERG fig. 8 and para:
“[0161] FIG. 8 depicts example method 800 for managing a fleet of ridesharing vehicles. Method 800 may, for example, be implemented by ridesharing management server 150 of FIG. 3.
[0162] At step 811, server 150 may assign, to ridesharing vehicles already transporting users, additional users for simultaneous transportation in the ridesharing vehicles. For example, as explained above with regards to assignment module 610, server 150 may make assignments based on the closeness of pick-up locations of the users and the additional users, the closeness of destinations of the users and the additional users, the closeness of pick-up locations of the users to destinations of the additional users (or vice versa), overlap between predicted routes from the pick-up locations of the users to the destinations of the additional users and predicted routes from the pick-up locations of the users to the destinations of the additional users, or the like.”).
Regarding claims 5 and 17 and the limitation the determining to execute the first vehicle service assignment comprising determining that the autonomous vehicle is to solely perform for the first vehicle service entity during a first time period, the executing of the first vehicle service being at least in part within the first time period (see the obviousness to combine and the rejection of corresponding parts of claim 3 above incorporated herein by reference and especially HOCHBERG fig. 5 and para:
“[0143] FIG. 5 is a diagram of three example timelines showing ridesharing arrangements, in accordance with some embodiments of the present disclosure. As shown in example timelines 510, 520, and 530, for a particular assigned vehicle undertaking a first ride request from a first user and a second ride request from a second user, the order of pick-ups and drop-offs for the second user may vary. For example, ridesharing management server 150 may receive a plurality of ride requests, design an optimal path and pick-up/drop-off order for a particular assigned vehicle undertaking multiple requests, and assign additional pick-ups as the vehicle completes a part of or all of the ride requests. For example, as shown in example timeline 510, a vehicle may receive a second ride request after picking up the first user, and drop-off the first user before dropping off the second user. A corresponding shared ride portion may be the portion of ride between the pick-up of the second user and drop-off of the first user. As shown in example timeline 520, the vehicle may receive a second ride request after picking up the first user, and drop-off the second user before dropping off the first user. A corresponding shared ride portion may be the portion of ride between the pick-up of the second user and drop-off the second user. As another example, as shown in example timeline 530, the vehicle may receive the first ride request and the second ride request before any pick-up. The vehicle may then pick-up the second user before picking up the first user, and drop-off the second user before dropping off the first user. A corresponding shared ride portion may be the portion of ride between pick-up of the first user and drop-off of the second user. Depending on the order of pick-ups and drop-offs, the ridesharing management server may then determine a corresponding shared ride portion, and calculate ride fare for each user based on, for example, the shared portion, solo portion of each user, and/or other factors such as the ride service parameters set by each user.”) .
Regarding claims 6 and 18 and the limitations further comprising sending to the second vehicle service entity an indication that the autonomous vehicle will be available to perform one or more vehicle services after the first time period (see the obviousness to combine and the rejection of corresponding parts of claims 5 and 2 above incorporated herein by reference wherein Greenberger teaches sending indications such as “confirmations” in for example paras:
“[0081] The request may be temporarily stored within a request pool, routed to compartment scheduling system 445a of platform 400a if compartment scheduling system 445a indicates that there is an open compartment, routed to scheduler 415a of platform 400a to determine whether the ARV 402a could arrive at the specified location at the requested time without unacceptably impacting the current reconciled schedule of ARV 402a, and the like. Compartment scheduling system 445a may determine that compartment 441a is available and scheduler 415a may determine that ARV 402a may satisfy the renters request and arrive at the specified location at the requested time so that the renter may access e.g., compartment 441a. Resultantly, scheduler 415a may confirm the request and may send a request confirmation to device 100a via text, native application, email, or the like. A code, such as a PIN randomly generated by e.g. system 300, 400a, or the like, may be sent to device 100a along with the confirmation. Upon arrival of ARV 402a at the specified location or reconciled updated location, the renter enters the code into device 100a via keypad 470a upon display 152a and confirms rental payment or rental agreement of compartment 441a by manipulating object 472a upon display 152a.
[0082] The entered code may be sent to server 300 encrypted and sent to platform 400a, routed to access system 442a, and unencrypted by the access system 442a. The access system 442a may confirm the code is correct and may unlock the door of compartment 441a or otherwise allow access to the securable inner portion of compartment 441a. Compartment 441a may include a light 474a or other identifier to bring attention to the renter of the assigned compartment. After the renter places the product into the rented compartment, the renter may again enter the code into the keypad 470a. The entered code may be sent to server 300 encrypted and sent to platform 400a, routed to access system 442, and unencrypted by the access system 442. The access system 442 may confirm the code is correct and may lock the door of compartment 441a or otherwise secure the securable inner portion of compartment 441a. A security system 443a of platform 400a may further confirm whether the product within compartment 441a poses an unacceptable security threat prior to further action by ARV 402a. Upon the rental of compartment 441a, compartment scheduling system 445a may remove compartment 441a from the queue of available compartments that are currently available for product delivery or available for compartment rental.“).
Regarding claims 7 and 19 and the limitations the operations further comprising sending data indicative of an acceptance of the first vehicle service assignment to the first service entity computing system via the first vehicle client (see HOCHBERG para:
“[0070] Consistent with some embodiments of the present disclosure, a ridesharing management system may receive a first ride request from a first user. The first ride request may include a starting point and a desired destination. The ridesharing management system may calculate a first estimated pick-up time based on a current location of a vehicle that is in the surrounding areas. After sending a confirmation with the estimated pick-up time, the ridesharing management system may then guide the vehicle to a pick-up location for picking up the first rider. The pick-up location may be a different location from the starting point included in the first ride request. The system may also guide the first user to the pick-up location.
[0071] In some embodiments, the system may subsequently receive a second ride request from a second user, for example, while the first user is still in the vehicle. The second ride request may include a second starting point and a second desired destination. The system may calculate a second estimated pick-up time, provide a second confirmation to the second rider, and guide the second rider to a second pick-up location. In some embodiments, the second pick-up location may be a different location from the second starting point included in the second ride request.“).
Regarding claims 8 and 19 and the limitations further comprising:
sending to the first service entity computing system a first indication that the autonomous vehicle is available to perform one or more vehicle services;
and sending to the second service entity computing system a second indication that the autonomous vehicle is available to perform one or more vehicle services (see the obviousness to combine and the rejection of corresponding parts of claim 2 above incorporated herein by reference wherein it is understood that each ride sharer and shipper would get confirmations. Further per the MPEP the duplication of parts would have been prima facie obvious.
B. Duplication of Parts
In re Harza, 274 F.2d 669, 124 USPQ 378 (CCPA 1960) (Claims at issue were directed to a water-tight masonry structure wherein a water seal of flexible material fills the joints which form between adjacent pours of concrete. The claimed water seal has a "web" which lies in the joint, and a plurality of "ribs" projecting outwardly from each side of the web into one of the adjacent concrete slabs. The prior art disclosed a flexible water stop for preventing passage of water between masses of concrete in the shape of a plus sign (+). Although the reference did not disclose a plurality of ribs, the court held that mere duplication of parts has no patentable significance unless a new and unexpected result is produced.).
Regarding claims 9 and 20 and the limitations the sending of the first indication that the autonomous vehicle is available to perform one or more vehicle services is via the first vehicle client (see the rejection of corresponding parts of claims 8 and 2 above incorporated herein by reference wherein it is understood that the rideshare is the first client).
Regarding claims 10 and 20 and the limitations further comprising, after the autonomous vehicle has completed the first vehicle service, sending to the second service entity computing system an indication that the autonomous vehicle is available to perform at least one vehicle service (see the teachings of Greenberger para:
“[0093] The accept fulfillment query may be sent to one or more intervening person while those intervening persons are within ARV 402c or prior to one or more intervening persons being picked up by ARV 402c. Scheduler 415c may rank the intervening persons based upon the least impact to the reconciled ARV 402c schedule and sequentially send the accept fulfillment query to the intervening persons in the order of the ranked list. For example, scheduler 415c may create a ranked list of the intervening persons based upon the likelihood of there being an available compartment at the time the intervening persons are within ARV 402c and sequentially send the accept fulfillment query to the intervening persons in the order of the ranked list.”
Regarding claim 11 and the limitation the autonomous vehicle of claim 2, the operations further comprising:
accessing data associated with a status of the autonomous vehicle;
using the data associated with the status of the autonomous vehicle to determine that the autonomous vehicle is to become available to perform one or more vehicle services at a first time;
and sending to the first service entity computing system an indication that the autonomous vehicle is to become available to perform one or more vehicle services at the first time, the first vehicle service assignment commencing after the first time (see the teachings of Hochberg paras:
“[0354] In some embodiments, the capacity status may be adjusted based on factors other than the number of passengers currently in the vehicle but that affect the available capacity of the vehicle. For example, if a passenger has a suitcase that is taking up the space in the vehicle, the capacity status availability may be reduced by 2 passengers instead of 1 passenger. As another example, if a passenger takes up more than one seat in the vehicle, the capacity status may be reduced accordingly. Additionally, the capacity status may be adjusted automatically based on, for example, metadata associated with a user's ride request, and/or manual inputs, such as the driver's observations when the passenger is picked up.
[0355] Capacity status determination module 1802 may also include software instructions for retrieving, receiving, and/or determining a capacity threshold for a given ridesharing vehicle. The capacity threshold may be any variable that captures the lack of further availability of a vehicle to accommodate transport of additional passengers and/or items. For example, the capacity threshold may be a percentage of the known passenger capacity of the given ridesharing vehicle. In one embodiment, the capacity threshold may be set at 75% of the known passenger capacity such that if 3 of the 4 available seats in a vehicle are full, the capacity threshold is met. In other embodiments, the capacity threshold may be determined based on a vehicle ride type selected and/or paid for by a given rider. For example, in one embodiment, a user may select a private ride such that the capacity threshold is set to one passenger.“).
Regarding claim 12 and the limitation the autonomous vehicle of claim 11, the determining that the autonomous vehicle is to become available to perform one or more vehicle services at the first time being based at least in part on a current task being performed by the autonomous vehicle (see the obviousness to combine and the rejection of corresponding parts of claims 11 and 2 above incorporated herein by reference wherein Greenberger teaches the claimed limitations in for example only para:
“[0059] In embodiments, scheduler 415 may further manage concurrent or potentially concurrent tasks. A concurrent task are tasks that are underway at the same time. For example, when a person is being given a ride by ARV 402 while the ARV 402 is also in process of delivering products, such ride task and delivery tasks are concurrent tasks. In a particular example, ARV 402 may be configured to primarily be a product delivery vehicle. However, the module 420 may receive a ride source request from a person. The scheduler 415 may determine that in fulfilling the ride source request, the preexisting product delivery requests would still be satisfactorily fulfilled, and therefore, instruct the module 420 to accept the ride source request. In this manner, ARV 402 may provide a ride to a person whom is to arrive at a destination along or near the delivery route while the delivering of products is underway.”).
Regarding claim 13 and the limitation the autonomous vehicle of claim 2, the operations further comprising sending data indicative of an acceptance of the second vehicle service assignment to the second service entity computing system via the second vehicle client, the sending of the data indicative of the acceptance of the second vehicle service assignment occurring before a completion of the first vehicle service (see the obviousness to combine and the rejection of corresponding parts of claim 2 above incorporated herein by reference wherein Greenberger teaches the claimed limitations in for example only para:
“[0134] Method 600 may continue with receiving a confirmation or acceptance of the accept fulfillment query from an intervening person, referred to as the accepting intervening person (block 614). For example, scheduler 415 receives the intervening person acceptance of the fulfillment query which indicates the accepting intervening person is willing to waypoint or alter the route of their ride to allow the ARV 402 to arrive at a fulfillment location to accept the purchased product. Resultantly, scheduler 415 or purchase module 450 may confirm to the buyer, via SMS, email, or by a native application with the buyers device 100, that the product will be accepted by the ARV 402 that which his or her future ride is scheduled. The fee of the accepting intervening person's ride may be reduced to promote the collective likelihood of the intervening persons to accept the fulfillment query and/or the fee associated with the buyer's ride may be increased.”)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL LAWSON GREENE JR whose telephone number is (571)272-6876. The examiner can normally be reached on MON-THUR 7-5:30PM (EST).
Examiner interviews are available via telephone 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, Hunter Lonsberry can be reached on (571) 272-7298. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DANIEL L GREENE/Primary Examiner, Art Unit 3665 20260516
Prosecution Insights