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 .
Examiner's Note
Examiner has cited particular paragraphs / columns and line numbers or figures in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant, in preparing the responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner. Applicant is reminded that the Examiner is entitled to give the broadest reasonable interpretation to the language of the claims. Furthermore, the Examiner is not limited to Applicants’ definition which is not specifically set forth in the claims.
Claim 13 stands cancelled by Applicant’s amendment dated September 6, 2024.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. § 102 and § 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1-5, 8-10, 14-17, and 19-21 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hicok et al. (US 20190265703 A1).
Regarding claim 1, Hicok discloses a vehicle interaction system to allow passenger interaction with a public transport vehicle, the system including:
a) a processing system; (Hicok: ¶ 159; system includes a central or other dispatch server) b) a passenger client device configured to: (Hicok: ¶ 159; smartphones, tablets, or laptops, able to request and schedule rides from the system.) i) determine a selected vehicle stop in accordance with user input commands; (Hicok: ¶ 170; Mobile device (1000) preferably includes a display map (1031) showing the presence of the traveler (1032) and the local area. TMA preferably allows the user to select the closest stop (pickup location) by providing input such as, for example, touching an area of a display corresponding to a virtual button (1040). The system will identify the closest pickup location and display it on the screen) ii) provide a selected vehicle stop to the processing system; and, (Hicok: ¶ 174; system schedules a shuttle based on the desired number of passengers (1044), departure location (1033), and destination) iii) notify the passenger when the vehicle is approaching the selected vehicle stop; and, (Hicok: ¶ 225; When Shuttle 1 arrives at location B, AI Dispatch may send a notification to Client 1 indicating the arrival of Shuttle) c) a vehicle terminal configured to: (Hicok: ¶ 296; Controller (100) also receives inputs from an instrument cluster (84) and can provide human-perceptible outputs to a human operator via human-machine interface (“HMI”) display(s)) i) receive a selected vehicle stop notification from the processing system; ii) determine when the vehicle is approaching the selected stop by monitoring a current vehicle location; and, iii) in response to a positive determination, at least one of: (1) selectively control at least part of the operation of the vehicle: (Hicok: ¶ 230; Planning and control are used to effectuate the navigation of the vehicle along the planned route by for example actuating steering, braking, propulsion, and other aspects of the vehicle operation in order to cause the vehicle to drive the planned route. An incoming request handler is used to receive incoming requests from new passengers, dynamically generate new routes, optimize those routes, and provide them to the navigation system.) (Hicok: ¶ 230; modify the global routes based on new information including for example new passenger requests, changes in passenger destinations, and dynamic environmental conditions such as traffic. Such functionality is enabled by the development as discussed above of a custom map by the vehicle itself. Dynamic object detection is used both to develop the custom map and to avoid colliding with dynamic objects) and, (2) generate an alert for a vehicle driver. (Hicok: Clm. 45752; safety driver interface application includes a master display screen [which displays] estimated time of arrival at the shuttle's next destination) (Hicok: ¶ 236; Driver UX may include a setting that requires safety driver confirmation in certain scenarios (stop signs, traffic lights, unprotected turns, shuttle stops).)
Regarding claim 2, as detailed above, Hicok teaches the invention as detailed with respect to claim 1. Hicok further teaches:
wherein the vehicle terminal is configured to control at least one: (Hicok: ¶ 160; In-Cabin Client provides multiple interfaces) a) a door opening duration, or opening/closing instruction to the door; (Hicok: ¶ 130; if that person runs up to the door of the vehicle, the sensors may detect this, and the controller may open the door to allow the person to board) (Hicok: ¶ 128; automatically opening the passenger compartment door to allow passengers to enter and exit the vehicle.) b) a door opening location; (Hicok: ¶ 130; if that person runs up to the door of the vehicle, the sensors may detect this, and the controller may open the door to allow the person to board) c) a vehicle suspension height; (Hicok: ¶ 128; vehicle may automatically lower the door entrance) d) a vehicle acceleration; (Hicok: ¶ 294; (100) sends command signals to operate vehicle brakes (60) via one or more braking actuators (61), operate steering mechanism via a steering actuator (62), and operate propulsion unit (56) which also receives an accelerator/throttle actuation signal (64).)
e) a vehicle deceleration; (Hicok: ¶ 136; controller would be responsible for both stopping the vehicle) f) a vehicle velocity; (Hicok: ¶ 131; vehicle may automatically adjust speed) g) a vehicle stopping duration; (Hicok: ¶ 129; vehicle may delay moving to the next stop if an additional passenger is running toward the vehicle) . . . i) vehicle lighting; (Hicok: ¶ 134; controller may cause such lights to automatically flash whenever the school bus has stopped) j) vehicle camera; (Hicok: ¶ 127; cameras may then detect that one or more passengers have entered) k) vehicle routing parameters; and, (Hicok: ¶ 231; the vehicle is informed of the desired destination of each passenger, the vehicle is capable of performing route optimization) . . .
Regarding claim 3, as detailed above, Hicok discloses the invention as detailed with respect to claim 1. Hicok further discloses:
a) determine one or more passenger requirements; and b) at least partially control the vehicle in accordance with the passenger requirements. (Hicok: ¶ 128; vehicle detects a special needs person, the vehicle may automatically lower the door entrance and if necessary, to deploy a ramp (e.g., to accommodate a wheelchair))
Regarding claim 4, as detailed above, Hicok discloses the invention as detailed with respect to claim 3. Hicok further discloses:
determine the passenger requirements in accordance with a requirements indication from the processing system. (Hicok: ¶ 128; vehicle detects a special needs person, the vehicle may automatically lower the door entrance and if necessary, to deploy a ramp (e.g., to accommodate a wheelchair))
Regarding claim 5, as detailed above, Hicok discloses the invention as detailed with respect to claim 1. Hicok further discloses:
a) obtain a list of available vehicle stops from the processing system; b) present the list of available vehicle stops to the passenger; and, c) determine a selected stop in accordance with user input commands. (Hicok: ¶ 170; Mobile device (1000) preferably includes a display map (1031) showing the presence of the traveler (1032) and the local area. TMA preferably allows the user to select the closest stop (pickup location) by providing input such as, for example, touching an area of a display corresponding to a virtual button (1040). The system will identify the closest pickup location and display it on the screen)
Regarding claim 8, as detailed above, Hicok discloses the invention as detailed with respect to claim 1. Hicok further discloses:
wherein the passenger client device is configured to: a) determine a passenger location; and, (Hicok: ¶ 229; application may include a GPS or other geolocator that transmits the coordinates or other identifying information corresponding to the current location of the passenger.) b) obtain a list of available vehicle stops from the processing system using the passenger location. (Hicok: ¶ 170; Mobile device (1000) preferably includes a display map (1031) showing the presence of the traveler (1032) and the local area. TMA preferably allows the user to select the closest stop (pickup location) by providing input such as, for example, touching an area of a display corresponding to a virtual button (1040). The system will identify the closest pickup location and display it on the screen)
Regarding claim 9, as detailed above, Hicok discloses the invention as detailed with respect to claim 8. Hicok further discloses:
a) receive a passenger location indication from the passenger client device; and, (Hicok: ¶ 229; application may include a GPS or other geolocator that transmits the coordinates or other identifying information corresponding to the current location of the passenger.) b) determine available vehicle stops at least in part using the passenger location. (Hicok: ¶ 170; Mobile device (1000) preferably includes a display map (1031) showing the presence of the traveler (1032) and the local area. TMA preferably allows the user to select the closest stop (pickup location) by providing input such as, for example, touching an area of a display corresponding to a virtual button (1040). The system will identify the closest pickup location and display it on the screen)
Regarding claim 10, as detailed above, Hicok discloses the invention as detailed with respect to claim 1. Hicok further discloses:
wherein the processing system is configured to: a) determine vehicle routing information; and, (Hicok: ¶ 188; system schedules a shuttle based on the desired number of passengers (2044), departure location (2033), and destination) b) provide an indication of the vehicle routing information to the passenger client device. (Hicok: ¶ 192; system also preferably notifies the user's mobile device (1000) via text when the ride is some threshold time (e.g., 15 minutes) or distance away) (Hicok: ¶ 189; mobile device preferably displays the estimated pickup time (2034) at the pickup location (2033), as well as a planned travel route)
Regarding claim 14, as detailed above, Hicok discloses the invention as detailed with respect to claim 1. Hicok further discloses:
in response to a positive determination, the vehicle terminal is configured to provide a vehicle approaching indication to at least one of: a) the processing system; and, (Hicok: ¶ 194; Manager Client (4000) includes a Status Map tab (4020), which displays a map (4031) of all shuttles in an area selected) b) the passenger client device. (Hicok: ¶ 225; When Shuttle 1 arrives at location B, AI Dispatch may send a notification to Client 1 indicating the arrival of Shuttle)
Regarding claim 15, as detailed above, Hicok discloses the invention as detailed with respect to claim 1. Hicok further discloses:
the processing system is configured to: a) receive a vehicle approaching indication from the vehicle terminal when the vehicle is approaching a selected stop; and, (Hicok: ¶ 194; Manager Client (4000) includes a Status Map tab (4020), which displays a map (4031) of all shuttles in an area selected) b) provide a vehicle approaching notification to the passenger client device. (Hicok: ¶ 177; system also preferably notifies the mobile device (1000) via text when the ride is a (configurably) specified time (e.g., 15 minutes, 5 minutes, etc.) away,)
Regarding claim 16, as detailed above, Hicok discloses the invention as detailed with respect to claim 1. Hicok further discloses:
the vehicle terminal is configured to: a) determine if a passenger is or has completed boarding or departing the vehicle; and, b) in response to a positive boarding or departing determination, at least one of: i) generate an alert for a vehicle driver; and, ii) selectively control at least part of the operation of the vehicle. (Hicok: ¶ 130; interior facing sensors observe the newly boarded passenger and wait until she is seated safely before controlling the vehicle to begin moving.)
Regarding claim 17, as detailed above, Hicok discloses the invention as detailed with respect to claim 1. Hicok further discloses:
the passenger client device is configured to: a) determine if a passenger is or has completed boarding or departing (Hicok: ¶ 229; mobile application may include a GPS or other geolocator that transmits the coordinates or other identifying information corresponding to the current location of the passenger. . . route planner uses such optimization to generate the route based on the passengers that are currently on board the vehicle) in accordance with user input commands; and, (Hicok: ¶ 231; passenger may have hailed the vehicle using a mobile application that specifies the passenger's pick-up location as well as the passenger's desired destination location. In usage contexts in which the vehicle is informed of the desired destination of each passenger, the vehicle is capable of performing route optimization to most efficiently get each of the passengers to their desired destination.) b) provide a passenger boarding or departing notification to at least one of: i) the vehicle terminal; and, (Hicok: ¶ 032; able to detect, based on perception of the passenger, whether the passenger needs a reminder (e.g., the passenger is about to miss their stop because they are paying too much attention to a phone screen)) ii) the processing system. (Hicok: ¶ 229; route planner uses such optimization to generate the route based on the passengers that are currently on board the vehicle, the ones that need to be picked up, and the ones that need to be discharged. The resulting new global route is then implemented, and the vehicle dynamically navigates along the new route.)
Regarding claim 19, as detailed above, Hicok discloses the invention as detailed with respect to claim 1. Hicok further discloses:
the selected stop is at least one of: a) a boarding stop; and, b) a destination stop. (Hicok: ¶ 129; vehicle may have already permitted all passengers to disembark at a particular stop and may have already picked up all passengers who are waiting at the stop)
Regarding claim 20, as detailed above, Hicok discloses the invention as detailed with respect to claim 1. Hicok further discloses:
wherein the vehicle terminal is configured to control at least part of the operation of the vehicle by sending control instructions to a vehicle control system. (Hicok: ¶ 230; Planning and control are used to effectuate the navigation of the vehicle along the planned route by for example actuating steering, braking, propulsion, and other aspects of the vehicle operation in order to cause the vehicle to drive the planned route. An incoming request handler is used to receive incoming requests from new passengers, dynamically generate new routes, optimize those routes, and provide them to the navigation system.)
Regarding claim 21, Hicok discloses a vehicle interaction method to allow passenger interaction with a public transport vehicle, the method including:
a) in a passenger client device: (Hicok: ¶ 159; smartphones, tablets, or laptops, able to request and schedule rides from the system.) i) determining a selected vehicle stop in accordance with user input commands; (Hicok: ¶ 170; Mobile device (1000) preferably includes a display map (1031) showing the presence of the traveler (1032) and the local area. TMA preferably allows the user to select the closest stop (pickup location) by providing input such as, for example, touching an area of a display corresponding to a virtual button (1040). The system will identify the closest pickup location and display it on the screen) ii) providing a selected vehicle stop to a processing system; and, (Hicok: ¶ 174; system schedules a shuttle based on the desired number of passengers (1044), departure location (1033), and destination)
iii) notifying the passenger when the vehicle is approaching the selected vehicle stop; and, (Hicok: ¶ 225; When Shuttle 1 arrives at location B, AI Dispatch may send a notification to Client 1 indicating the arrival of Shuttle) b) in a vehicle terminal: (Hicok: ¶ 296; Controller (100) also receives inputs from an instrument cluster (84) and can provide human-perceptible outputs to a human operator via human-machine interface (“HMI”) display(s)) i) receiving a selected vehicle stop notification from the processing system; ii) determining when the vehicle is approaching the selected stop by monitoring a current vehicle location; and, iii) in response to a positive determination at least one of: (1) selectively controlling at least part of the operation of the vehicle: (Hicok: ¶ 230; Planning and control are used to effectuate the navigation of the vehicle along the planned route by for example actuating steering, braking, propulsion, and other aspects of the vehicle operation in order to cause the vehicle to drive the planned route. An incoming request handler is used to receive incoming requests from new passengers, dynamically generate new routes, optimize those routes, and provide them to the navigation system.) (Hicok: ¶ 230; modify the global routes based on new information including for example new passenger requests, changes in passenger destinations, and dynamic environmental conditions such as traffic. Such functionality is enabled by the development as discussed above of a custom map by the vehicle itself. Dynamic object detection is used both to develop the custom map and to avoid colliding with dynamic objects. T) and,(2) generate an alert for a vehicle driver. (Hicok: Clm. 45752; safety driver interface application includes a master display screen [which displays] estimated time of arrival at the shuttle's next destination)
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over Hicok et al. (US 20190265703 A1) as applied to claim 1 above and in view of Rakah et al. (US 20180209803 A1). As regards the individual claims:
Regarding claim 6 as detailed above, Hicok teaches the invention as detailed with respect to claim 5. Hicok does not explicitly teach:
a) determine one or more passenger requirements; and, b) determine available vehicle stops at least in part using the one or more passenger requirements. ; however, Rakah does teach:
a) determine one or more passenger requirements; and, (Rakah: ¶ 393; user preference parameters regarding a vehicle ridesharing service, for example, a maximum walking distance from a starting point to a pick-up location). b) determine available vehicle stops at least in part using the one or more passenger requirements. (Rakah: ¶ 394; determining the driving route may include selecting pick-up locations and drop-off locations for each of the plurality of users . . . When selecting a virtual bus stop, route determination module 2108 may confirm that the pick-up location is within a maximum walking distance (e.g., 300 meters or less) from the starting point, and that the drop-off location is within a maximum walking distance)
Before the effective filling date of the claimed invention, it would have been obvious to one of ordinary skill in the art to combine the teachings of Rakah with the teachings of Hicok because doing so would result in the predicable benefit of "provide an improved user experience for the riders and/or drivers in the ridesharing network." (Rakah: ¶ 322).
Regarding claim 7, as detailed above, Hicok in view of Rakah teaches the invention as detailed with respect to claim 6. Rakah further teaches:
determine one or more passenger requirements based on at least one of: a) a passenger profile; and, (Rakah: ¶ 393; user preference parameters regarding a vehicle ridesharing service, for example, a maximum walking distance from a starting point to a pick-up location) b) an indication of passenger requirements received from the passenger client device. (Rakah: ¶ 425; Ride service parameters may include user preference parameters . . . Ridesharing management server 150 may further be configured to receive user input from user devices (e.g., user devices 120A-120C) as to various ride service parameters)
Claims 11-12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Hicok et al. (US 20190265703 A1) as applied to claims 10, 1, and 1 respectively above, and further in view of Taveira et al. (US 20220204050 A1).
Regarding claim 11, as detailed above, Hicok teaches the invention as detailed with respect to claim 10. Hicok does not explicitly teach:
wherein the passenger client device is configured to: a) obtain vehicle routing information from the processing system; b) present vehicle routing information to the passenger; and, c) determine a selected vehicle route in accordance with user input commands; however, Taveira does teach:
wherein the passenger client device is configured to: a) obtain vehicle routing information from the processing system; b) present vehicle routing information to the passenger; and, c) determine a selected vehicle route in accordance with user input commands. (Taveira: ¶ 125; one or more determined routes may be presented on a display . . . server or network entity may determine the routes to be presented to the passenger . . . a user selection of one of the presented routes (e.g., a user touch input on a corresponding icon or element presented on the display screen) may cause the vehicle to drive to the venue along the route selected).
Before the effective filling date of the claimed invention, it would have been obvious to one of ordinary skill in the art to combine the teachings of Taveira with the teachings of Hicok because doing so would result in the predicable benefit of better managing "unexpected conditions (e.g., traffic jams, hazardous road conditions, sudden weather changes, etc.) [which] preclude the autonomous vehicle from "timely completing a route. (Taveira: ¶ 003).
Regarding claim 12, as detailed above, Hicok teaches the invention as detailed with respect to claim 1. Hicok teaches:
. . . b) at least one of: i) provide the selected vehicle stop notification to the vehicle terminal using the selected vehicle route indication: and, (Hicok: ¶ 236; Driver UX may include a setting that requires safety driver confirmation in certain scenarios (stop signs, traffic lights, unprotected turns, shuttle stops).) i) determine available vehicle stops at least in part using the selected vehicle route. (Hicok: ¶ 224; Client 1 may accept or reject the proposal, cancel the request, or submit a new request. When Client 1 selects a proposal, AI Dispatch notifies Shuttle 1 of the path and the proposed actions. In this case, the actions comprise picking up the requesting passenger, at location B, and dropping off Bob at location X. AI Dispatch sends the <Route for Shuttle 1> to Client1, and shuttle proceeds to location B, possibly making other pickups and drop-offs along the way.)
Hicok does not explicitly teach: wherein the processing system is configured to: a) receive a selected vehicle route indication from the passenger client device; and . . .; however, Taveira does teach:
wherein the processing system is configured to: a) receive a selected vehicle route indication from the passenger client device; and . . . (Taveira: ¶ 125; a user selection of one of the presented routes (e.g., a user touch input on a corresponding icon or element presented on the display screen) may cause the vehicle to drive to the venue along the route selected).
Before the effective filling date of the claimed invention, it would have been obvious to one of ordinary skill in the art to combine the teachings of Taveira with the teachings of Hicok because doing so would result in the predicable benefit of better managing "unexpected conditions (e.g., traffic jams, hazardous road conditions, sudden weather changes, etc.) [which] preclude the autonomous vehicle from" timely completing a route. (Taveira: ¶ 003).
Regarding claim 18, as detailed above, Hicok teaches the invention as detailed with respect to claim 1. Hicok does not explicitly teach:
the system includes vehicle beacons and wherein the passenger client device is configured to communicate using the vehicle beacons with at least one of:; however, Taveira does teach:
the system includes vehicle beacons and wherein the passenger client device is configured to communicate using the vehicle beacons with at least one of: (Taveira: ¶ 071; transceivers 210 may be configured to operate according to . . . Bluetooth). a) the processing system; and, b) the vehicle terminal. (Taveira: ¶ 071; transceivers 210 may facilitate the exchange of communications (such as signals and messages) between the route selection system 200, [and / or] the vehicles 120,)
Before the effective filling date of the claimed invention, it would have been obvious to one of ordinary skill in the art to combine the teachings of Taveira with the teachings of Hicok because doing so would result in the predicable benefit of better managing "unexpected conditions (e.g., traffic jams, hazardous road conditions, sudden weather changes, etc.) [which] preclude the autonomous vehicle from "timely completing a route. (Taveira: ¶ 003).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure Ran (US 20200020227 A1) which discloses a transit management system, which facilitates transit vehicle operations and control for connected automated transit vehicles (CATVs) systems.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES PALL whose telephone number is (571)272-5280. The examiner can normally be reached on M-F 9:30 - 18:30.
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, Angela Ortiz can be reached on 571-272-1206. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.P./ Examiner, Art Unit 3663
/ANGELA Y ORTIZ/Supervisory Patent Examiner, Art Unit 3663