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 .
Status of Claims
This action is in reply to the amendments filed on 10/29/2025.
Claims 1-12 are currently pending and have been examined.
Claims 1, 5, 7, 8, and 10 are currently amended.
Claim 12 are newly added.
Claims 1-12 are currently rejected.
This action is made FINAL.
Response to Arguments
Applicant’s arguments filed 10/29/2025 have been fully considered but they are not persuasive.
Applicant’s arguments appear to be directed solely to the amended limitations of the claims which are addressed in the updated rejections below.
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.
Claim(s) 1, 3-8, and 10-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Glaser (US 2018/0308064), herein Glaser in view of Rakah et. al. (US 2018/0211541), herein Rakah, Namba et. al. (US 2019/0303806), herein Namba, and Busch et. al. (US 2018/0197153), herein Busch.
Regarding claim 1:
Glaser teaches:
A vehicle management system (A multi-mode transportation management method is presented here. [0006]; A computer-based system is also presented here. [0007]) for managing a vehicle with an autonomous driving function (With reference to FIG. 1, a control system shown generally at 100 is associated with a vehicle 10 in accordance with various embodiments. In general, the control system 100 is suitably configured to operate the vehicle 10 in an autonomous manner as needed. [0019]), comprising a server (The autonomous vehicle system 52 includes one or more backend server systems, which may be cloud-based, network-based, or resident at the particular campus or geographical location serviced by the vehicle system 52. [0033]) and a terminal to be used by a user (Although only one user device 54 is shown in FIG. 2, embodiments of the transportation system 50 can support any number of user devices 54, including multiple user devices 54 owned, operated, or otherwise used by one person. Each user device 54 supported by the system 50 may be implemented using any suitable hardware platform. In this regard, the user device 54 can be realized in any common form factor including, but not limited to: a desktop computer; a mobile computer (e.g., a tablet computer, a laptop computer, or a netbook computer); a smartphone; [0032]), wherein the terminal includes a terminal communication unit which transmits user position information indicating a present position of the user to the server (the user device 54 includes a GPS module capable of receiving GPS satellite signals and generating GPS coordinates based on those signals [0032]; The navigation and map system 68 can be used to determine passenger transportation routes to be followed by the vehicles, and it can also be used to locate and monitor the current location of passengers in an ongoing manner. [0035]), and
the server includes:
an autonomous driving control unit (The autonomous vehicle system 52 includes one or more backend server systems, which may be cloud-based, network-based, or resident at the particular campus or geographical location serviced by the vehicle system 52 [0033]) for controlling traveling of the vehicle (the vehicle system 52 may cooperate with the navigation and map system 68 and/or any number of the other transportation systems to manage the dispatching of vehicles and to otherwise support certain features and functions of the multi-mode transportation system. [0034]; The vehicle system 52 receives the transportation request, processes the request in an appropriate manner, and dispatches or otherwise controls one or more vehicles (e.g., an AV 10) such that the vehicle conveniently meets the passenger at a scheduled pickup point at the appropriate time. [0034]);
a server communication unit (the system 50 further includes one or more user devices 54 that communicate with the autonomous vehicles 10 and/or the vehicle system 52 via a communication network 56. [0028]; The autonomous vehicle system 52 includes one or more backend server systems, which may be cloud-based, network-based, or resident at the particular campus or geographical location serviced by the vehicle system 52. The vehicle system 52 can be manned by at least one live advisor, at least one automated advisor, or a combination of both. The vehicle system 52 can communicate with the user devices 54 and the autonomous vehicles 10a-10n to schedule rides, dispatch autonomous vehicles 10a-10n, provide transportation status notifications, provide travel instructions, and the like. In various embodiments, the vehicle system 52 stores account information such as subscriber authentication information, vehicle identifiers, profile records, behavioral patterns, and other pertinent subscriber information. [0033]) for receiving vehicle position information (The navigation and map system 68 can be an independent and distinct subsystem, or it can be integrated with the vehicle system 52 and/or any of the other systems described herein. The navigation and map system 68 may be implemented with one or more backend server systems, which may be cloud-based, network-based, or resident at the particular geographical location serviced by the vehicle system 52. In some embodiments, the navigation and map system 68 includes or cooperates with compatible features, functions, or applications resident at the AVs 10 and/or resident at the user devices 54. For example, a user device 54 may include a locally installed navigation or mapping app that receives and processes data provided by the navigation and map system 68. In this regard, the user device 54 may leverage cached map data, or it may rely on map data provided via the communication network 56. The navigation and map system 68 can be used to determine passenger transportation routes to be followed by the vehicles, and it can also be used to locate and monitor the current location of passengers in an ongoing manner. [0035]) indicating a present position of the vehicle from the vehicle (The positioning system 106 processes sensor data along with other data to determine a position (e.g., a local position relative to a map, an exact position relative to lane of a road, vehicle heading, velocity, etc.) of the vehicle 10 relative to the environment. The guidance system 108 processes sensor data along with other data to determine a path for the vehicle 10 to follow. The vehicle control system 110 generates control signals for controlling the vehicle 10 according to the determined path. [0042]) and the user position information from the terminal communication unit (the user device 54 includes a GPS module capable of receiving GPS satellite signals and generating GPS coordinates based on those signals. In other embodiments, the user device 54 includes cellular communications functionality such that the device carries out voice and/or data communications over the communication network 56 using one or more cellular communications protocols, as are discussed herein [0032]); and
a vehicle management unit (a multi-mode transportation system 50 [0028]) for setting a boarding point at which the user rides the vehicle (The system 50 can include any number of predefined vehicle pickup/drop-off locations that are known to the vehicle system 52. Alternatively or additionally, the vehicle system 52 can leverage GPS technology (and/or other position or location determination techniques or methodologies) to pick up passengers at any location and/or to leave passengers at any desired destination location. [0034]), calculating a user estimated arrival time at which the user arrives at the boarding point based on the present position of the user (the travel timing information may include, without limitation: a particular departure time; a destination arrival time; an intermediate or intersegment destination arrival time (e.g., a transfer or layover time between two travel segments) [0034]; the process 400 estimates or otherwise calculates the passenger arrival time at a departure location of an approaching vehicle segment. The estimated arrival time can be calculated based on any of the following, without limitation: the monitored current location and/or movement of the passenger or user device; the status or schedule information for the current mode of transportation; the status or schedule information for one or more intervening approaching modes of transportation (for travel segments between the current leg and the approaching vehicle leg); traffic data; weather data; police or emergency services notifications; etc. Again, the goal is to determine a good rendezvous time for the dispatched vehicle that will result in little to no wait time for the passenger at the upcoming departure location. [0062]), and for managing traveling of the vehicle (The vehicle system 52 receives the transportation request, processes the request in an appropriate manner, and dispatches or otherwise controls one or more vehicles (e.g., an AV 10) such that the vehicle conveniently meets the passenger at a scheduled pickup point at the appropriate time. As explained in more detail below, the vehicle system 52 may cooperate with the navigation and map system 68 and/or any number of the other transportation systems to manage the dispatching of vehicles and to otherwise support certain features and functions of the multi-mode transportation system. [0034]), wherein the vehicle management unit:
calculates a vehicle estimated arrival time at which the vehicle arrives at the first boarding point [and the second boarding point] based on the vehicle position information (The transportation request will typically identify a pickup or starting location for the passenger (or a current GPS location), the desired destination location for the passenger (which may be a predefined vehicle stop and/or a user-specified destination), and certain travel timing information. In this context, the travel timing information may include, without limitation: a particular departure time; a destination arrival time; an intermediate or intersegment destination arrival time (e.g., a transfer or layover time between two travel segments); a request for an immediate passenger pickup; or any combination thereof. [0034]; the vehicle system 52 obtains (or estimates) departure locations, arrival locations, departure times, and arrival times for the various transportation systems [0038]; the system can estimate the driving time of the dispatched vehicle using existing techniques and technologies. [0062]) and calculates a difference between the user estimated arrival time at which the second user arrives at the second boarding point while the first user is riding in the vehicle (examiner notes that a passenger being preset or not inside the vehicle would not affect the vehicles ability to calculate a time between estimated arrival time of the vehicle and a passenger waiting to be picked up.) and the vehicle estimated arrival time at which the vehicle arrives at the second boarding point (examiner notes that in order to synchronize the arrival of the vehicle with the passenger Glaser inherently must be able to determine a difference between the arrival time of the user and of the vehicle.); and
compares the difference with [a predetermined time threshold] (Once the desired passenger arrival time is determined, the system can dispatch and/or control the operation of a vehicle as needed to reach the designated departure location at the rendezvous time. In practice, the system can estimate the driving time of the dispatched vehicle using existing techniques and technologies. In this regard, the driving time can be estimated based on the required mileage, traffic data, accident data, weather data, the time of day, and the like. [0062]; accurate monitoring of the passenger's travel progress can be used to synchronize the arrival of a vehicle (autonomous or traditional) with the arrival of the passenger at a departure location of an approaching vehicle segment or leg of the travel plan. [0062]; examiner notes that the synchronizing the arrival the system inherently is comparing the users estimated arrival time with that of the vehicle.), while the vehicle is traveling (control the operation of a vehicle as needed to reach the designated departure location at the rendezvous time [0062]; examiner notes that the Glaser teaches adjusting the dispatch time or control of the vehicle after being dispatched to synchronize the arrival time which would occur while the vehicle is travelling if it has already been dispatched.)
wherein the autonomous driving control unit is configured to adjust a travel route (control the operation of a vehicle [0062]) of the vehicle with the autonomous driving function controls travelling (dispatches or otherwise controls one or more vehicles (e.g., an AV 10) such that the vehicle conveniently meets the passenger at a scheduled pickup point at the appropriate time [0034]) so that the estimated arrival time of the vehicle is later than the estimated arrival time of the second user (Again, the goal is to determine a good rendezvous time for the dispatched vehicle that will result in little to no wait time for the passenger at the upcoming departure location. Once the desired passenger arrival time is determined, the system can dispatch and/or control the operation of a vehicle as needed to reach the designated departure location at the rendezvous time. [0062])
Glaser does not explicitly teach, however Rakah teaches:
prepares a vehicle allocation schedule (a system for managing a fleet of ridesharing vehicles may comprise a communications interface configured to receive requests for shared rides from a plurality of users and at least one processor. The at least one processor may be configured to identify a first ridesharing vehicle and a second ridesharing vehicle that are currently without passengers and receive, via the communications interface, a first request for a shared ride from a first user. The first request may include information related to a first pick-up location of the first user and a first desired destination of the first user. The at least one processor may be further configured to receive, via the communications interface, a second request for a shared ride from a second user. The second request may include information related to a second pick-up location of the second user and a second desired destination of the second user. The at least one processor may be further configured to assign the first user and the second user to the first ridesharing vehicle; generate a route to the first ridesharing vehicle for picking up and dropping off each of the first user and the second user [0010]), where the vehicle allocation schedule at least indicates that a first user boards the vehicle at a first boarding point (the message includes a confirmation that the ridesharing request is accepted. If ridesharing management server 150 assigns a pick-up location different from the starting point, the message may further cause the display of an indication of the assigned pick-up location. Ridesharing management server 150 may further provide a navigation option which may be displayed on a user interface. A selection of the navigation option may then provide walking directions the user to the assigned pick-up location for pick-up. The message may further cause a display of an indication of an estimated walking distance from the starting point to the assigned pick-up location. In addition, the message may include an estimated walking distance from the assigned drop-off location to the desired destination. The assigned drop-off location may be a location close to the desired destination, within the maximum walking distance parameters set by the first user. For example, the drop-off location may be at a location half a block away or further from the desired destination, and may be along a main street where the vehicle may easily locate and access. For another example, the drop-off location may be determined based on a route towards the next pick-up location, such that the vehicle may easily drop-off the first user on its way to the next pick-up location, thereby avoiding an extra detour. [0132]) and that a second user boards the vehicle at a second boarding point (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. [0136]),
calculates a vehicle estimated arrival time at which the vehicle arrives at the first boarding point (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. [0075]) and the second boarding point (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. [0076])
It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to have modified Glaser to include the teachings as taught by Rakah with a reasonable expectation of success. Rakah teaches “Recent years have witnessed increasing interest and development in the field of vehicle sharing, where one or more riders may share the same vehicle for a portion of their rides. Ridesharing may save ride costs, increase vehicle utilization, and reduce air pollution. [Rakah, 0003]”. Both inventions are also in the same field of endeavor of control of vehicles for ridesharing/taxi purposes.
Glaser in view of Rakah does not explicitly teach, however Namba teaches:
and calculates a difference (the cancellation decision unit 207 compares the time lag (T2-T1), obtained by subtracting the first time T1 from the second time T2 [0098]) between the user estimated arrival time at which the second user arrives at the second boarding point (The second time T2 is a time when the scheduled passenger 6 is going to arrive at the boarding location P11 [0091]) while the first user is riding in the vehicle (the search unit 203 searches for a recommended candidate from among the plurality of cars 3 by taking, into account, how the on-board passenger's terms of use will be affected when each of the plurality of cars 3 is used by the potential user. This allows the search unit 203 to search for a recommended candidate from among the plurality of cars 3, depending on the degree of change of the terms of use of the on-board passenger [0071]) and the vehicle estimated arrival time at which the vehicle arrives at the second boarding point (The first time T1 is a time when the car 3A that the scheduled passenger 6 is scheduled to board is expected to arrive at the boarding location P11 [0091]); and
compares the difference with a predetermined time threshold while the vehicle is traveling (In Step S24, the cancellation decision unit 207 compares the time lag (T2-T1), obtained by subtracting the first time T1 from the second time T2, to a second threshold value Th2. The time lag (T2-T1), obtained by subtracting the first time T1 from the second time T2, has a positive value in a situation where the car 3A arrives at the boarding location P11 earlier than the scheduled passenger 6. In that case, the time lag (T2-T1), obtained by subtracting the first time T1 from the second time T2 corresponds to the car's 3A waiting time [0098]) and determines whether a delay of an arrival of the second user is greater than or equal to a predetermined value (fig. 5, S24 - YES).
cancels a ride of the second user (when finding the time lag (T2-T1), obtained by subtracting the first time T1 from the second time T2, greater than the second threshold value Th2 (i.e., when finding the car's 3A waiting time greater than the second threshold value Th2) (if the answer is YES in Step S24), the cancellation decision unit 207 proceeds to Step S25 to perform the processing of canceling the boarding reservation [0100]) when the delay of the arrival of the second user is greater than or equal to the predetermined value (fig. 5, S24 - YES), and prepares a changed vehicle allocation schedule after removing the second user as the user of the vehicle (This message allows the scheduled passenger 6 to learn that his or her boarding reservation for the car 3A has been canceled. Meanwhile, when the communications unit 31 of the car 3A receives the driving instruction information from the management server 2, the processing unit 30 controls the driving control unit 34 to drive the car 3A following the updated scheduled route. [0104]),
when the delay of arrival of the second user is less than the predetermined value (fig. 5, S24 - NO)
It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to have modified Glaser and Rakah to include the teachings as taught by Namba with a reasonable expectation of success. Namba teaches the benefit of “if the arrival of either the scheduled passenger 6 or the car 3A at the boarding location P11 is delayed, then the management server 2 automatically cancels the boarding reservation made by the scheduled passenger 6. This saves the scheduled passenger 6 the trouble to cancel the boarding reservation by him- or herself and provides a boarding management system 1 with improved user friendliness. In addition, if it is predicted that the arrival of either the scheduled passenger 6 or the car 3A would be delayed, the management server 2 cancels, in advance, the boarding reservation made by the scheduled passenger 6. This avoids a situation where the scheduled passenger 6 or the on-board passenger already aboard the car 3A has to wait at the boarding location P11 for an amount of time longer than the threshold value. This provides a boarding management system 1 with further improved user-friendliness and convenience [Namba, 0105]”.
Glaser, Rakah, and Namba do not explicitly teach, however Busch teaches:
the estimated arrival time of the vehicle is later than the estimated arrival time of the second user (Based upon an estimated delay for attendee 1, for instance of an hour or more, [0059]) and so that the travel route passes through scenic waypoints for the first user (Based upon an estimated delay for attendee 1, for instance of an hour or more, the system may present attendee 2 with the option to avoid the current route down the thruway between Albany and New York City, which includes tolls 800, and take a more scenic route, such as the Taconic Parkway, from Albany to New York City, to arrive at the meeting location at about the same time as the delayed attendee 1 is now projected to arrive at the meeting location [0059])
It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to have modified Glaser, Rakah, and Namba to include the teachings as taught by Busch with a reasonable expectation of success. Busch teaches the benefit of “the calendaring and travel facility disclosed herein allows multiple attendees to be notified should one of the attendees experience a travel delay, with the information being automatically shared in order to save time and potentially costs for attendees traveling to a meeting, for example, where the meeting is likely to be delayed. The system assumes that the calendaring programs used by the attendees to the meeting, particularly the traveling attendees, are able to share their starting or originating location, and if needed, a likely route each attendee would take. This information may then be shared with the navigation or travel facility. Traveling attendees to the meeting may use their navigation system to initially select the best route for the user subject to the constraint of arriving at the meeting location at the meeting time [Busch, 0060]”.
Regarding claim 3:
Glaser in view of Rakah, Namba, and Busch teaches all the limitations of claim 1, upon which this claim is dependent.
Glaser further teaches:
calculates the travel route from the present position of the vehicle to the boarding point (The positioning system 106 processes sensor data along with other data to determine a position (e.g., a local position relative to a map, an exact position relative to lane of a road, vehicle heading, velocity, etc.) of the vehicle 10 relative to the environment. The guidance system 108 processes sensor data along with other data to determine a path for the vehicle 10 to follow. The vehicle control system 110 generates control signals for controlling the vehicle 10 according to the determined path. [0042]);
and changes the travel route (the vehicle system 52 cooperates with the other transportation systems to manage multi-mode transit routes for passengers. Accordingly, the vehicle system 52 obtains (or estimates) departure locations, arrival locations, departure times, and arrival times for the various transportation systems, and intelligently dispatches vehicles at appropriate times that coordinate with the schedules and real-time status of the other transportation systems. Moreover, the vehicle system 52 is suitably configured to generate or retrieve one or more multi-mode travel plans in response to a passenger request, wherein the travel plans are determined based on the information obtained from the various transportation systems [0038]; The vehicle system 52 described here can be suitably configured to arrange and manage multi-mode transportation routes for passengers. In accordance with certain embodiments, the system 52 coordinates the dispatch of autonomous and/or traditional vehicles based on the arrival/departure schedules and operating status of other available modes of transportation. [0054]; The monitoring performed by the process 400 can be utilized to update the current travel plan if needed to compensate for transportation delays, traffic, emergencies, road closures, or the like (task 418). The current travel plan can also be updated or otherwise altered at the request of the passenger. If the existing travel plan is changed, then the process 400 provides a confirmation and updated instructions to the user device, as needed (task 420). The updated instructions can include any of the information and functionality described above in the context of the initial instructions (see task 410 and the related description). The monitoring performed by the process 400 is also utilized to control the dispatch timing and routing of vehicles in accordance with the multi-mode travel plan. More specifically, accurate monitoring of the passenger's travel progress can be used to synchronize the arrival of a vehicle (autonomous or traditional) with the arrival of the passenger at a departure location of an approaching vehicle segment or leg of the travel plan. [0062]) so that the vehicle estimated arrival time is the user estimated arrival time or later than the user estimated arrival time (and control dispatch timing of a vehicle in accordance with the multi-mode travel plan and in response to the monitored travel progress of the passenger to synchronize arrival of the vehicle with arrival of the passenger at a departure location of an approaching vehicle segment of the multi-mode travel plan. [0007]).
Regarding claim 4:
Glaser in view of Rakah, Namba, and Busch teaches all the limitations of claim 1, upon which this claim is dependent.
Glaser further teaches:
wherein the terminal includes a notification unit for notifying the user of information (The autonomous vehicle system 52 includes one or more backend server systems, which may be cloud-based, network-based, or resident at the particular campus or geographical location serviced by the vehicle system 52. The vehicle system 52 can be manned by at least one live advisor, at least one automated advisor, or a combination of both. The vehicle system 52 can communicate with the user devices 54 and the autonomous vehicles 10a-10n to schedule rides, dispatch autonomous vehicles 10a-10n, provide transportation status notifications, provide travel instructions, and the like. In various embodiments, the vehicle system 52 stores account information such as subscriber authentication information, vehicle identifiers, profile records, behavioral patterns, and other pertinent subscriber information. [0033]; status updates and notifications for the different transportation systems, including “on time” status reports, “delayed” status reports, and the like [0034]), the terminal communication unit receives information including the vehicle estimated arrival time from the server (the vehicle system 52 cooperates with the other transportation systems to manage multi-mode transit routes for passengers. Accordingly, the vehicle system 52 obtains (or estimates) departure locations, arrival locations, departure times, and arrival times for the various transportation systems, and intelligently dispatches vehicles at appropriate times that coordinate with the schedules and real-time status of the other transportation systems [0038]), and
the notification unit notifies the user of the vehicle estimated arrival time (status updates and notifications for the different transportation systems, including “on time” status reports, “delayed” status reports, and the like [0034]).
Regarding claim 5:
Glaser in view of Rakah, Namba, and Busch teaches all the limitations of claim 1, upon which this claim is dependent.
Glaser further teaches:
wherein the terminal includes a first terminal used by a first user (Although only one user device 54 is shown in FIG. 2, embodiments of the transportation system 50 can support any number of user devices 54, including multiple user devices 54 owned, operated, or otherwise used by one person. Each user device 54 supported by the system 50 may be implemented using any suitable hardware platform. In this regard, the user device 54 can be realized in any common form factor including, but not limited to: a desktop computer; a mobile computer (e.g., a tablet computer, a laptop computer, or a netbook computer); a smartphone; [0032])
the server communication unit receives first user position information indicating a position of the first user (it can also be used to locate and monitor the current location of passengers in an ongoing manner. [0035]; the autonomous vehicles 10 and the user devices 54 can include GPS receivers and/or other location determining hardware and functionality integrated therein. Thus, the vehicles 10 and/or the user devices 54 can communicate with GPS satellites and process geographical position information to calculate their current geographical positions. In practice, certain portions or aspects of the device-specific hardware, software, firmware, and features 308 may be implemented in one or more of the other blocks depicted in FIG. 4. [0049])
a present position of the first user and the position of the vehicle with respect to the first boarding point (accurate monitoring of the passenger's travel progress can be used to synchronize the arrival of a vehicle (autonomous or traditional) with the arrival of the passenger at a departure location of an approaching vehicle segment or leg of the travel plan. Accordingly, during the current or a previous leg of the travel route, the process 400 estimates or otherwise calculates the passenger arrival time at a departure location of an approaching vehicle segment. The estimated arrival time can be calculated based on any of the following, without limitation: the monitored current location and/or movement of the passenger or user device; the status or schedule information for the current mode of transportation; the status or schedule information for one or more intervening approaching modes of transportation (for travel segments between the current leg and the approaching vehicle leg); traffic data; weather data; police or emergency services notifications; etc. Again, the goal is to determine a good rendezvous time for the dispatched vehicle that will result in little to no wait time for the passenger at the upcoming departure location. Once the desired passenger arrival time is determined, the system can dispatch and/or control the operation of a vehicle as needed to reach the designated departure location at the rendezvous time. In practice, the system can estimate the driving time of the dispatched vehicle using existing techniques and technologies. In this regard, the driving time can be estimated based on the required mileage, traffic data, accident data, weather data, the time of day, and the like. [0062])
Rakah further teaches:
wherein the terminal includes a first terminal (fig. 1, user device 120A) used by a first user (fig. 1, user 130A) and a second terminal (fig. 1, user device 120B) used by a second user (fig. 1, user 130B);
the server communication unit receives first user position information indicating a position of the first user (Sensors, devices, and subsystems can be coupled to peripherals interface 206 to facilitate multiple functionalities. For example, a motion sensor 210, a light sensor 212, and a proximity sensor 214 may be coupled to peripherals interface 206 to facilitate orientation, lighting, and proximity functions. Other sensors 216 may also be connected to peripherals interface 206, such as a positioning system (e.g., UPS receiver), a temperature sensor, a biometric sensor, or other sensing device, to facilitate related functionalities. A GPS receiver may be integrated with, or connected to, mobile communications device 200. For example, a GPS receiver may be included in mobile telephones, such as smartphone devices. GPS software may allow mobile telephones to use an internal or external GPS receiver (e.g., connecting via a serial port or Bluetooth). [0092]; server 150 may use information received from a first communications device of a first user to predict when the first user will arrive the assigned first pick-up location. For example, the information used for predicting when the first user will arrive at the assigned first pick-up location may be derived from the ride request. Additionally or alternatively, the information used for predicting when the first user will arrive at the assigned first pick-up location is derived from a GPS of the first communications device. [0242]) and second user information indicating a position of second user (Sensors, devices, and subsystems can be coupled to peripherals interface 206 to facilitate multiple functionalities. For example, a motion sensor 210, a light sensor 212, and a proximity sensor 214 may be coupled to peripherals interface 206 to facilitate orientation, lighting, and proximity functions. Other sensors 216 may also be connected to peripherals interface 206, such as a positioning system (e.g., UPS receiver), a temperature sensor, a biometric sensor, or other sensing device, to facilitate related functionalities. A GPS receiver may be integrated with, or connected to, mobile communications device 200. For example, a GPS receiver may be included in mobile telephones, such as smartphone devices. GPS software may allow mobile telephones to use an internal or external GPS receiver (e.g., connecting via a serial port or Bluetooth). [0092]; the information related to the second pick-up location may include a current location of the second user (e.g., derived from a GPS device of a first communications device associated with the second user) and/or a user-requested pick-up location. For example, the second user may request to be picked up at a certain location (e.g., certain GPS coordinates, a certain physical address, or the like), e.g., by inputting the certain location into the first communications device associated with the first user. Optionally, the information related to the second pick-up location may also include a requested time for pick-up, e.g., based on input to the first communications device associated with the second user. [0272]);
the autonomous driving control unit controls traveling of the vehicle based on the vehicle allocation schedule (At step 417, ridesharing management server 150 may guide the assigned vehicle to the first pick-up location for picking up the first user. For example, ridesharing management server 150 may transmit direction information to the driver device associated with the assigned vehicle, for example, driver device 120D or driving-control device 120F. In some embodiments, a navigation component of the driver device, or the driving-control device may perform the step of guiding the vehicle to the first pick-up location. Correspondingly, ridesharing management server 150, or a navigation component of the user device 120A, may guide the user to the first pick-up location, in cases where the pick-up location is an assigned pick-location different from the first starting point. For example, for autonomous vehicles used for ridesharing services, such as autonomous vehicle 130F as shown in FIG. 1, the vehicle itself may be capable of using a variety of techniques to detect its surroundings, identify feasible paths, and navigate without direct human input. [0134]);
the vehicle management unit, when adjusting the first vehicle arrival time in accordance with a present position of the first user and the position of the vehicle with respect to the first boarding point (For example, the delay may be due to traffic, weather, vehicle malfunction, police activity, wrong turns, or the like. [0221]), prepares the vehicle allocation schedule after change (Ridesharing management server 150 may continuously receive location information to estimate arrival dines at respective pick-up locations. Accordingly, in example timeline 1030, ridesharing management server 150 may calculate an updated arrival time of the first ridesharing vehicle at the first pick-up location and/or the second pick-up location. Although not depicted in FIG. 10A, ridesharing server 150 may additionally or alternatively calculate an updated arrival time for the first user at the first pick-up location and/or an updated arrival time for the second user at the second pick-up location. In the example of timeline 1030, ridesharing management server 150 has predicted a delay in an arrival of the first ridesharing vehicle at the first pick-up location and/or the second pick-up location. For example, the delay may be due to traffic, weather, vehicle malfunction, police activity, wrong turns, or the like. [0221]);
the second terminal receives time information including the second vehicle arrival time after change indicated by the vehicle allocation schedule after the change (At step 422, ridesharing management server 150 may calculate a second estimated pick-up time, for example, based on a second current location of the vehicle and the second starting point. The second estimated pick-up time may refer to an estimated time period before the vehicle arrives at a second pick-up location for picking up the second user. The second pick-up location may be an assigned pick-up location different from, but associated with, the second starting point. Assignment of the second pick-up location may include similar steps as described above with reference to FIG. 4A, details of which are not repeated herein. [0138]; Ridesharing management server 150 may continuously receive location information to estimate arrival dines at respective pick-up locations. Accordingly, in example timeline 1030, ridesharing management server 150 may calculate an updated arrival time of the first ridesharing vehicle at the first pick-up location and/or the second pick-up location. Although not depicted in FIG. 10A, ridesharing server 150 may additionally or alternatively calculate an updated arrival time for the first user at the first pick-up location and/or an updated arrival time for the second user at the second pick-up location. In the example of timeline 1030, ridesharing management server 150 has predicted a delay in an arrival of the first ridesharing vehicle at the first pick-up location and/or the second pick-up location. For example, the delay may be due to traffic, weather, vehicle malfunction, police activity, wrong turns, or the like. [0221]), and
notifies the second user of the second vehicle arrival time (At step 424, ridesharing management server 150 may send a second message to the second wireless mobile communication device, which is user device 120B in this example. The second message may be configured to cause an indication of the calculated second estimated pick-up time to appear on a display of the second wireless mobile communication device. As described above with reference to FIG. 4A, the message may appear in different formats, and may further cause a display of multiple proposals with multiple options for the second pick-up location, walking distance, walking directions from the second starting point to the second pick-up location, etc., the details of which are not repeated herein. [0139]).
Regarding claim 6:
Glaser in view of Rakah, Namba, and Busch teaches all the limitations of claim 1, upon which this claim is dependent.
Glaser further teaches:
wherein the autonomous driving control unit does not control traveling of the vehicle with the autonomous driving function for adjusting the vehicle estimated arrival time to the user estimated arrival time or a time later than the user estimated arrival time (the vehicle system 52 and the process 400 can be designed to accommodate passenger customization or options that allow the passenger to view or select changes to the recommended travel plans. For example, the mobile app can display drop down menus or interactive tables that identify transportation system schedules, corresponding departure and destination locations, and the resulting time adjustments, relative to a suggested travel plan. In other words, the process 400 and the vehicle system 52 can be suitably designed to allow the passenger to “override” a recommended travel plan and/or to alter one or more legs of a recommended multi-mode travel plan. [0058]; examiner notes that although the desire is to arrive at the same time or later than the passenger, this is capable of being overwritten by user input and therefore result in the system being controlled to “not control traveling of the vehicle with the autonomous driving function for adjusting the vehicle estimated arrival time to the user estimated arrival time or a time later than the user estimated arrival time”.).
Regarding claim 7:
Glaser teaches:
A vehicle management device (A multi-mode transportation management method is presented here. [0006]; A computer-based system is also presented here. [0007]) comprising:
a communication unit for receiving (The navigation and map system 68 can be an independent and distinct subsystem, or it can be integrated with the vehicle system 52 and/or any of the other systems described herein. The navigation and map system 68 may be implemented with one or more backend server systems, which may be cloud-based, network-based, or resident at the particular geographical location serviced by the vehicle system 52. In some embodiments, the navigation and map system 68 includes or cooperates with compatible features, functions, or applications resident at the AVs 10 and/or resident at the user devices 54. For example, a user device 54 may include a locally installed navigation or mapping app that receives and processes data provided by the navigation and map system 68. In this regard, the user device 54 may leverage cached map data, or it may rely on map data provided via the communication network 56. The navigation and map system 68 can be used to determine passenger transportation routes to be followed by the vehicles, and it can also be used to locate and monitor the current location of passengers in an ongoing manner. [0035]), vehicle position information indicating a present position of the user from a terminal (the user device 54 includes a GPS module capable of receiving GPS satellite signals and generating GPS coordinates based on those signals. In other embodiments, the user device 54 includes cellular communications functionality such that the device carries out voice and/or data communications over the communication network 56 using one or more cellular communications protocols, as are discussed herein [0032]) and vehicle position information indicating a present position of a vehicle from the vehicle with an autonomous driving function (The positioning system 106 processes sensor data along with other data to determine a position (e.g., a local position relative to a map, an exact position relative to lane of a road, vehicle heading, velocity, etc.) of the vehicle 10 relative to the environment. The guidance system 108 processes sensor data along with other data to determine a path for the vehicle 10 to follow. The vehicle control system 110 generates control signals for controlling the vehicle 10 according to the determined path. [0042]);
an autonomous driving control unit (The autonomous vehicle system 52 includes one or more backend server systems, which may be cloud-based, network-based, or resident at the particular campus or geographical location serviced by the vehicle system 52 [0033]) for controlling traveling of the vehicle (the vehicle system 52 may cooperate with the navigation and map system 68 and/or any number of the other transportation systems to manage the dispatching of vehicles and to otherwise support certain features and functions of the multi-mode transportation system. [0034]; The vehicle system 52 receives the transportation request, processes the request in an appropriate manner, and dispatches or otherwise controls one or more vehicles (e.g., an AV 10) such that the vehicle conveniently meets the passenger at a scheduled pickup point at the appropriate time. [0034]);
a vehicle management unit (a multi-mode transportation system 50 [0028]) for setting a boarding point at which the user rides the vehicle (The system 50 can include any number of predefined vehicle pickup/drop-off locations that are known to the vehicle system 52. Alternatively or additionally, the vehicle system 52 can leverage GPS technology (and/or other position or location determination techniques or methodologies) to pick up passengers at any location and/or to leave passengers at any desired destination location. [0034]), calculating a user estimated arrival time at which the user arrives at the boarding point based on the present position of the user (the travel timing information may include, without limitation: a particular departure time; a destination arrival time; an intermediate or intersegment destination arrival time (e.g., a transfer or layover time between two travel segments) [0034]; the process 400 estimates or otherwise calculates the passenger arrival time at a departure location of an approaching vehicle segment. The estimated arrival time can be calculated based on any of the following, without limitation: the monitored current location and/or movement of the passenger or user device; the status or schedule information for the current mode of transportation; the status or schedule information for one or more intervening approaching modes of transportation (for travel segments between the current leg and the approaching vehicle leg); traffic data; weather data; police or emergency services notifications; etc. Again, the goal is to determine a good rendezvous time for the dispatched vehicle that will result in little to no wait time for the passenger at the upcoming departure location. [0062]), and for managing traveling of the vehicle (The vehicle system 52 receives the transportation request, processes the request in an appropriate manner, and dispatches or otherwise controls one or more vehicles (e.g., an AV 10) such that the vehicle conveniently meets the passenger at a scheduled pickup point at the appropriate time. As explained in more detail below, the vehicle system 52 may cooperate with the navigation and map system 68 and/or any number of the other transportation systems to manage the dispatching of vehicles and to otherwise support certain features and functions of the multi-mode transportation system. [0034]), wherein the vehicle management unit:
calculates a vehicle estimated arrival time at which the vehicle arrives at the first boarding point [and the second boarding point] based on the vehicle position information (The transportation request will typically identify a pickup or starting location for the passenger (or a current GPS location), the desired destination location for the passenger (which may be a predefined vehicle stop and/or a user-specified destination), and certain travel timing information. In this context, the travel timing information may include, without limitation: a particular departure time; a destination arrival time; an intermediate or intersegment destination arrival time (e.g., a transfer or layover time between two travel segments); a request for an immediate passenger pickup; or any combination thereof. [0034]; the vehicle system 52 obtains (or estimates) departure locations, arrival locations, departure times, and arrival times for the various transportation systems [0038]; the system can estimate the driving time of the dispatched vehicle using existing techniques and technologies. [0062]) and calculates a difference between the user estimated arrival time at which the second user arrives at the second boarding point while the first user is riding in the vehicle (examiner notes that a passenger being preset or not inside the vehicle would not affect the vehicles ability to calculate a time between estimated arrival time of the vehicle and a passenger waiting to be picked up.) and the vehicle estimated arrival time at which the vehicle arrives at the second boarding point (examiner notes that in order to synchronize the arrival of the vehicle with the passenger Glaser inherently must be able to determine a difference between the arrival time of the user and of the vehicle.); and
compares the difference with [a predetermined time threshold] (Once the desired passenger arrival time is determined, the system can dispatch and/or control the operation of a vehicle as needed to reach the designated departure location at the rendezvous time. In practice, the system can estimate the driving time of the dispatched vehicle using existing techniques and technologies. In this regard, the driving time can be estimated based on the required mileage, traffic data, accident data, weather data, the time of day, and the like. [0062]; accurate monitoring of the passenger's travel progress can be used to synchronize the arrival of a vehicle (autonomous or traditional) with the arrival of the passenger at a departure location of an approaching vehicle segment or leg of the travel plan. [0062]; examiner notes that the synchronizing the arrival the system inherently is comparing the users estimated arrival time with that of the vehicle.), while the vehicle is traveling (control the operation of a vehicle as needed to reach the designated departure location at the rendezvous time [0062]; examiner notes that the Glaser teaches adjusting the dispatch time or control of the vehicle after being dispatched to synchronize the arrival time which would occur while the vehicle is travelling if it has already been dispatched.)
wherein the autonomous driving control unit is configured to adjust a travel route (control the operation of a vehicle [0062]) of the vehicle with the autonomous driving function controls travelling (dispatches or otherwise controls one or more vehicles (e.g., an AV 10) such that the vehicle conveniently meets the passenger at a scheduled pickup point at the appropriate time [0034]) so that the estimated arrival time of the vehicle is later than the estimated arrival time of the second user (Again, the goal is to determine a good rendezvous time for the dispatched vehicle that will result in little to no wait time for the passenger at the upcoming departure location. Once the desired passenger arrival time is determined, the system can dispatch and/or control the operation of a vehicle as needed to reach the designated departure location at the rendezvous time. [0062])
Glaser does not explicitly teach, however Rakah teaches:
prepares a vehicle allocation schedule (a system for managing a fleet of ridesharing vehicles may comprise a communications interface configured to receive requests for shared rides from a plurality of users and at least one processor. The at least one processor may be configured to identify a first ridesharing vehicle and a second ridesharing vehicle that are currently without passengers and receive, via the communications interface, a first request for a shared ride from a first user. The first request may include information related to a first pick-up location of the first user and a first desired destination of the first user. The at least one processor may be further configured to receive, via the communications interface, a second request for a shared ride from a second user. The second request may include information related to a second pick-up location of the second user and a second desired destination of the second user. The at least one processor may be further configured to assign the first user and the second user to the first ridesharing vehicle; generate a route to the first ridesharing vehicle for picking up and dropping off each of the first user and the second user [0010]), where the vehicle allocation schedule at least indicates that a first user boards the vehicle at a first boarding point (the message includes a confirmation that the ridesharing request is accepted. If ridesharing management server 150 assigns a pick-up location different from the starting point, the message may further cause the display of an indication of the assigned pick-up location. Ridesharing management server 150 may further provide a navigation option which may be displayed on a user interface. A selection of the navigation option may then provide walking directions the user to the assigned pick-up location for pick-up. The message may further cause a display of an indication of an estimated walking distance from the starting point to the assigned pick-up location. In addition, the message may include an estimated walking distance from the assigned drop-off location to the desired destination. The assigned drop-off location may be a location close to the desired destination, within the maximum walking distance parameters set by the first user. For example, the drop-off location may be at a location half a block away or further from the desired destination, and may be along a main street where the vehicle may easily locate and access. For another example, the drop-off location may be determined based on a route towards the next pick-up location, such that the vehicle may easily drop-off the first user on its way to the next pick-up location, thereby avoiding an extra detour. [0132]) and that a second user boards the vehicle at a second boarding point (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. [0136]),
calculates a vehicle estimated arrival time at which the vehicle arrives at the first boarding point (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. [0075]) and the second boarding point (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. [0076])
It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to have modified Glaser to include the teachings as taught by Rakah with a reasonable expectation of success. Rakah teaches “Recent years have witnessed increasing interest and development in the field of vehicle sharing, where one or more riders may share the same vehicle for a portion of their rides. Ridesharing may save ride costs, increase vehicle utilization, and reduce air pollution. [Rakah, 0003]”. Both inventions are also in the same field of endeavor of control of vehicles for ridesharing/taxi purposes.
Glaser in view of Rakah does not explicitly teach, however Namba teaches:
and calculates a difference (the cancellation decision unit 207 compares the time lag (T2-T1), obtained by subtracting the first time T1 from the second time T2 [0098]) between the user estimated arrival time at which the second user arrives at the second boarding point (The second time T2 is a time when the scheduled passenger 6 is going to arrive at the boarding location P11 [0091]) while the first user is riding in the vehicle (the search unit 203 searches for a recommended candidate from among the plurality of cars 3 by taking, into account, how the on-board passenger's terms of use will be affected when each of the plurality of cars 3 is used by the potential user. This allows the search unit 203 to search for a recommended candidate from among the plurality of cars 3, depending on the degree of change of the terms of use of the on-board passenger [0071]) and the vehicle estimated arrival time at which the vehicle arrives at the second boarding point (The first time T1 is a time when the car 3A that the scheduled passenger 6 is scheduled to board is expected to arrive at the boarding location P11 [0091]); and
compares the difference with a predetermined time threshold while the vehicle is traveling (In Step S24, the cancellation decision unit 207 compares the time lag (T2-T1), obtained by subtracting the first time T1 from the second time T2, to a second threshold value Th2. The time lag (T2-T1), obtained by subtracting the first time T1 from the second time T2, has a positive value in a situation where the car 3A arrives at the boarding location P11 earlier than the scheduled passenger 6. In that case, the time lag (T2-T1), obtained by subtracting the first time T1 from the second time T2 corresponds to the car's 3A waiting time [0098]) and determines whether a delay of an arrival of the second user is greater than or equal to a predetermined value (fig. 5, S24 - YES).
cancels a ride of the second user (when finding the time lag (T2-T1), obtained by subtracting the first time T1 from the second time T2, greater than the second threshold value Th2 (i.e., when finding the car's 3A waiting time greater than the second threshold value Th2) (if the answer is YES in Step S24), the cancellation decision unit 207 proceeds to Step S25 to perform the processing of canceling the boarding reservation [0100]) when the delay of the arrival of the second user is greater than or equal to the predetermined value (fig. 5, S24 - YES), and prepares a changed vehicle allocation schedule after removing the second user as the user of the vehicle (This message allows the scheduled passenger 6 to learn that his or her boarding reservation for the car 3A has been canceled. Meanwhile, when the communications unit 31 of the car 3A receives the driving instruction information from the management server 2, the processing unit 30 controls the driving control unit 34 to drive the car 3A following the updated scheduled route. [0104]),
when the delay of arrival of the second user is less than the predetermined value (fig. 5, S24 - NO)
It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to have modified Glaser and Rakah to include the teachings as taught by Namba with a reasonable expectation of success. Namba teaches the benefit of “if the arrival of either the scheduled passenger 6 or the car 3A at the boarding location P11 is delayed, then the management server 2 automatically cancels the boarding reservation made by the scheduled passenger 6. This saves the scheduled passenger 6 the trouble to cancel the boarding reservation by him- or herself and provides a boarding management system 1 with improved user friendliness. In addition, if it is predicted that the arrival of either the scheduled passenger 6 or the car 3A would be delayed, the management server 2 cancels, in advance, the boarding reservation made by the scheduled passenger 6. This avoids a situation where the scheduled passenger 6 or the on-board passenger already aboard the car 3A has to wait at the boarding location P11 for an amount of time longer than the threshold value. This provides a boarding management system 1 with further improved user-friendliness and convenience [Namba, 0105]”.
Glaser, Rakah, and Namba do not explicitly teach, however Busch teaches:
the estimated arrival time of the vehicle is later than the estimated arrival time of the second user (Based upon an estimated delay for attendee 1, for instance of an hour or more, [0059]) and so that the travel route passes through scenic waypoints for the first user (Based upon an estimated delay for attendee 1, for instance of an hour or more, the system may present attendee 2 with the option to avoid the current route down the thruway between Albany and New York City, which includes tolls 800, and take a more scenic route, such as the Taconic Parkway, from Albany to New York City, to arrive at the meeting location at about the same time as the delayed attendee 1 is now projected to arrive at the meeting location [0059])
It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to have modified Glaser, Rakah, and Namba to include the teachings as taught by Busch with a reasonable expectation of success. Busch teaches the benefit of “the calendaring and travel facility disclosed herein allows multiple attendees to be notified should one of the attendees experience a travel delay, with the information being automatically shared in order to save time and potentially costs for attendees traveling to a meeting, for example, where the meeting is likely to be delayed. The system assumes that the calendaring programs used by the attendees to the meeting, particularly the traveling attendees, are able to share their starting or originating location, and if needed, a likely route each attendee would take. This information may then be shared with the navigation or travel facility. Traveling attendees to the meeting may use their navigation system to initially select the best route for the user subject to the constraint of arriving at the meeting location at the meeting time [Busch, 0060]”.
Regarding claim 8:
Glaser teaches:
A vehicle control method for managing a vehicle (A multi-mode transportation management method is presented here. [0006]; A computer-based system is also presented here. [0007]) with an autonomous driving function (The positioning system 106 processes sensor data along with other data to determine a position (e.g., a local position relative to a map, an exact position relative to lane of a road, vehicle heading, velocity, etc.) of the vehicle 10 relative to the environment. The guidance system 108 processes sensor data along with other data to determine a path for the vehicle 10 to follow. The vehicle control system 110 generates control signals for controlling the vehicle 10 according to the determined path. [0042]), using a server (The autonomous vehicle system 52 includes one or more backend server systems, which may be cloud-based, network-based, or resident at the particular campus or geographical location serviced by the vehicle system 52 [0033]), the vehicle control method comprising:
receiving user position information indicating a present position of the user (the user device 54 includes a GPS module capable of receiving GPS satellite signals and generating GPS coordinates based on those signals. In other embodiments, the user device 54 includes cellular communications functionality such that the device carries out voice and/or data communications over the communication network 56 using one or more cellular communications protocols, as are discussed herein [0032]);
receiving vehicle position information indicating a present position of the vehicle from the vehicle (The positioning system 106 processes sensor data along with other data to determine a position (e.g., a local position relative to a map, an exact position relative to lane of a road, vehicle heading, velocity, etc.) of the vehicle 10 relative to the environment. The guidance system 108 processes sensor data along with other data to determine a path for the vehicle 10 to follow. The vehicle control system 110 generates control signals for controlling the vehicle 10 according to the determined path. [0042]), the user position information from the terminal communication unit (the user device 54 includes a GPS module capable of receiving GPS satellite signals and generating GPS coordinates based on those signals. In other embodiments, the user device 54 includes cellular communications functionality such that the device carries out voice and/or data communications over the communication network 56 using one or more cellular communications protocols, as are discussed herein [0032]);
setting a boarding point at which the user rides the vehicle (The system 50 can include any number of predefined vehicle pickup/drop-off locations that are known to the vehicle system 52. Alternatively or additionally, the vehicle system 52 can leverage GPS technology (and/or other position or location determination techniques or methodologies) to pick up passengers at any location and/or to leave passengers at any desired destination location. [0034]);
calculates a vehicle estimated arrival time at which the vehicle arrives at the first boarding point [and the second boarding point] based on the vehicle position information (The transportation request will typically identify a pickup or starting location for the passenger (or a current GPS location), the desired destination location for the passenger (which may be a predefined vehicle stop and/or a user-specified destination), and certain travel timing information. In this context, the travel timing information may include, without limitation: a particular departure time; a destination arrival time; an intermediate or intersegment destination arrival time (e.g., a transfer or layover time between two travel segments); a request for an immediate passenger pickup; or any combination thereof. [0034]; the vehicle system 52 obtains (or estimates) departure locations, arrival locations, departure times, and arrival times for the various transportation systems [0038]; the system can estimate the driving time of the dispatched vehicle using existing techniques and technologies. [0062]) and calculates a difference between the user estimated arrival time at which the second user arrives at the second boarding point while the first user is riding in the vehicle (examiner notes that a passenger being preset or not inside the vehicle would not affect the vehicles ability to calculate a time between estimated arrival time of the vehicle and a passenger waiting to be picked up.) and the vehicle estimated arrival time at which the vehicle arrives at the second boarding point (examiner notes that in order to synchronize the arrival of the vehicle with the passenger Glaser inherently must be able to determine a difference between the arrival time of the user and of the vehicle.); and
compares the difference with [a predetermined time threshold] (Once the desired passenger arrival time is determined, the system can dispatch and/or control the operation of a vehicle as needed to reach the designated departure location at the rendezvous time. In practice, the system can estimate the driving time of the dispatched vehicle using existing techniques and technologies. In this regard, the driving time can be estimated based on the required mileage, traffic data, accident data, weather data, the time of day, and the like. [0062]; accurate monitoring of the passenger's travel progress can be used to synchronize the arrival of a vehicle (autonomous or traditional) with the arrival of the passenger at a departure location of an approaching vehicle segment or leg of the travel plan. [0062]; examiner notes that the synchronizing the arrival the system inherently is comparing the users estimated arrival time with that of the vehicle.), while the vehicle is traveling (control the operation of a vehicle as needed to reach the designated departure location at the rendezvous time [0062]; examiner notes that the Glaser teaches adjusting the dispatch time or control of the vehicle after being dispatched to synchronize the arrival time which would occur while the vehicle is travelling if it has already been dispatched.)
wherein the autonomous driving control unit is configured to adjust a travel route (control the operation of a vehicle [0062]) of the vehicle with the autonomous driving function controls travelling (dispatches or otherwise controls one or more vehicles (e.g., an AV 10) such that the vehicle conveniently meets the passenger at a scheduled pickup point at the appropriate time [0034]) so that the estimated arrival time of the vehicle is later than the estimated arrival time of the second user (Again, the goal is to determine a good rendezvous time for the dispatched vehicle that will result in little to no wait time for the passenger at the upcoming departure location. Once the desired passenger arrival time is determined, the system can dispatch and/or control the operation of a vehicle as needed to reach the designated departure location at the rendezvous time. [0062])
Glaser does not explicitly teach, however Rakah teaches:
prepares a vehicle allocation schedule (a system for managing a fleet of ridesharing vehicles may comprise a communications interface configured to receive requests for shared rides from a plurality of users and at least one processor. The at least one processor may be configured to identify a first ridesharing vehicle and a second ridesharing vehicle that are currently without passengers and receive, via the communications interface, a first request for a shared ride from a first user. The first request may include information related to a first pick-up location of the first user and a first desired destination of the first user. The at least one processor may be further configured to receive, via the communications interface, a second request for a shared ride from a second user. The second request may include information related to a second pick-up location of the second user and a second desired destination of the second user. The at least one processor may be further configured to assign the first user and the second user to the first ridesharing vehicle; generate a route to the first ridesharing vehicle for picking up and dropping off each of the first user and the second user [0010]), where the vehicle allocation schedule at least indicates that a first user boards the vehicle at a first boarding point (the message includes a confirmation that the ridesharing request is accepted. If ridesharing management server 150 assigns a pick-up location different from the starting point, the message may further cause the display of an indication of the assigned pick-up location. Ridesharing management server 150 may further provide a navigation option which may be displayed on a user interface. A selection of the navigation option may then provide walking directions the user to the assigned pick-up location for pick-up. The message may further cause a display of an indication of an estimated walking distance from the starting point to the assigned pick-up location. In addition, the message may include an estimated walking distance from the assigned drop-off location to the desired destination. The assigned drop-off location may be a location close to the desired destination, within the maximum walking distance parameters set by the first user. For example, the drop-off location may be at a location half a block away or further from the desired destination, and may be along a main street where the vehicle may easily locate and access. For another example, the drop-off location may be determined based on a route towards the next pick-up location, such that the vehicle may easily drop-off the first user on its way to the next pick-up location, thereby avoiding an extra detour. [0132]) and that a second user boards the vehicle at a second boarding point (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. [0136]),
calculates a vehicle estimated arrival time at which the vehicle arrives at the first boarding point (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. [0075]) and the second boarding point (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. [0076])
It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to have modified Glaser to include the teachings as taught by Rakah with a reasonable expectation of success. Rakah teaches “Recent years have witnessed increasing interest and development in the field of vehicle sharing, where one or more riders may share the same vehicle for a portion of their rides. Ridesharing may save ride costs, increase vehicle utilization, and reduce air pollution. [Rakah, 0003]”. Both inventions are also in the same field of endeavor of control of vehicles for ridesharing/taxi purposes.
Glaser in view of Rakah does not explicitly teach, however Namba teaches:
and calculates a difference (the cancellation decision unit 207 compares the time lag (T2-T1), obtained by subtracting the first time T1 from the second time T2 [0098]) between the user estimated arrival time at which the second user arrives at the second boarding point (The second time T2 is a time when the scheduled passenger 6 is going to arrive at the boarding location P11 [0091]) while the first user is riding in the vehicle (the search unit 203 searches for a recommended candidate from among the plurality of cars 3 by taking, into account, how the on-board passenger's terms of use will be affected when each of the plurality of cars 3 is used by the potential user. This allows the search unit 203 to search for a recommended candidate from among the plurality of cars 3, depending on the degree of change of the terms of use of the on-board passenger [0071]) and the vehicle estimated arrival time at which the vehicle arrives at the second boarding point (The first time T1 is a time when the car 3A that the scheduled passenger 6 is scheduled to board is expected to arrive at the boarding location P11 [0091]); and
compares the difference with a predetermined time threshold while the vehicle is traveling (In Step S24, the cancellation decision unit 207 compares the time lag (T2-T1), obtained by subtracting the first time T1 from the second time T2, to a second threshold value Th2. The time lag (T2-T1), obtained by subtracting the first time T1 from the second time T2, has a positive value in a situation where the car 3A arrives at the boarding location P11 earlier than the scheduled passenger 6. In that case, the time lag (T2-T1), obtained by subtracting the first time T1 from the second time T2 corresponds to the car's 3A waiting time [0098]) and determines whether a delay of an arrival of the second user is greater than or equal to a predetermined value (fig. 5, S24 - YES).
cancels a ride of the second user (when finding the time lag (T2-T1), obtained by subtracting the first time T1 from the second time T2, greater than the second threshold value Th2 (i.e., when finding the car's 3A waiting time greater than the second threshold value Th2) (if the answer is YES in Step S24), the cancellation decision unit 207 proceeds to Step S25 to perform the processing of canceling the boarding reservation [0100]) when the delay of the arrival of the second user is greater than or equal to the predetermined value (fig. 5, S24 - YES), and prepares a changed vehicle allocation schedule after removing the second user as the user of the vehicle (This message allows the scheduled passenger 6 to learn that his or her boarding reservation for the car 3A has been canceled. Meanwhile, when the communications unit 31 of the car 3A receives the driving instruction information from the management server 2, the processing unit 30 controls the driving control unit 34 to drive the car 3A following the updated scheduled route. [0104]),
when the delay of arrival of the second user is less than the predetermined value (fig. 5, S24 - NO)
It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to have modified Glaser and Rakah to include the teachings as taught by Namba with a reasonable expectation of success. Namba teaches the benefit of “if the arrival of either the scheduled passenger 6 or the car 3A at the boarding location P11 is delayed, then the management server 2 automatically cancels the boarding reservation made by the scheduled passenger 6. This saves the scheduled passenger 6 the trouble to cancel the boarding reservation by him- or herself and provides a boarding management system 1 with improved user friendliness. In addition, if it is predicted that the arrival of either the scheduled passenger 6 or the car 3A would be delayed, the management server 2 cancels, in advance, the boarding reservation made by the scheduled passenger 6. This avoids a situation where the scheduled passenger 6 or the on-board passenger already aboard the car 3A has to wait at the boarding location P11 for an amount of time longer than the threshold value. This provides a boarding management system 1 with further improved user-friendliness and convenience [Namba, 0105]”.
Glaser, Rakah, and Namba do not explicitly teach, however Busch teaches:
the estimated arrival time of the vehicle is later than the estimated arrival time of the second user (Based upon an estimated delay for attendee 1, for instance of an hour or more, [0059]) and so that the travel route passes through scenic waypoints for the first user (Based upon an estimated delay for attendee 1, for instance of an hour or more, the system may present attendee 2 with the option to avoid the current route down the thruway between Albany and New York City, which includes tolls 800, and take a more scenic route, such as the Taconic Parkway, from Albany to New York City, to arrive at the meeting location at about the same time as the delayed attendee 1 is now projected to arrive at the meeting location [0059])
It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to have modified Glaser, Rakah, and Namba to include the teachings as taught by Busch with a reasonable expectation of success. Busch teaches the benefit of “the calendaring and travel facility disclosed herein allows multiple attendees to be notified should one of the attendees experience a travel delay, with the information being automatically shared in order to save time and potentially costs for attendees traveling to a meeting, for example, where the meeting is likely to be delayed. The system assumes that the calendaring programs used by the attendees to the meeting, particularly the traveling attendees, are able to share their starting or originating location, and if needed, a likely route each attendee would take. This information may then be shared with the navigation or travel facility. Traveling attendees to the meeting may use their navigation system to initially select the best route for the user subject to the constraint of arriving at the meeting location at the meeting time [Busch, 0060]”.
Regarding claim 10:
Glaser in view of Rakah, Namba, and Busch teaches all the limitations of claim 1, upon which this claim is dependent.
Rakah further teaches:
wherein the autonomous driving control unit adjusts at least one of the travel route (the first ridesharing vehicle may be re-routed to bypass the pick-up location of the first user [0201]) and the vehicle speed (examiner is interpreting this limitation in the alternative.) based upon:
the vehicle estimated arrival time at the boarding point being earlier than the user estimated arrival time due to the shorter travel route (For example, the first ridesharing vehicle may be re-routed to bypass the pick-up location of the first user and therefore reach another pick-up location or drop-off location at an earlier time and/or after traversing a shorter distance. [0201]).
Regarding claim 11:
Glaser in view of Rakah, Namba, and Busch teaches all the limitations of claim 1, upon which this claim is dependent.
Glaser further teaches:
wherein the server notifies a destination facility of a changed estimated arrival time when the user has reserved service for the destination facility and the vehicle is late for arrival at the destination facility (In some embodiments, the transportation schedule for a passenger can be adjusted to account for changes in schedule (e.g., if a train is late, the autonomous vehicle coming to pick the passenger up could be dispatched to another passenger, and a new autonomous vehicle can be dispatched later to the pick-up the passenger). Dispatching of autonomous vehicles can be dynamically adjusted to changes in the passenger's travel schedule so that an autonomous vehicle is at a particular location when the passenger arrives even when the passenger's schedule changes. As such, autonomous vehicles do not waste time waiting for a passenger to arrive when his/her schedule changes while traveling along the route. If the change in arrival time is significant, a new autonomous vehicle can be dispatched so that the originally scheduled autonomous vehicle can be dispatched to another passenger [0024]; examiner notes that whether it is a vehicle service receiving an notification of a user being late via a train or a vehicle being late to its destination, that would simply be a reversal of parts and therefore an obvious modification. See MPEP 2144.04(VI)(A).).
Regarding claim 12:
Glaser in view of Rakah, Namba, and Busch teaches all the limitations of claim 1, upon which this claim is dependent.
Rakah further teaches:
wherein, when the delay of arrival of the second user is greater than or equal to the predetermined value (assignment module 920 may cancel the assignment of the first rideshare vehicle when an estimated arrival time of the first ridesharing vehicle is before an estimated arrival time of the first user. In certain aspects, assignment module 920 may cancel the assignment of the first rideshare vehicle when the estimated arrival lime of the first ridesharing vehicle is more than a predetermined period of time (e.g., 0.5 minutes, 1 minute, 2 minutes, 3 minutes, 5 minutes, or the like) before the estimated arrival time of the first user [0197]), the vehicle management unit:
determines whether the second user is moving toward the second boarding point based on the present position of the second user (a predicted arrival time when the first user will arrive at the first pick-up location [0195]; examiner notes that in order to predict the arrival time the system inherently determines that the user is progressing towards the pick-up location.),
identifies other vehicles available for the second user to board when determining that the second user is moving toward the second boarding point (server 150 may cancel another assignment to the first vehicle and re-assign that request to a second vehicle [0180]), and
transmits vehicle information about the identified other vehicles to a terminal of the second user (The re-assignment may be performed similar to the initial assignment. For example, assignment module 920 may assign the first user to the second ridesharing vehicle based on a current location of the second ridesharing vehicle and a desired destination of the at least one second use [0196]).
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Glaser (US 2018/0308064), herein Glaser in view of Rakah et. al. (US 2018/0211541), herein Rakah, Namba et. al. (US 2019/0303806), herein Namba, and Busch et. al. (US 2018/0197153), herein Busch in further view of Hashisho (US 2019/0086219), herein Hashisho.
Regarding claim 2:
Glaser in view of Rakah, Namba, and Busch teaches all the limitations of claim 1, upon which this claim is dependent.
Glaser further teaches:
wherein the autonomous driving control unit controls the vehicle speed (The positioning system 106 processes sensor data along with other data to determine a position (e.g., a local position relative to a map, an exact position relative to lane of a road, vehicle heading, velocity, etc.) of the vehicle 10 relative to the environment. The guidance system 108 processes sensor data along with other data to determine a path for the vehicle 10 to follow. The vehicle control system 110 generates control signals for controlling the vehicle 10 according to the determined path. [0042]) of the vehicle so that the vehicle estimated arrival time is the user estimated arrival time or later than the user estimated arrival time (and control dispatch timing of a vehicle in accordance with the multi-mode travel plan and in response to the monitored travel progress of the passenger to synchronize arrival of the vehicle with arrival of the passenger at a departure location of an approaching vehicle segment of the multi-mode travel plan. [0007]).
Glaser in view of Rakah, Namba, and Busch does not explicitly teach, however Hashisho teaches:
controls the vehicle speed (provide an instruction to either increase speed or decrease speed in response to the change in availability of the respective node [0004]) of the vehicle so that the vehicle estimated arrival time (The processing circuitry may optionally be configured to: monitor progress of a vehicle along the established recommended route; determine an estimated time of arrival at a next node in the sequence of nodes of the established recommended route based on vehicle information; determine if the estimated time of arrival at a next node in the sequence of the established recommended route corresponds to the anticipated time for the corresponding node; and provide an instruction to either increase speed or decrease speed in response to the estimated time of arrival at the next node not corresponding to the anticipated time for the corresponding node. [0004]) is the user estimated arrival time or later than the user estimated arrival time (examiner notes that in view of Glaser, one having ordinary skill in the art would be able to apply the modification of speed to alter arrival time as taught by Hashisho to control the arrival time to arrive at the same time or later as the user as taught by Glaser.).
It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to have modified Glaser in view of Rakah, Namba, and Busch to include the teachings as taught by Hashisho with a reasonable expectation of success. Hashisho teaches “the processing circuitry may be configured to: monitor the availability of each node of the established recommended route; determine, for at least one node, a change in availability of the respective node in the sequence at the anticipated time the node would be reached; determine potential routes from a current location to the destination, where each route includes a sequence of nodes; determine, for each sequence of nodes, an anticipated time at which point each node in the sequence would be reached; determine, for each sequence of nodes, the availability of each node in the sequence at the anticipated time each node in the sequence would be reached; establish a revised recommended route between the current location and the destination according to the availability of each of the sequence of nodes in the sequence at the time the node would be reached; and provide an instruction to follow the established revised recommended route. In response to establishing the revised recommended route from the current location to the destination, a node that was in the recommended route between the origin and the destination, but not in the revised recommended route between the current location and the destination is released to increase the availability of the node at the anticipated time the node in the sequence of the recommended route would have been reached. [Hashisho, 0005]”. This provides a benefit of being able to anticipate possible traffic ramifications of adjusting the routing of the vehicle.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Glaser (US 2018/0308064), herein Glaser in view of Rakah et. al. (US 2018/0211541), herein Rakah, Namba et. al. (US 2019/0303806), herein Namba, and Busch et. al. (US 2018/0197153), herein Busch in further view of Pallett et. al. (US 2016/0009291), herein Pallett.
Regarding claim 9:
Glaser in view of Rakah, Namba, and Busch teaches all the limitations of claim 1, upon which this claim is dependent.
Glaser further teaches:
so that the vehicle estimated arrival time is the user estimated arrival time or later than the user estimated arrival time (Again, the goal is to determine a good rendezvous time for the dispatched vehicle that will result in little to no wait time for the passenger at the upcoming departure location. Once the desired passenger arrival time is determined, the system can dispatch and/or control the operation of a vehicle as needed to reach the designated departure location at the rendezvous time. [0062]).
Glaser in view of Rakah, Namba, and Busch does not explicitly teach, however Pallett teaches:
wherein the autonomous driving control unit is configured to change the travel mode of the vehicle (As illustrated in FIG. 1, the autonomous vehicle 100 includes an autonomous driving system 105 configured to implement a selected driving mode. Once selected, the autonomous driving system 105 may control various vehicle subsystems in accordance with the selected mode. That is, the autonomous driving system 105 may adjust driving characteristics as well as a vehicle “personality.” Examples of the driving modes may include a “time to target” mode, an “eco-friendly” mode, a “chauffeur” mode, a “sport” mode, and a “race car” mode. [0008]) from the power mode with an increased energy consumption during vehicle traveling allowing the vehicle to arrive at a target point more quickly (When operating in the “time to target” mode, the autonomous driving system 105 may prioritize reaching the target destination as quickly as possible relative to traffic laws and the current traffic patterns. This may include aggressively accelerating and decelerating the vehicle 100, performing aggressive cornering maneuvers, aggressively entering and crossing traffic, changing lanes frequently, making more abrupt steering actions. Moreover, the autonomous driving system 105 may leave less room between the autonomous vehicle 100 and a front vehicle (i.e., the vehicle immediately in front of the autonomous vehicle 100). The “time to target” mode may further have the autonomous vehicle 100 drive at appropriate speeds relative to the speed limit and traffic density. [0009]) to the eco-mode reducing the energy consumption during vehicle traveling and suppressing changes in vehicle speed (The “eco-friendly” mode may prioritize maximizing fuel economy. When operating in the “eco-friendly” mode, the autonomous driving system 105 may implement hyper-miling techniques such as minimizing vehicle accelerations and decelerations as much as possible and allowing increased distance between the autonomous vehicle 100 and the front vehicle. Another hyper-miling technique may include pulse driving. Pulse driving may include quickly accelerating to the driving speed and then coasting for as long as possible. [0010]),
It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to have modified Glaser in view of Rakah, Namba, and Busch to include the teachings as taught by Pallett with a reasonable expectation of success. Glaser teaches the ability to control a vehicle to synchronize the arrival time of vehicle with a passenger to minimize waiting time. Glaser also teaches the ability to adapt control of the vehicle to adapt to a changing arrival time but does not explicitly teach that the control adjustment is between a “power” and “eco” modes. Pallett teaches the ability to adapt an autonomous vehicle to alter from a power mode (time to target) and an eco mode which provides the benefits to “prioritize reaching the target destination as quickly as possible relative to traffic laws and the current traffic patterns [Pallett, 0009]” and “mode may prioritize maximizing fuel economy [Pallett, 0010]”.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hansen (US 2017/0108348) discloses A method is described for incorporating a new waypoint into a current trip. The method includes configuring a trip definition and thereafter determining a proposed POI based upon: the trip definition, and a collection of potential proposed POI instances. The waypoint server system processes the collection of potential proposed POI instances, to render the proposed POI, by: (1) establishing POI ratings for individual ones of the collection of potential proposed POI instances based at least in part upon: the delay factor, and an estimate of additional delay arising from adding the individual POI to the current trip route; (2) establishing a rank ordering of the individual ones of the collection of potential proposed POI instances based upon the POI ratings; and (3) rendering the proposed POI from the rank ordering of the individual ones of the collection of potential proposed POI instances.
Goldberg (US 2015/0006072) discloses A comprehensive system to optimize utilization of transportation resources, including public vehicles such as municipal buses, quasi-public vehicles such as university and corporate campus shuttles, private vehicles, and freight carriers (all participating vehicles collectively, "Transportation Assets") and provide superior, expedient, efficient, and economical transportation options to prospective passengers or cargo items (each, a "Rider"). A central tracking and guidance system (the "Coordination System") will monitor the current itineraries, present locations, capabilities, and operator-designated preferences of Transportation Assets. A Rider seeking transportation will be directed to a point of rendezvous with a Transportation Asset on the basis of computer or smartphone-provided destination and price preference information given by such Rider, and such Rider's mobility. Transportation Asset routing, Rider guidance prior to and during utilization of Transportation Assets, and pricing will be dynamically determined on the basis of the existing itineraries of Transportation Assets, the ability of Riders to travel en route to use of a Transportation Asset, and capacity utilization of Transportation Assets. All participants in the system may dynamically adjust their preferences in response to pricing information, so the system will be continuously optimized.
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 Scott R Jagolinzer whose telephone number is (571)272-4180. The examiner can normally be reached M-Th 8AM - 4PM Eastern.
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, Christian Chace can be reached at (571)272-4190. 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.
Scott R. Jagolinzer
Examiner
Art Unit 3665
/S.R.J./Examiner, Art Unit 3665 /CHRISTIAN CHACE/Supervisory Patent Examiner, Art Unit 3665