DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/09/2025 and 4/3/2026 has been entered.
Status of Claims
This office action is in response to applicant’s amendments to application number 18/312,876 filed on 4/3/2026, in which Claims 1-20 are presented for examination. The applicant amends Claims 1, 3, 6-9, 11-12, 14, and 17-20 and cancels Claims 4 and 15.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 5/5/2023 has been received and considered.
Response to Arguments
Applicant’s amendments and arguments, see pgs. 2-5 and 7, filed 4/3/2026, with respect to the objection to Claim 18 have been fully considered and are persuasive. The objection of 1/9/2026 has been withdrawn.
Applicant’s amendments and arguments, see pgs. 2-5 and 7, filed 4/3/2026, with respect to the rejection of Claims 6 and 17 under 35 U.S.C. 112(b) have been fully considered and are persuasive. The of 1/9/2026 has been withdrawn.
Applicant’s amendments and arguments, see pgs. 2-5 and 7-8, filed 4/3/2026, with respect to the rejections of Claims 1- under 35 U.S.C. 103 have been considered but are moot because they are directed towards the amendments in Claims 1 and 12. In light of the amendments, the interpretation of Claim 1 changes from including “activating a security response that includes disabling a security feature in response to the exit of the occupant” to only “disabling a security feature in response to an exit of the occupant,” where the disabling a security feature is no longer triggered by “activating a security response” and instead is a direct result of the detection that an occupant has exited the vehicle. Additionally, disabling the security feature is further defined by the amendments by broadly reciting a set of possible actions, including “allowing access to control over the vehicle, allowing locking or unlocking without authorization data or identification data, or allowing remote operation of the vehicle.” Therefore, in light of the amendments and this new interpretation, Examiner provides an updated rejection for Claims 1-3, 5-14, and 16-20 under 35 U.S.C. 103. Further details are provided 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.
Claims 1-2, 5, 11-13, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Ito et al, PG Pub US-2021/0026345-A1 (herein "Ito") in view of Nix et al., PG Pub US-2019/0064806-A1 (herein "Nix").
Regarding Claim 1, Ito discloses: (Currently Amended) A method comprising: receiving identification data of an object outside of a vehicle from an identification recognition unit. See [Ito, FIG. 9 and pg. 5, paras 0083-0084], which explain that a parent, or other user, inputs their data and a request for pickup of another person, or object, “[…] the portable terminal 14 in the possession of the user receives operation from the user. […] the user starts up an application preinstalled in the portable terminal 14, inputs personal information […], and attaches an image of their face. The user then presses a register button […] to complete receipt of the operation. [… and] transmits the personal information […] to the processing server 18.”
Ito further discloses: acquiring authorization data associated with an occupant in the vehicle. See [Ito, FIG. 11 and pg. 7, paras 0110-0114 and 0116], which explains that the occupant is authorized based on matching identification codes, “[0110] […] The user in the possession of the portable terminal 14 and the person outside the vehicle 12 are thereby able to converse. [0111][…] the CPU 20A acquires an authentication code from the unlocking terminal 15 through the communication I/F 20E. [0112] […] the CPU 20A performs a comparison to determine whether or not the authentication code acquired from the unlocking terminal 15 matches the unique authentication code of the vehicle 12 that is pre-stored in the storage 20D […]. […] the CPU 20A determines that the acquired authentication code matches the unique authentication code of the vehicle 12. [… or] the CPU 20A determines that the acquired authentication code does not match the unique authentication code of the vehicle 12. [0113] […] the CPU 20A operates the door locking device 36 to unlock the side door 82. [… which] be opened and closed to allow a passenger to board […]. [0114] […] the CPU 20A issues an error report indicating that authentication has failed. […] such as "The authentication code does not match" on the second display 32B, and outputs an alarm sound through the speaker 32C. […] [0116] […] the CPU 20A transmits information indicating that unlocking was unsuccessful to the portable terminal 14. The user in the possession of the portable terminal 14 is thereby made aware that passenger boarding […] was not possible.”
Ito further discloses: controlling a locking mechanism of a door of the vehicle based on an authorization of the object, wherein the authorization of the object is based on the identification data and the authorization data, wherein the controlling comprises unlocking the door when the object is authorized, and locking or keeping the door locked based on the object being unauthorized. See again [Ito, FIG. 9 and pg. 5, paras 0083-0084], which explains that a parent, or other user, inputs their data and a request for pickup of another person, or object. See also [Ito, FIG. 12 and pg. 8, paras 0126, 0129-0130, and 132], which explains the verification of the user based on the previously provided image, associated with the pick-up, or drop-off, request, “[126] The authentication section 280 […] determines authentication to be successful in cases in which a facial image of the person outside the vehicle acquired in advance from the unlocking terminal 15 matches an image captured by the camera 24A. […] [0129] […] the CPU 20A captures an image of a person outside the vehicle near to the side door 82 using the camera 24A. [0130] [… and] performs a comparison to determine whether or not the facial image acquired from the unlocking terminal 15 matches the facial image included in the captured image as a result of authentication processing. […] the CPU 20A determines that the acquired facial image matches the captured facial image. [… or] determines that the acquired facial image does not match the captured facial image. […] [0132] […] the present exemplary embodiment performs unlocking based on facial authentication […]. Also see again [Ito, FIG. 11 and pg. 7, paras 0112-0113 and 0116], which explains that the door is unlocked when the user is authorized based on matching identification codes. Also see [Ito, pg. 1, paras 0013-0014], which explains the locking and unlocking based on authentication, “[0013] […] a locking section configured to lock and unlock the door section, and an authentication section configured to perform authentication to cause the locking section to perform unlocking based on information from outside the vehicle. [0014] […] the door section locked by the locking section is configured capable of being unlocked on the basis of authentication by the authentication section.” Also see [Ito, pg. 3, para 0050], which explains that the door locking device can lock and unlock the side door, "The door locking device 36 serves as a locking section, and is capable of locking and unlocking the side door 82, serving as a door section. The door locking device 36 includes a locking mechanism for locking the side door 82 and an actuator to drive the locking mechanism. Being "locked" by the door locking device 36 refers to a state in which the side door 82 is locked, and being "unlocked" by the door locking device 36 refers to a state in which the side door 82 is unlocked." Also see [Ito, pg. 4, para 0060], which further explains the authentication steps and the resulting unlocking, “The authentication section 280 includes functionality to perform authentication to unlock the side door 82. In the present exemplary embodiment, the authentication section 280 determines authentication to be successful in cases in which an authentication code acquired from the unlocking terminal 15 matches the authentication code stored in the ROM 20B or the storage 20D. The authentication section 280 operates the door locking device 36 to unlock the side door 82 in cases in which authentication has been determined to be successful. This enables a person outside the vehicle to open and close the side door 82.” Finally see [Ito, pg. 7, para 0123], which explains that that the door is locked door prior to being unlocked in response to authentication, "In the vehicle 12 of the present exemplary embodiment, the side door 82 locked by the door locking device 36 can be unlocked by performing authentication with the authentication section 280. The present exemplary embodiment thereby enables boarding of a passenger unconnected to the user or loading of a package unconnected to the user to be prevented."
Ito does not disclose: detecting by the identification recognition unit, an exit of the occupant from the vehicle; and , wherein disabling the security feature comprises one or more of allowing access to control over the vehicle, allowing locking or unlocking without authorization data or identification data, or allowing remote operation of the vehicle.
However, Nix teaches: detecting by the identification recognition unit, an exit of the occupant from the vehicle; and , wherein disabling the security feature comprises one or more of allowing access to control over the vehicle, allowing locking or unlocking without authorization data or identification data, or allowing remote operation of the vehicle. See [Nix, pgs. 3-4, paras 0028-0030], which explains that the autonomous vehicle can use sensors, such as a pressure sensor, door sensor, or a motion sensor, and computing system for detecting that passengers have exited the vehicle and the service is complete, “[0028] […]. […] the autonomous vehicle can process sensor data from sensor(s) onboard the vehicle to identify or more release signal(s), and generate release signal data indicative of the release signal(s). […]. The release signal(s) can include, for example, a sensor reading (e.g., motion, pressure, trigger, etc.), an action of a user associated with the vehicle service, an event or condition in a surrounding environment, an instruction from a remote computing system (e.g., operations computing system, user computing system, etc.), and/or other signal(s) that can indicate when a vehicle service is complete. The release signal data can include, for example, data representing a number of passengers that entered the autonomous vehicle, an identifier of a pressure sensor that is triggered, an identifier of a door sensor that is triggered, a motion detected inside the autonomous vehicle, an identifier of a person or object inside the autonomous vehicle (e.g., visual profile, heat signature, detected motion, user computing system, etc.), a proximity of a user to the autonomous vehicle, etc. [0029] […]. For example, if the release signal data indicates that two passengers (e.g., a user and a companion) entered an autonomous vehicle at a starting location, then the autonomous vehicle can determine that the vehicle service is complete after two passengers exit the autonomous vehicle at the ending location. As another example, if the release signal data indicates that pressure sensors in three seats are activated, then the autonomous vehicle can determine that the vehicle service is complete after the pressure sensors in the three seats are deactivated. […]. As yet another example, if the release signal data indicates motion inside the autonomous vehicle (e.g., caused by motion of passengers exiting), then the autonomous vehicle can determine that the vehicle service is complete after the motion stops.” See also [Nix, pg. 2, para 0019] after the user exits the user's controls are released and the control is returned to the autonomous vehicle and the vehicle drives away, “The autonomous vehicle can navigate to the ending location, where the autonomous vehicle can park to allow the user to unlock a cabin door and exit the vehicle. After the user exits, the autonomous vehicle can determine that the vehicle service is complete, release the user's control, and drive away.” See again [Nix, pgs. 3-4, paras 0028-0029], which also explain that the upon completion of the service, the system releases the user’s control, where the user’s control includes a limited control of the vehicle, “[0028] According to an aspect of the present disclosure, the selected autonomous vehicle can provide a user associated with the vehicle service with a limited control over the autonomous vehicle. When the autonomous vehicle provides the limited control to the user, the autonomous vehicle can process sensor data from sensor(s) onboard the vehicle to identify or more release signal(s), and generate release signal data indicative of the release signal(s). […]. [0029] […]. When the autonomous vehicle determines that the vehicle service is complete, the autonomous vehicle can release a user's control and drive away,” where [Nix, pg. 8, para 0069], the limited control allows the user to control the vehicle, “[0069] At (503), the method 500 can include providing limited control to a user associated with the vehicle service. For example, the vehicle computing system 100 into can provide a control of the vehicle 104 to the user 101 associated with the vehicle service. In some implementations, the vehicle computing system 102 can provide the control of the vehicle 104 when the vehicle 104 is at the starting location.” See also [Nix, pg. 3, para 0024], which explains that the autonomous vehicle can also be equipped for communication with devices remote to the vehicle for monitoring and managing the vehicle, “[0024] More particularly, a service provider (e.g., owner, manager, entity) can use one or more vehicles (e.g., ground-based vehicles) to provide a vehicle service such as a transportation service (e.g., rideshare service) […]. The vehicles can be autonomous vehicles that include various systems and devices configured to control an operation of the vehicle. For example, an autonomous vehicle can include an onboard vehicle computing system for operating the vehicle (e.g., located on or within the autonomous vehicle). […]. Moreover, the autonomous vehicle can be configured to communicate with one or more computing devices that are remote from the vehicle. For example, the autonomous vehicle can communicate with an operations computing system that can be associated with the service provider. The operations computing system can help the service provider monitor, communicate with, manage, etc. the fleet of vehicles,” which includes, [Nix, pg. 8, para 0074], a command from a remote computing system to release the user's controls, “[0074] As another example, the vehicle computing system 102 can receive, from a remote computing system 103, an instruction to release control from the user 101. When the vehicle computing system 102 receives the instruction to release control, the vehicle computing system 102 can determine that the vehicle service is complete, and release control of the vehicle 104 from the user 101 in response to the instruction,” or [Nix, pgs. 1-2, para 0018] control by a service provider to select an autonomous vehicle, for example, for a transportation service, “[0018] Example aspects of the present disclosure are directed to an autonomous vehicle that can provide a vehicle service to a user, and in particular, to determining when the vehicle service is complete so that the autonomous vehicle can release the user's control over the autonomous vehicle. The autonomous vehicle can be part of a fleet of vehicles that include, for example, a plurality of autonomous vehicles that can drive, navigate, operate, etc. with minimal and/or no interaction from a human driver. A service provider can use the fleet of vehicles to provide one or more vehicle services (e.g., transportation service […]) […]..” Alternatively, [Nix, pgs. 9-10, para 0085], the autonomous vehicle can be controlled using systems on the vehicle, such as by using the vehicle computing system, “[0085] Computing tasks discussed herein as being performed at computing device(s) remote from the vehicle can instead be performed at the vehicle (e.g., via the vehicle computing system), or vice versa.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Ito with Nix to include detecting the occupant exits the vehicle and disabling a security feature, which can include allowing access to control over the vehicle, allowing locking or unlocking without authorization data or identification data, or allowing remote operation of the vehicle. Doing so allows for providing a subsequent service [Nix, pg. 4, para 0032] and ensuring that the control is safely and efficiently transferred from an previous occupant, back to the vehicle, in preparation for the next service [Nix, pg. 2, para 0023], which also allows for the vehicle, and system, to more efficiently perform autonomous navigation [Nix, pg. 5, para 0035].
Regarding Claim 2, Ito as modified discloses the limitations of Claim 1.
Ito further discloses: (Previously Presented) […] receiving an input of a destination location. See [Ito, pg. 3, para 0055], which explains that the travel plan includes a pre-set destination, “The travel plan generation section 230 includes functionality to generate a travel plan to cause the vehicle 12 to travel based on the position information acquired by the position acquisition section 200, the peripheral information acquired by the peripheral information acquisition section 210, and the vehicle information acquired by the vehicle information acquisition section 220. The travel plan includes not only a travel route to a pre-set destination […].”
Ito further discloses: acquiring a location of the vehicle. See [Ito, FIG.’s 2 and 4 and pg. 3, para 0043], which explains that the GPS device measures the vehicle location, “The GPS device 22 is a device for measuring the current position of the vehicle 12. The GPS device 22 includes an antenna to receive signals from GPS satellites,” and [Ito, pg. 3, para 0052], which further explains that the position acquisition section acquires the vehicle location from the GPS, “The position acquisition section 200 includes functionality to acquire the current position of the vehicle 12. The position acquisition section 200 acquires position information from the GPS device 22 through the input/output I/F 20F.”
Ito further discloses: determining that the location of the vehicle matches the destination location of the vehicle; and unlocking the door of the vehicle in response to determining that the location of the vehicle matches the destination location of the vehicle. See [Ito, pg. 6, para 0097], which explains that after vehicle operation, the vehicle controller device determines that the vehicle has arrived at its destination and proceeds with next steps, “the CPU 20A of the vehicle 12 determines whether or not the vehicle 12 has arrived at the designated dispatch destination. Processing proceeds to the next step S31 in cases in which the vehicle has arrived at the dispatch destination. Note that the CPU 20A may determine the vehicle 12 to have arrived when the vehicle 12 has come within a predetermined range of the dispatch destination.” See also [Ito, FIG. 10] which identifies the next steps (S31 and S34) as the vehicle “presentation and unlocking process.”
Regarding Claim 5, Ito as modified discloses the limitations of Claim 1.
Ito further discloses: (Previously Presented) […] acquiring identification data of the occupant; and acquiring the authorization data associated with the occupant to the vehicle based on the identification data of the occupant. See again [Ito, FIG. 11 and pg. 7, paras 0110-0114 and 0116], which explains that the occupant is authorized based on matching identification codes, where the occupant must provide the authentication code and the unlocking terminal determines if the authentication matches the stored data.
Regarding Claim 11, Ito as modified discloses the limitations of Claim 1.
Ito further discloses: (Currently Amended) […] operating the vehicle to drive autonomously. See [Ito, pg. 1, para 0007], which explains the autonomous capabilities of the vehicle, “The vehicle of the first aspect is capable of implementing autonomous driving and remote driving by the travel control section controlling the travel device. The autonomous driving is travel based on the peripheral information acquired from the peripheral information detection section by the acquisition section and the travel plan generated by the travel plan generation section,” and further [Ito, pg. 2, para 0034], which identifies the vehicle features that enable autonomous driving, “The vehicle 12 is configured so as to be capable of implementing autonomous driving in which the vehicle 12 travels independently by the vehicle controller device 20 based on a pre-generated travel plan, remote driving based on operation of the remote operation station 16 by a remote driver, and manual driving based on operation by an occupant of the vehicle 12 (namely, a driver).”
Regarding Claim 12, Ito discloses: (Currently Amended) A processing system comprising: a memory comprising computer-executable instructions; and a processor configured to execute the computer-executable instructions and cause the processing system. See [Ito, Abstract], which describes the system components, including a processor and a memory, “A vehicle including: […] and a processor coupled to the memory, the processor being configured to: acquire peripheral information peripheral to a vehicle body from a peripheral information detection section, generate a travel plan based on the peripheral information, and control the travel device so as to perform autonomous driving in which travel is based on the generated travel plan […].” See also [Ito, FIG.'s 2, 5, and 7 and pg. 8, para 0133], which shows the various CPUs, or processors, of the system, “Note that the various processing executed by the CPU 20A, the CPU 40A, and the CPU 60A reading software (programs) in the exemplary embodiments described above may be executed by various processors other than CPUs. Examples of such processors include programmable logic devices (PLDs) such as field-programmable gate arrays (FPGAs) […], or dedicated electrical circuits these being processors such as application specific integrated circuits (ASICs) […]. The various processing may be executed using one of these processors, or may be executed by a combination of two or more processors of the same type or different types to each other […]. A more specific example of a hardware structure of these various processors is electric circuitry combining circuit elements such as semiconductor elements.”
Ito further discloses: receive identification data of an object outside of a vehicle from an identification recognition unit; acquire authorization data associated with an occupant in the vehicle. See again [Ito, FIG. 9 and pg. 5, paras 0083-0084], which explains that a parent, or other user, inputs their data and a request for pickup of another person, or object and [Ito, FIG. 11 and pg. 7, paras 0110-0114 and 116], which explains that the occupant is authorized based on matching identification codes.
Ito further discloses: control a locking mechanism of a door of the vehicle based on an authorization of the object, wherein the authorization of the object is based on the identification data and the authorization data, wherein the controlling comprises unlocking the door when the object is authorized, and locking or keeping the door locked based on the object being unauthorized. See again [Ito, FIG. 9 and pg. 5, paras 0083-0084], which explains that a parent, or other user, inputs their data and a request for pickup of another person, or object and [Ito, FIG. 12 and pg. 8, paras 0126, 0129-0130, and 132], which explains the verification of the user based on the previously provided image, associated with the pick-up, or drop-off, request. Also see again [Ito, FIG. 11 and pg. 7, paras 0112-0113 and 116], which explains that the door is unlocked when the user is authorized based on matching identification codes. Also see [Ito, pg. 1, paras 0013-0014], which explains the locking and unlocking based on authentication. Also see [Ito, pg. 3, para 0050], which explains that the door locking device can lock and unlock the side door. Also see [Ito, pg. 4, para 0060], which further explains the authentication steps and the resulting unlocking. Finally see [Ito, pg. 7, para 0123], which explains that that the door is locked door prior to being unlocked in response to authentication.
Ito does not disclose: detect by the identification recognition unit an exit of the occupant from the vehicle; and disable a security feature of the vehicle in response to the detection of the exit of the occupant, wherein to disable the security feature comprises one or more of allowing access to control over the vehicle, allowing locking or unlocking without authorization data or identification data, or allowing remote operation of the vehicle.
However, Nix teaches: detect by the identification recognition unit an exit of the occupant from the vehicle; and disable a security feature of the vehicle in response to the detection of the exit of the occupant, wherein to disable the security feature comprises one or more of allowing access to control over the vehicle, allowing locking or unlocking without authorization data or identification data, or allowing remote operation of the vehicle. See again [Nix, pgs. 3-4, paras 0028-0030], which explains that the autonomous vehicle can use sensors, such as a pressure sensor, door sensor, or a motion sensor, and computing system for detecting that passengers have exited the vehicle and the service is complete. Also see again [Nix, pg. 2, para 0019] after the user exits the user's controls are released and the control is returned to the autonomous vehicle and the vehicle drives away. Also see again [Nix, pgs. 3-4, paras 0028-0029], which also explain that the upon completion of the service, the system releases the user’s control, where the user’s control includes a limited control of the vehicle, where [Nix, pg. 8, para 0069], the limited control allows the user to control the vehicle. Also see again [Nix, pg. 3, para 0024], which explains that the autonomous vehicle can also be equipped for communication with devices remote to the vehicle for monitoring and managing the vehicle, which includes, [Nix, pg. 8, para 0074], a command from a remote computing system to release the user's controls, or [Nix, pgs. 1-2, para 0018] control by a service provider to select an autonomous vehicle, for example, for a transportation service. Finally see again, alternatively, [Nix, pgs. 9-10, para 0085], the autonomous vehicle can be controlled using systems on the vehicle, such as by using the vehicle computing system.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Ito with Nix to include detecting the occupant exits the vehicle and disabling a security feature, which can include allowing access to control over the vehicle, allowing locking or unlocking without authorization data or identification data, or allowing remote operation of the vehicle. Doing so allows for providing a subsequent service [Nix, pg. 4, para 0032] and ensuring that the control is safely and efficiently transferred from an previous occupant, back to the vehicle, in preparation for the next service [Nix, pg. 2, para 0023], which also allows for the vehicle, and system, to more efficiently perform autonomous navigation [Nix, pg. 5, para 0035].
Regarding Claim 13, Ito as modified discloses the limitations of Claim 12.
Ito further discloses: (Previously Presented) […] wherein the processor is further configured to execute the computer-executable instructions to cause the processing system to: receive an input of a destination location; acquire a location of the vehicle; determine that the location of the vehicle matches the destination location of the vehicle; and unlock the door of the vehicle in response to determining that the location of the vehicle matches the destination location of the vehicle. See again [Ito, pg. 3, para 0055], which explains that the travel plan includes a pre-set destination, [Ito, FIG.’s 2 and 4 and pg. 3, para 0043], which explains that the GPS device measures the vehicle location, and [Ito, pg. 3, para 0052], which further explains that the position acquisition section acquires the vehicle location from the GPS. See again, [Ito, pg. 6, para 0097], which explains that after vehicle operation, the vehicle controller device determines that the vehicle has arrived at its destination and proceeds with next steps and [Ito, FIG. 10] which identifies the next steps (S31 and S34) as the vehicle “presentation and unlocking process.”
Regarding Claim 16, Ito as modified discloses the limitations of Claim 12.
Ito further discloses: (Previously Presented) […] wherein the processor is further configured to execute the computer-executable instructions to cause the processing system to: acquire identification data of the occupant; and acquire the authorization data associated with the occupant to the vehicle based on the identification data of the occupant. See again [Ito, FIG. 11 and pg. 7, paras 0110-0114 and 116], which explains that the occupant is authorized based on matching identification codes, where the occupant must provide the authentication code and the unlocking terminal determines if the authentication matches the stored data.
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Ito in view of Nix, further in view of Eathakota, PG Pub US-2021/0245708-A1 (herein "Eathakota").
Regarding Claim 3, Ito as modified discloses the limitations of Claim 1.
Ito does not disclose: (Currently Amended) […] driving the vehicle to a base location in response to the detecting that the occupant exited the vehicle.
However, Nix teaches: (Currently Amended) […] driving the vehicle […] in response to the detecting that the occupant exited the vehicle. See again [Nix, pgs. 3-4, paras 0028-0030], which explains that the autonomous vehicle can use sensors, such as a pressure sensor, door sensor, or a motion sensor, and computing system for detecting that passengers have exited the vehicle and the service is complete. Also see again [Nix, pg. 2, para 0019] after the user exits the user's controls are released and the control is returned to the autonomous vehicle and the vehicle drive away. Also see again [Nix, pg. 3, para 0024], which explains that the autonomous vehicle can also be equipped for communication with devices remote to the vehicle for monitoring and managing the vehicle, which includes, [Nix, pg. 8, para 0074], a command from a remote computing system to release the user's controls, or [Nix, pgs. 1-2, para 0018] control by a service provider to select an autonomous vehicle, for example, for a transportation service. Alternatively, [Nix, pgs. 9-10, para 0085], the autonomous vehicle can be controlled using systems on the vehicle, such as by using the vehicle computing system.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Ito with Nix to include detecting the occupant exits the vehicle and, in response, driving the vehicle. Doing so allows for providing a subsequent service [Nix, pg. 4, para 0032] and ensuring that the control is safely and efficiently transferred from an previous occupant, back to the vehicle, in preparation for the next service [Nix, pg. 2, para 0023], which also allows for the vehicle, and system, to more efficiently perform autonomous navigation [Nix, pg. 5, para 0035].
However, Eathakota teaches: (Currently Amended) […] driving the vehicle to a base location in response to […] the occupant exited the vehicle. See [Eathakota, pg. 3, para 0040], which explains that when the user confirms they have exited the vehicle, temporary access is ended, and the vehicle is returned to the vehicle lot, “Once the temporary access has expired the key or fob is returned to the keybox 120, and the user exits the vehicle. The user then confirms that the vehicle is empty using the software application 40 and the vehicle autonomously navigates back to the car lot in a "Return Vehicle to Lot" step 250.” See also [Eathakota, pg. 3, Claim 10], which summarizes that the temporary access is ended and the vehicle is returned, “10. The method of claim 1, wherein transporting the vehicle from the user to the storage space subsequent to the user's access comprises providing the user with a confirmation that the user is ending the temporary access.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to have modified Ito with Eathakota to include ensuring that an occupant has exited the vehicle and returning the vehicle to a lot. Doing so provides the user with only temporary access to a vehicle, which is ideal for test drives and rental cars [Eathakota, pg. 1, para 0003] that are stored at other locations, allowing the vehicles to be sent from the storage location to the user [Eathakota, pg. 1, para 0004] temporarily, and returned once the user is done [Eathakota, pg. 1, para 0015].
Regarding Claim 14, Ito as modified discloses the limitations of Claim 12.
Ito does not disclose: (Currently Amended) […] wherein the processor is further configured to execute the computer-executable instructions to cause the processing system to[[:]] drive the vehicle to a base location in response to determining that the occupant exited the vehicle.
However, Nix teaches: (Currently Amended) […] drive the vehicle […] in response to determining that the occupant exited the vehicle. See again [Nix, pgs. 3-4, paras 0028-0030], which explains that the autonomous vehicle can use sensors, such as a pressure sensor, door sensor, or a motion sensor, and computing system for detecting that passengers have exited the vehicle and the service is complete. Also see again [Nix, pg. 2, para 0019] after the user exits the user's controls are released and the control is returned to the autonomous vehicle and the vehicle drive away. Also see again [Nix, pg. 3, para 0024], which explains that the autonomous vehicle can also be equipped for communication with devices remote to the vehicle for monitoring and managing the vehicle, which includes, [Nix, pg. 8, para 0074], a command from a remote computing system to release the user's controls, or [Nix, pgs. 1-2, para 0018] control by a service provider to select an autonomous vehicle, for example, for a transportation service. Alternatively, [Nix, pgs. 9-10, para 0085], the autonomous vehicle can be controlled using systems on the vehicle, such as by using the vehicle computing system.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Ito with Nix to include detecting the occupant exits the vehicle and, in response, driving the vehicle. Doing so allows for providing a subsequent service [Nix, pg. 4, para 0032] and ensuring that the control is safely and efficiently transferred from an previous occupant, back to the vehicle, in preparation for the next service [Nix, pg. 2, para 0023], which also allows for the vehicle, and system, to more efficiently perform autonomous navigation [Nix, pg. 5, para 0035].
However, Eathakota teaches: (Currently Amended) […] wherein the processor is further configured to execute the computer-executable instructions to cause the processing system to[[:]] drive the vehicle to a base location in response to [… determining] the occupant exited the vehicle. See again [Eathakota, pg. 3, para 0040], which explains that the user confirms they have exited the vehicle and temporary access is ended and the vehicle is returned to the vehicle lot. See also [Eathakota, pg. 3, Claim 10], which summarizes that the temporary access is ended and the vehicle is returned.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to have modified Ito with Eathakota to include ensuring that an occupant has exited the vehicle and returning the vehicle to a lot. Doing so provides the user with only temporary access to a vehicle, which is ideal for test drives and rental cars [Eathakota, pg. 1, para 0003] that are stored at other locations, allowing the vehicles to be sent from the storage location to the user [Eathakota, pg. 1, para 0004] temporarily, and returned once the user is done [Eathakota, pg. 1, para 0015].
Claims 6 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Ito in view of Nix, further in view of Gordon et al., Patent No. US-10,363,893-B2 (herein “Gordon”).
Regarding Claim 6, Ito as modified discloses the limitations of Claim 1.
Ito further discloses: (Currently Amended) […] wherein the detecting of the unauthorized attempt […] by the object is based on the identification . See again, [Ito, FIG. 11 and pg. 7, paras 0112-0114], which explains that the vehicle checks the authentication and provides a notification of a failed authorization.
Ito does not explicitly disclose: attempt to open the door of the vehicle.
However, Gordon teaches: attempt to open the door of the vehicle. See again [Gordon, col 12, lines 1-15], which explains that the vehicle can detect the door handle being pulled by an unauthorized person, "sensors on the SDV may determine than an unauthorized person is pulling the handle of a passenger door, attempting to open the trunk, pushing or knocking at the window, utilizing a tool to force a lock open, etc., which may indicate an attempt at theft of the SDV."
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to have modified Ito with Gordon to include detecting an attempt to open the door handle by an unauthorized person. Doing so would allow the vehicle to stop an attempt where the user does not just approach the vehicle, but is attempting to get inside, steal from, or damage the vehicle, and further prevent access of the unauthorized person [Gordon, col 12, lines 1-15].
Regarding Claim 17, Ito as modified discloses the limitations of Claim 12.
Ito further discloses: (Currently Amended) […] wherein to detect the unauthorized attempt […] by the object is based on the identification data . See again, [Ito, FIG. 11 and pg. 7, paras 0112-0114], which explains that the vehicle checks the user input authentication to detect an authorized, or unauthorized, attempt and provides a notification of a failed authorization.
Ito does not explicitly disclose: attempt to open the door of the vehicle.
However, Gordon teaches: attempt to open the door of the vehicle. See [Gordon, col 12, lines 1-15], which explains that the vehicle can detect the door handle being pulled by an unauthorized person.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to have modified Ito with Gordon to include detecting an attempt to open the door handle by an unauthorized person. Doing so would allow the vehicle to stop an attempt where the user does not just approach the vehicle, but is attempting to get inside, steal from, or damage the vehicle, and further prevent access of the unauthorized person [Gordon, col 12, lines 1-15].
Claims 7, 9, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ito in view of Nix, further in view of Huang et al., US-11,099,558-B2 (herein "Huang").
Regarding Claim 7, Ito as modified discloses the limitations of Claim 1.
Ito does not disclose: (Currently Amended) […] allowing remote control of the vehicle in response to a triggering event.
However, Huang teaches: (Currently Amended) […] allowing remote control of the vehicle in response to a triggering event. See [Huang, col 2, lines 20-43], which explain that the vehicle can be remotely controlled, “a remote operator […] may have at least partial control of the vehicle or other object […], and may provide controls for the vehicle or other object using a remote control system.” See [Huang, FIG. 3A], which shows B302, the step to determine that a transfer to remote control is required. See also [Huang, col 4-5, lines 45-67 and 1-15], which describes the transfer determination step, “[…] a remote operator may be transferred at least partial control of the vehicle or other object in response to a determination (e.g., by the autonomous vehicle or other object) that the vehicle or object cannot or should not (e.g., based on rules, conditions, constraints, etc.) navigate a situation or environment (e.g., debris blocking a safe path, rules of the road prevent the vehicle from proceeding a certain way, a dangerous condition has presented itself, such as a fallen tree or power line, etc.). See also, [Huang, col 8, lines 12-26], which further describes the transfer determination step, “However, in the current autonomous vehicle control system 100, the vehicle 102 may determine, in response to encountering the situation represented in the image 146, to transfer 15 at least partial control to the remote control system 106. In other examples, the determination to transfer the control of the vehicle 102 (e.g., to initiate a remote control session) may be made by the remote operator (or otherwise may be made at the remote control system 106); by a passenger of 20 the vehicle 102 (e.g., using a command or signal, such as a voice command, an input to a user interface element, a selection of a physical button, etc.); and/or by another actor. For example, sensor data may be analyzed at the remote control system 106 (and/or by another system remote from the vehicle 102) and may be used to determine whether a remote control session should be initiated.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Ito with Huang to include allowing remote control of the vehicle, in response to a trigger. Doing so would allow the vehicle to be safely operated in scenarios where autonomous control is not safe [Huang, col 1, lines 17-24] or provide an option when there is no driver or driver controls, such as an autonomous robo-taxi [Huang, col 1, lines 35-41].
Regarding Claim 9, Ito as modified discloses the limitations of Claim 7.
Ito as modified does not disclose: (Currently Amended) […] creating a digital twin based on image data from the vehicle to provide augmented control of the vehicle.
However, Huang teaches: (Currently Amended) […] creating a digital twin based on image data from the vehicle to provide augmented control of the vehicle. See [Huang, col 2, lines 20-43], which explains that the vehicle sensor data can be used to render a virtual vehicle and environment, “Sensor data from the vehicle or other object may be sent from the vehicle or the other object to the remote control system, and the remote control system may generate and render a virtual environment for display using a VR system (e.g., on a display of a VR headset). The remote operator (e.g., a human, a robot, etc.) may provide controls to a control component(s) of the remote control system to control a virtual representation of the vehicle or other object in the virtual environment. The controls from the remote control system may then be sent […] to the vehicle or other object, and the vehicle or other object may execute controls that are based on the controls from the remote control system.” See [Huang, col 4-5, lines 45-67 and 1-15], which explains that the sensor data includes image data, “Sensor data (e.g., from cameras, LIDAR sensors, RADAR sensors, microphones, etc.) representative of fields of view of the sensors of the vehicle or object may be generated and transmitted to a control system (e.g., the system used by the remote operator).” And finally see [Huang, col 5, lines 62-64], which explains that the virtual vehicle and environment can be used by the remote operator to control the vehicle, “The remote operator may use a view of the virtual environment and/or the control components of the control system to control the vehicle in the physical environment,” [Huang, col 9, lines 23-48] using a remote control, augmented reality, system, “The remote control system 106 may include a virtual environment generator 114, a VR headset 116, and a remote control(s) 118. The virtual environment generator 114 may use the sensor data, the vehicle state data, and/or the calibration data to generate a virtual environment that may represent the environment […] in the field(s) of view of the sensor(s) 110 of the vehicle 102 […], as well as represent at least a portion of the vehicle 102 […] and/or controls of the vehicle 102 35 […]. In some examples, the virtual environment may include virtual representations of portions of the vehicle 102 that may not be visible to a driver or passenger of the vehicle 102 in the real-world environment […].”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to have modified Ito with Huang to include augmented control for the remote operator. Doing so would allow the remote operator to fully immerse in the vehicle operation, giving the operator an intuitive, natural sense of the environment and controls, and providing safer operation, which cannot be done with 2D formats [Huang, col 1, lines 52-63].
Regarding Claim 18, Ito as modified discloses the limitations of Claim 12.
Ito does not disclose: (Currently Amended) […] wherein the processor is further configured to execute the computer-executable instructions to cause the processing system to[[::]] allow remote control of the vehicle in response to a triggering event.
However, Huang teaches: (Currently Amended) […] wherein the processor is further configured to execute the computer-executable instructions to cause the processing system to[[::]] allow remote control of the vehicle in response to a triggering event. See [Huang, col 2, lines 20-43], which explains that the vehicle can be remotely controlled. See also [Huang, col 4-5, lines 45-67 and 1-15], which describes the transfer determination step can include triggers such as vehicle environment. See also, [Huang, col 8, lines 12-26], which further describes the transfer determination step can be made based on the situation, the operator, the passenger, or sensor data.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Ito with Huang to include allowing remote control of the vehicle, in response to a trigger. Doing so would allow the vehicle to be safely operated in scenarios where autonomous control is not safe [Huang, col 1, lines 17-24] or providing an option when there is no driver or driver controls, such as an autonomous robo-taxi [Huang, col 1, lines 35-41].
Regarding Claim 20, Ito as modified discloses the limitations of Claim 18.
Ito as modified does not disclose: (Currently Amended) […] wherein the processor is further configured to execute the computer-executable instructions to cause the processing system to create a digital twin based on image data from the vehicle to provide augmented control of the vehicle.
However, Huang teaches: (Currently Amended) […] wherein the processor is further configured to execute the computer-executable instructions to cause the processing system to create a digital twin based on image data from the vehicle to provide augmented control of the vehicle. See [Huang, col 2, lines 20-43], which explains that the vehicle sensor data can be used to render a virtual vehicle and environment and [Huang, col 4-5, lines 45-67 and 1-15], which explains that the sensor data includes image data. See [Huang, col 5, lines 62-64], which explains that the virtual vehicle and environment can be used by the remote operator to control the vehicle, [Huang, col 9, lines 23-48] using a remote control system that includes a virtual environment generator, a VR headset, and remote controls.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to have modified Ito with Huang to include augmented control for the remote operator. Doing so would allow the remote operator to fully immerse in the vehicle operation, giving the operator an intuitive, natural sense of the environment and controls, and providing safer operation, which cannot be done with 2D formats [Huang, col 1, lines 52-63].
Claims 8 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Ito in view of Nix and Huang, further in view of Gordon.
Regarding Claim 8, Ito as modified discloses the limitations of Claim 7.
Ito further discloses: (Currently Amended) […] the triggering event includes an unauthorized attempt […] by the object when the object is not authorized to pick up the occupant detected based on the identification data and the authorization data. See again, [Ito, FIG. 11 and pg. 7, paras 0112-0114], which explains that the vehicle checks the user-input authentication to detect an authorized, or unauthorized, attempt and provides a notification of a failed authorization.
Ito does not explicitly disclose: attempt to open the door of the vehicle.
However, Gordon teaches: attempt to open the door of the vehicle. See [Gordon, col 12, lines 1-15], which explains that the vehicle can detect the door handle being pulled by an unauthorized person.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to have further modified Ito, as modified by Huang, with Gordon to include detecting an attempt to open the door handle by an unauthorized person. Doing so would allow the vehicle to stop an attempt where the user does not just approach the vehicle, but is attempting to get inside, steal from, or damage the vehicle, and further prevent access of the unauthorized person [Gordon, col 12, lines 1-15].
Regarding Claim 19, Ito as modified discloses the limitations of Claim 18.
Ito further discloses: (Currently Amended) the triggering event includes an unauthorized attempt […] by the object when the object is not authorized to pick up the occupant detected based on the identification data and the authorization data. See again, [Ito, FIG. 11 and pg. 7, paras 0112-0114], which explains that the vehicle checks the user-input authentication to detect an authorized, or unauthorized, attempt and provides a notification of a failed authorization.
Ito does not explicitly disclose: attempt to open the door of the vehicle.
However, Gordon teaches: attempt to open the door of the vehicle. See [Gordon, col 12, lines 1-15], which explains that the vehicle can detect the door handle being pulled by an unauthorized person.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to have further modified Ito, as modified by Huang, with Gordon to include detecting an attempt to open the door handle by an unauthorized person. Doing so would allow the vehicle to stop an attempt where the user does not just approach the vehicle, but is attempting to get inside, steal from, or damage the vehicle, and further prevent access of the unauthorized person [Gordon, col 12, lines 1-15].
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Ito in view of Nix, further in view of Edwards, US-11,042,619-B2 (herein "Edwards").
Regarding Claim 10, Ito as modified discloses the limitations of Claim 1.
Ito does not disclose: (Original) […] the identification data corresponds to a key associated with the authorization data in a blockchain, and the authorization data is generated based on the key.
However, Edwards teaches: (Original) […] the identification data corresponds to a key associated with the authorization data in a blockchain, and the authorization data is generated based on the key. See [Edwards, col 7, lines 5-9], which describes the vehicle has occupant verification system, “The vehicle 200 can include the occupant verification system 260 or capabilities to support or interact with the occupant verification system 260 […].” See also [Edwards, col 8, lines 3-11], which explains the occupant verification system uses blockchain data to validate identity, “The occupant verification system 260 is more clearly described with reference to FIG. 4. [… and] can include one or more modules which integrate the distributed and immutable nature of a blockchain to evaluate and authenticate occupancy in a vehicle, to validate identity information received with relation to the one or more occupants, to evaluate trustworthiness of said 10 occupants, and/or forward to one or more modules or systems for authentication of occupant identity and quantity,” and [Edwards, col 8, lines 44-48], which explains that the occupant verification system accesses and verifies the data in the blockchain using a hash “The blocks can receive a verification code, such as a hash. Then, the occupant verification system 260 can forward the block and the verification code to other recipients in the network, for verification and incorporation into the blockchain ledger.” See also [Edwards, cols 9-10, lines 59-67 and 1-2], which explain that occupant identifiers can include various forms of occupant data as part of the identification data, “data as derived from a government issued identification (ID), law enforcement reports or other government interactions, self-reported information […], data from associated devices […], or others. In one example, the occupant identifiers can include at least one of the prior vehicle interaction, criminal history, passport, driver's license […], or combinations thereof. The occupant indicator and/or the one or more occupant identifiers can then be stored as part of the identification data 460 […].” And finally see [Edwards, cols 10-11, lines 65-67 and 1-5], which explain that the evaluation module accesses the blockchain data, which includes authenticity data, “The evaluation module 430 can include instructions to reference known information or indicia which are stored in blocks of the blockchain ledger. The blocks can contain authenticity data about one or more of the occupants. The authenticity data can include previously collected and stored information about a variety of vehicles and occupants which have interacted with the occupant verification system 260,” and [Edwards, col 11, lines 20-22] which further explains the evaluation module compares the authenticity data to verify the occupant, “The evaluation module 430 can then compare the occupant identifiers, as described above, to the authenticity data to corroborate the occupant identifiers as presented.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to have modified Ito with Edwards to include using blockchain data to retrieve and generate authorization data. Doing so would add redundancy checks and allow access to previously recorded data [Edwards, cols 10-11, lines 65-67 and 1-5] and shared data [Edwards, col 13, lines 17-27] providing a broader data pool.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Reference F, Schwie et al., PG Pub US-2020/0301414-A1, discusses a safety system for a self-driving vehicle that includes a vehicle management system, which can drive the vehicle to pick up a user based on a schedule and detect riders entering, within, or exiting the vehicle and detect items left behind in the vehicle, and in response to an exit of the rider and an item left in the vehicle, the vehicle can be driven to a cleaning facility.
Reference G, Gerrese et al., PG Pub US-2023/0081186-A1, discusses systems and methods for adding supervised stops to an autonomous vehicle route, wherein the vehicle uses sensors to monitor and detect occupants, including detecting that the primary passenger exits the vehicle where the system passes control to the autonomous vehicle or a remote operator to, for example, unlock the door for secondary passengers still in the vehicle.
Reference H, Mohammad et al., PG Pub US-2016/0174010-A1, discusses a system for a vehicle that allows passenger-specific features in a shared space, such as navigation and auditory feedback cues in a vehicle, wherein the vehicle detects and authenticates a passenger to initiate personal settings and safety features and, once the authenticated passenger leaves the vehicle, the personalized features and restricted access, or control, is disabled.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ERIN MARIE HARTMANN whose telephone number is (571)272-5309. The examiner can normally be reached M-F 7-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kito Robinson can be reached at (571) 270-3921. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/E.M.H./ Examiner, Art Unit 3664
/KITO R ROBINSON/ Supervisory Patent Examiner, Art Unit 3664
Prosecution Insights