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 .
Reopening of Prosecution after Appeal Brief
In view of the appeal brief filed on September 8, 2025, PROSECUTION IS HEREBY REOPENED. New grounds of rejection are set forth below.
To avoid abandonment of the application, appellant must exercise one of the following two options:
(1) file a reply under 37 CFR 1.111 (if this Office action is non-final) or a reply under 37 CFR 1.113 (if this Office action is final); or,
(2) initiate a new appeal by filing a notice of appeal under 37 CFR 41.31 followed by an appeal brief under 37 CFR 41.37. The previously paid notice of appeal fee and appeal brief fee can be applied to the new appeal. If, however, the appeal fees set forth in 37 CFR 41.20 have been increased since they were previously paid, then appellant must pay the difference between the increased fees and the amount previously paid.
A Supervisory Patent Examiner (SPE) has approved of reopening prosecution by signing below:
Response to Arguments
Applicant’s arguments with respect to claim(s) 1–22 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections – 35 U.S.C. § 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.
Claims 1, 5, 6, 8, 12, 13, 15, 19, and 20 are rejected under 35 U.S.C. § 102(a)(1) as being anticipated by U.S. Patent Application Publication No. 2020/0001890 A1 (“Kline”).
Claim 1
Kline discloses:
A method,
“With reference to FIG. 7, a method of operating one or more autonomous vehicles is provided.” Kline ¶ 43.
implemented by programmed one or more processors in a client terminal, for setting an operational rule of a vehicle, the method comprising:
As will be discussed in greater detail below, the method shown in FIG. 7 is performed using the architecture shown in FIGS. 2–4 (autonomous vehicle system 10), which includes “an operator interface 20” that “is capable of communicating with each of the autonomous vehicles 11 and the remote server 30.” Kline ¶ 27.
Operator interface 20 further includes a display processing unit and a memory with instructions, that, when executed will “generate [a] graphical rule creation interface (GRCI) 201 for viewing and interaction with an operator, to receive the instructions inputted by the operator via the GRCI 201 and to compile the second driving rule set from those received instructions and to upload the second driving rule set to the memory units 111 of each of the autonomous vehicles 11 at the secondary instance.” Kline ¶ 37. Careful readers will observe that these are the same steps described in the method of FIG. 7.
To be clear, the elements of claim 1 correspond to the prior art as follows:
Claim 1
Kline
client terminal
operator interface 20
one or more processors in the client terminal
display processing unit of operator interface 20 (a component of “control element 216”)
operational rule of a vehicle
second driving rule set
vehicle
vehicle 11
one or more components of the vehicle, including an autonomous driving control
units 110–113, which execute autonomous vehicle operation controls in accordance with the second driving rule set
user interface for setting an operational rule
graphical rule creation interface (GRCI) 201
server
remote server 30 or control element 100 (depending on interpretation of “server”)
outputting a user interface
Turning now to the flowchart of FIG. 7, “[t]he method [] includes generating a graphical rule creation interface (GRCI) for an operator that can be displayed to the operator as an augmented reality map overlaid onto the operator's field of view through wearable augmented reality glasses (703).” Kline ¶ 43.
for setting an operational rule for controlling one or more components of a vehicle,
“The operator interface 20 is further configured to receive instructions inputted by the operator via the GRCI 201, to compile the second driving rule set from those received instructions and to upload the second driving rule set to the memory units 111 of each of the autonomous vehicles 11 at a secondary instance.” Kline ¶ 32.
wherein the one or more components includes an autonomous driving control of the vehicle;
“[T]he processing unit 110 [in vehicle 100] executes [] autonomous control such that the autonomous vehicle 11 is operable for driving in accordance with multiple driving rules and regulations including, but not limited to the first driving rule set and the second driving rule set when the second driving rule set is installed or uploaded” to the vehicle from the GRCI. Kline ¶ 31; see also Kline ¶ 29 (describing the individual components 112–114 that processing unit 110 directs to autonomously drive the vehicle).
receiving, via a user input to the user interface, a setting of the operational rule,
Returning to FIG. 7, the method further includes “compiling a second driving rule set, according to which the one or more autonomous vehicles are operable, from instructions inputted by the operator using a stylus, gestures or vocal commands via the GRCI (704).” Kline ¶ 43.
wherein the operational rule assists in avoiding unsafe driving; and
“Such driving rules can include contour drawings that effectively define lanes for the autonomous vehicles to move into so that they divert around the accident or traffic rules, such as speed limits, that insure that the autonomous vehicles move carefully along the lanes defined by the contours.” Kline ¶ 40.
transmitting the received setting to a server to implement the operational rule on the fly via an over-the-air transmission to the vehicle.
“The method also includes uploading the second driving rule set to the memory units [of the vehicle] to supersede the first driving rule set in an event the second driving rule set is acceptable or approved (705).” Kline ¶ 43.
Notably, there are two different ways to interpret the above claim language, and Kline likewise discloses two different ways to implement step 705, each of which anticipates a respective one of the two different claim interpretations.
Under a first, strict/narrow interpretation of “server,” the claimed “server” must be separate and external to both the vehicle and the client terminal. For this, Kline likewise discloses that all communication from operator interface 20 to vehicle 10 is routed through remote server 30, who acts as the intermediary between the two devices. See Kline ¶ 28 and Claim 9.
Under a second, broader (but reasonable) interpretation (given the plain language of the claim), the above claim language encompasses a server installed on the vehicle, such that when we transmit the setting to the vehicle over-the-air, it is received by the vehicle’s server, and then the vehicle’s server causes the vehicle to implement the received setting. For this interpretation, Kline likewise discloses an embodiment where the second driving rule set is “uploaded” from the operator interface 20 to the memory units 111, Kline ¶ 31, which are components of the vehicle’s control element 100 (the claimed server, under this interpretation).
Either way, Kline anticipates each and every element of claim 1.
Claim 5
Kline discloses the method according to claim 1,
wherein the operational rule comprises a condition and a control to be performed based on the condition.
“The first and second driving rule sets can relate to various factors, such as road and traffic conditions, location and destination, speed limits and passenger schedules.” Kline ¶ 31. “Such driving rules can include contour drawings that effectively define lanes for the autonomous vehicles to move into so that they divert around the accident or traffic rules, such as speed limits, that insure that the autonomous vehicles move carefully along the lanes defined by the contours.” Kline ¶ 40.
Claim 6
Kline discloses the method according to claim 5,
wherein the condition comprises at least one of a number of passengers, a location, a distance traveled, a time of travel, a time, a drowsiness detection, and a careless driving detection.
“The first and second driving rule sets can relate to various factors, such as road and traffic conditions, location and destination, speed limits and passenger schedules.” Kline ¶ 31.
Claims 8, 12, and 13
Claims 8, 12, and 13 are directed to a general purpose computer apparatus programmed to perform exactly the same method as recited in claims 1, 5, and 6. Therefore, the findings from those rejections are hereby reincorporated by reference, taken together with Kline’s further disclosure of the computer hardware itself. See Kline ¶¶ 45–50.
Claims 15, 19, and 20
Claims 15, 19, and 20 are directed to a non-transitory computer-readable recording medium having recorded thereon exactly the same instructions that are stored on the memory of the apparatus of claims 8, 12, and 13. Therefore, claims 15, 19, and 20 are rejected over the same findings and rationale as provided above for claims 8, 12, and 13, with the understanding that the additional computer components in those claims (e.g., the processor) simply fall within the open-ended “comprising” scope of claims 15, 19, and 20.
Claim Rejections – 35 U.S.C. § 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 of this title, 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.
I. Kline and Penilla teach claims 2, 3, 9, 10, 16, and 17.
Claims 2, 3, 9, 10, 16, and 17 are rejected under 35 U.S.C. § 103 as being unpatentable over Kline as applied to claims 1, 8, and 15 above, and further in view of U.S. Patent Application Publication No. 2019/0196851 A1 (“Penilla”).
Claim 2
Kline teaches the method according to claim 1, and further teaches that the operator of its user interface is someone with authorization to control the vehicles (a “road traffic officer,” see Kline ¶ 25), but does not explicitly disclose whether or not the user must provide a “successful authentication” in order to display the user interface.
Penilla, however, teaches a method that includes displaying a user interface for setting rules that are transmitted to a vehicle, and further teaches:
the outputting of the user interface comprises outputting the user interface based on a successful authentication of the user.
“The access to the vehicle site may be granted by supplying credentials for accessing a user account, or establishing a new user account.” Penilla ¶ 176.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to improve Kline’s interface, which was already intended for authorized personnel, by protecting it with an authentication method, as taught by Penilla. One would have been motivated to protect Kline’s interface with Penilla’s authentication requirements because this would make the overall system more secure, and free from unauthorized influence.
Claim 3
Kline and Penilla teach the method according to claim 2,
wherein the successful authentication of the user is verified based on one of a login procedure and/or biometric authentication.
“The credentials can include usernames and passwords, keys, alphanumeric entries, biometric inputs, voice inputs, retina scan inputs, fingerprints, face recognition, etc.” Penilla ¶ 144.
Claims 9, 10, 16, and 17
Claims 9 and 10 are directed to a general purpose computer apparatus programmed to perform exactly the same method as recited in claims 2 and 3. Therefore, the findings and rationale from those rejections are hereby reincorporated by reference, taken together with Kline’s further disclosure of the computer hardware itself. See Kline ¶¶ 45–50.
Claims 16 and 17 are directed to a non-transitory computer-readable recording medium having recorded thereon exactly the same instructions that are stored on the memory of the apparatus of claims 9 and 10. Therefore, claims 16 and 17 are rejected over the same findings and rationale as provided above for claims 9 and 10, with the understanding that the additional computer components in those claims (e.g., the processor) simply fall within the open-ended “comprising” scope of claims 16 and 17.
II. Kline and Boyles teach claims 7 and 14.
Claims 7 and 14 are rejected under 35 U.S.C. § 103 as being unpatentable over Kline as applied to claims 1 and 8 above, and further in view of U.S. Patent Application Publication No. 2015/0116114 A1 (“Boyles”).
Claim 7
Kline teaches the method according to claim 5, but does not explicitly disclose whether the server provides a notification whenever the defined conditions are met.
Boyles, however, teaches a server 540 that determines when a vehicle has violated a defined safety rule, and further teaches:
receiving, from the server, a notification of the condition being met.
As shown in FIG. 5, an “event detector 508 declares a safety event” when its vehicle 502 violates a defined safety rule, “and, in response, vehicle alert data 505 is transmitted from the onboard computer system 503 to the server 540,” Boyles ¶ 35, which server 540 subsequently transmits “to a mobile device or other electronic device 560 associated with an authorized recipient of the data.” Boyles ¶ 36.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to improve Kline’s method of defining rules for autonomous vehicles with Boyles’s technique of notifying authorized users when those rules are violated. One would have been motivated to improve Kline with this technique because “[t]imely notification of safety event alerts to individuals responsible for vehicle safety within predetermined regions allows individuals receiving the alerts to take immediate action shortly after the occurrence of an unsafe driving event.” Boyles ¶ 18.
Claim 14
Claims 14 is directed to a general purpose computer apparatus programmed to perform exactly the same method as recited in claim 7. Therefore, the findings and rationale from the rejection of claim 7 are hereby reincorporated by reference, taken together with Kline’s further disclosure of the computer hardware itself. See Kline ¶¶ 45–50.
III. Liffman and Aust teach claims 21 and 22.
Claims 21 and 22 are rejected under 35 U.S.C. § 103 as being unpatentable over U.S. Patent Application Publication No. 2020/0269861 A1 (hereafter “Liffman”) in view of U.S. Patent Application Publication No. 2020/0125355 A1 (hereafter “Aust”).
Claim 21
Liffman teaches:
A system comprising:
“Turning now to FIG. 4, a system 400 for facilitating operationally customized access to smart vehicles will now be described.” Liffman ¶ 47.
a user terminal;
System 400 includes “user devices 420,” one of which is operated by an “owner.” Liffman ¶¶ 47–48.
a server;
System 400 further includes “a policy management server 410.” Liffman ¶ 47.
and a vehicle, wherein:
Lastly, system 400 also includes “smart vehicles 430,” Liffman ¶ 47, one of which is owned by the same “owner” who is operating one of the user devices 420 above. Liffman ¶ 48.
the server is configured to send a notification to the user terminal in response to a vehicle speed of the vehicle exceeding a speed limit or in response to the vehicle leaving a designated location,
Policy management server 410 is configured to “administer [a] vehicle policy” for smart vehicle 430. Liffman ¶ 62. The policy comprises “instructions for actions to perform in response to determining that a given rule or operational constraint has been violated or is in danger of being violated.” Liffman ¶ 61.
Notably, Liffman explicitly teaches that the actions can include “open[ing] a communication link with the owner,” Liffman ¶ 65, and that the given rules or operational constraints can include both “constraints that restrict the top speed,” and constraints that restrict “permissible geographic locations.” Liffman ¶ 46; see also Liffman ¶ 49 (“The policy management server 410 may track the location of the smart vehicle 430 to ensure adherence to any geographical limitations placed on the authorized access, use or rental of the vehicle.”).
Please note, although the communication link action is initially described as “causing the vehicle to open a communication link with the owner” in paragraph 65, Liffman also clarifies that in different embodiments, “actions taken by the smart vehicle 430 based on the vehicle policy may be initiated by either or both of the smart vehicle 430 and the policy management server 410.” Liffman ¶ 62. It should be understood, therefore, that this rejection is in view of the embodiment where the policy management server 410 initiates the actions, with opening the communication link with the owner being one such action.
the user terminal is configured to receive an input from a user of the user terminal,
“User devices 420 can include an input device.” Liffman ¶ 54.
the input indicating a setting which is an operational rule corresponding to implementation of a limp mode, wherein the input from the user is received via a mobile phone application or a browser web page, and the user is able to implement the operational rule in real-time,
“User device(s) 420 can be configured to execute a mobile application that provides an interactive user interface that allows a user to input data related to the specification of operational constraints” for the smart vehicle 430. Liffman ¶ 54. In addition to the operational constraints mentioned earlier, another operational constraint that the owner may define is a rule to “automatically drive the vehicle to a specified location in response to determining that the constraint has been violated.” Liffman ¶ 56.
the server is further configured to: i) verify that the setting is valid,
“According to some embodiments of the invention, if there is a conflict between the two sets of constraints . . . the policy management server 410 can resolve the conflict.” Liffman ¶ 57.
“At block 508, the method 500 includes transmitting (e.g., by the policy management server 410) the vehicle policy to the smart vehicle.” Liffman ¶ 62.
and the vehicle is configured to: i) receive the setting,
“In some embodiments of the invention, smart vehicle can be configured to receive and execute a vehicle policy received from the policy management server 410 to moderate the operation of the smart vehicle 410.” Liffman ¶ 56. “According to some embodiments of the invention, a smart vehicle 430 may provide sensor data to the policy management server 410 and receive instructions from the policy management server 410 to perform an attenuation or enforcement action in response to the policy management server's 410 determination that the operation of the smart vehicle 430 violates or is close to violating a specified constraint.” Liffman ¶ 56.
Liffman does not appear to explicitly disclose the remaining security features recited in claim 21. That is, while Liffman teaches a vehicle controlled by a server, with policies defined from a user device, the server is not necessarily configured to “verify that the vehicle is able to receive the setting,” and the vehicles are not necessarily configured to “verify that the server is a valid source.”
Aust, however, teaches
A system comprising:
Reference is made to FIGS. 1 and 2, which teach a “software update system 100” for updating software on a vehicle. See Aust ¶ 50 and FIGS. 1–2.
a server; and a vehicle, wherein:
The system 100 includes “includes a server device 101, a wireless access point 102, and an on-vehicle device 103.” Aust ¶ 50.
the server is further configured to . . . ii) verify that the vehicle is able to receive the setting,
As shown in FIG. 2, “[a] software update by the wireless communication is performed under the initiative of the server device 101.” Aust ¶ 56. However, in order to receive the software update, the vehicle must be operational. Therefore, “the control unit 108 of the server device 101 transmits a wake-up request 121,” which is forwarded to “the wake-up receiving unit 107 of the on-vehicle device 103 mounted on the vehicle 104.” Aust ¶¶ 57–58. Likewise, “[w]hen the control unit 108 of the server device 101 receives [a] wake-up completion notice 130 via the communication unit 109, the control unit 108 recognizes that the on-vehicle device 103 having the desired wake-up ID is in a wake-up state at a desired location.” Aust ¶ 60.
and iii) transmit the setting to the vehicle,
“Then, the control unit 108 of the server device 101 transmits, by the communication unit 109, an update program 131 to the communication unit 106 of the on-vehicle device 103 via the wireless access point 102 at the location where the vehicle 104 is present.” Aust ¶ 61.
and the vehicle is configured to: i) receive the setting,
“When the communication unit 106 receives the update program 131, the communication unit 106 transfers it as an update program 132 to the ECU 105.” Aust ¶ 61.
ii) verify that the server is a valid source,
“When the wake-up receiving unit 107 of the on-vehicle device 103 mounted on the vehicle 104 that is present in the wireless coverage area 110 receives the wake-up request 122, it performs security check 123. In the security check 123, the wake-up ID included in the received wake-up request 122 is compared with the wake-up ID stored in advance in the wake-up receiving unit 107. When the received wake-up ID does not match the stored wake-up ID, the wake-up receiving unit 107 disregards the wake-up request. When the received wake-up ID matches the stored wake-up ID, if there is no other security check previously defined as essential, the wake-up receiving unit 107 accepts the wake-up request.” Aust ¶ 58.
and iii) implement the setting
“The ECU 105 receives the update program 132, and updates the currently used program by the received update program 132 (133).” Aust ¶ 61.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to improve the security of Liffman’s vehicle control system with Aust’s technique of ensuring the vehicle is awake to receive updates, and ensuring that the updates are coming from a valid source. One would have been motivated to improve the security of Liffman’s system with Aust’s technique because “when wireless communication for software update can be made even when the vehicle is in any place, there is a risk of unauthorized access by a malicious third party.” Aust ¶ 7.
Claim 22
Lifftman and Aust teach system of claim 21,
wherein limp mode includes activating autonomous control of the vehicle to return the vehicle to the designated location.
The owner may define is a rule to “automatically drive the vehicle to a specified location in response to determining that the constraint has been violated.” Liffman ¶ 56.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin R. Blaufeld whose telephone number is (571)272-4372. The examiner can normally be reached M-F 9:00am - 4:00pm ET.
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, James K Trujillo can be reached at (571) 272-3677. 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.
Justin R. Blaufeld
Primary Examiner
Art Unit 2151
/Justin R. Blaufeld/Primary Examiner, Art Unit 2151
/James Trujillo/Supervisory Patent Examiner, Art Unit 2151
Prosecution Insights