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 .
Response to Amendment
This Final Office action is responsive to the communication filed under 37 C.F.R. § 1.111 on April 23, 2026 (hereafter “Response”). The amendments to the claims are acknowledged and have been entered.
Claims 1, 8, 15, and 21 are now amended.
New claims 23–25 are now added.
Claims 1–3, 5–10, 12–17, and 19–25 are pending in the application.
Response to Arguments
The 35 U.S.C. § 102 rejection based on the Kline reference is hereby withdrawn in response to the amendment to claims 1, 8, and 15 narrowing the scope of the claimed output of a user interface to one that is output in response to receiving a message from a server related to an initial condition. Kline has the same server/client architecture, but does not describe that exact process flow, so the rejection is withdrawn. It is replaced with at least two new grounds of rejection, necessitated by the amendment, and under 35 U.S.C. § 103.
In contrast, claims 21 and 22 stand rejected under 35 U.S.C. § 103 as being unpatentable over Liffman in view of Aust. The Applicant contends that neither Liffman nor Aust explicitly disclose or teach that “the user terminal is configured to receive an input from a user of the user terminal in response to receiving the notification from the server,” (Response 11) but the Examiner respectfully disagrees.
The asserted claim language describes how the user terminal functions, rather than claiming a particular structure of the user terminal. As the MPEP explains, “[f]unctional claim language that is not limited to a specific structure covers all devices that are capable of performing the recited function. Therefore, if the prior art discloses a device that can inherently perform the claimed function, a rejection under 35 U.S.C. § 102 and/or 35 U.S.C. § 103 may be appropriate.” MPEP § 2114 (subsection IV.).
Claim 21 does not contain a single limitation about the structure of the claimed user terminal. Claim 21 also fails to recite anything about the notification that prevents additional inputs from also being received at any other non-recited time. See MPEP § 2111.03 (claims with the “comprising” transitional phrase may include features that are not recited in the claim). Claim 21 doesn’t require the input to include any reference to the notification. For example, the notification of claim 21 doesn’t even solicit the user input, let alone modify the state of the claimed application or browser web page—the claimed notification merely informs the user terminal of the violation, leaving it to the user to operate the application or browser web page to provide the input.
Contrast this with claim 21’s sister claims 1, 8, and 15, each of which display the user interface in response to the notification. Unlike the other independent claims (where the client device outputs the user interface in response to the server message), claim 21 says that the user terminal is merely configured to receive an input in response to the server’s notification. The doctrine of claim differentiation tells us that this difference of wording is presumed to be significant. See, e.g., Nystrom v. TREX Co., Inc., 424 F.3d 1136, 1143 (Fed. Cir. 2005) (“When different words or phrases are used in separate claims, a difference in meaning is presumed”) and Helmsderfer v. Bobrick Washroom Equip., Inc., 527 F.3d 1379, 1382 (Fed. Cir. 2008) (“different claim terms are presumed to have different meanings”).
Consequently, the scope of claim 21 includes a system with a user terminal that is always configured to receive an input—either before or after receiving a notification from the server—falls within the scope of claim 21 (so long as the input includes all of the limitations that claim 21 recites for the input).
In this case, Liffman teaches that “[u]ser devices 420 can include an input device,” Liffman ¶ 54, meaning each user device 420 it is at least “configured to” receive an input from its user, with or without receiving a notification from policy management server 410.
As a result, since Liffman teaches a user device 420 that is configured the same way as the claimed user terminal, Liffman is understood to teach the newly amended element, and the combination of Liffman with Aust renders the whole claim obvious for the reasons set forth in the rejection below.
Accordingly, since each and every claim stands rejected, the Applicant’s request for a notice of allowance (Response 11) is respectfully denied.
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 Boyles teach claims 1, 5–8, 12–15, 19, 20, 23, and 25.
Claims 1, 5–8, 12–15, 19, 20, 23, and 25 are rejected under 35 U.S.C. § 103 as being unpatentable over U.S. Patent Application Publication No. 2020/0001890 A1 (“Kline”) in view of U.S. Patent Application Publication No. 2015/0116114 A1 (“Boyles”).
Claim 1
Kline teaches:
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
the “server” that “implement the operational rule on the fly via an over-the-air transmission to the vehicle”
remote server 30 or control element 100 (depending on interpretation of “server”)
receiving a message
Prior to step 703 of the method (e.g., while the autonomous vehicles are operating according to a first rule set in step 702), sensors 214 in the operator interface 20 “can observe a scene in the operator's field of view in which one or more autonomous vehicles 11 are operating on a road . . . and supply sensing results to the display processing unit via the I/O unit.” Kline ¶ 36.
in response to receiving the message, outputting a user interface
“The display processing unit can then [i.e., responsive to the data from sensors 214,] cause the display element 213 to display the GRCI 201 as or along with an augmented reality map 202 to the operator, which includes the details of the scene.” Kline ¶ 36. The result of the decision to display the GRCI 201 is discussed in greater detail with respect to step 703 of FIG. 7: “The method further 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 interpretation (but reasonable, 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).
Also, it should be understood that under both interpretations, the server that implements the operational rule recited at the end of the claim need not be the same server as the server that provides the message related to the initial condition recited at the beginning of the claim, because both servers are recited using the indefinite article “a,” rather than the second server using the definite article “the” to refer back to the first recited server. See Baldwin Graphic Systems, Inc. v. Siebert, 512 F.3d 1338, 1342 (Fed. Cir. 2008).
Either way, Kline teaches “transmitting the received setting to a server to implement the operational rule on the fly via an over-the-air transmission to the vehicle” for the reasons given above.
The only difference between Kline and the claimed invention is that Kline does not explicitly disclose receiving the message related to the initial condition “from a server.” The message that triggers display of the GRCI comes from the client device’s own internal sensors.
Boyles, however, teaches a method comprising:
receiving a message from a server related to an initial condition;
As shown in FIG. 5, a remote electronic device 560 receives, from a server 540, data 545 including “various graphs and maps, electronic driver log data, driver history information, vehicle history information, and hours of service (HOS) data,” all of which are transmitted by the server 540 based on, and in response to, “data collected during and surrounding a detected vehicle safety event.” Boyles ¶ 36. “This initial safety event notification to the supervisor's mobile device is intended to alert the supervisor to the occurrence of a vehicle safety situation and provide summary information regarding same.” Boyles ¶ 38.
in response to receiving the message, outputting a user interface
“The supervisor may, if desired, request additional information regarding the safety incident, such as by touching/clicking on the Event Alert 226 button shown in FIG. 2.” Boyles ¶ 38. “According to one illustrative scenario, clicking on an Event Alert message (e.g., see Event Alert 226 in FIG. 2) serves as a request from the supervisor to the central server for Event Detail information. In response, a panel 604 of Event Detail information is transmitted from the central office to the supervisor's mobile device.” Boyles ¶ 39.
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. Specifically, the skilled artisan could have either copied the notification function of Boyles’s server 540 into the implementation Kline’s remote server 30, or, left remote server 30 mostly untouched and simply added Boyles’s server 540 to Kline’s overall vehicle system 10. Both modifications fall within the scope of the claim language, because the claim language uses the indefinite article (“a server”) to name the server that transmits the message about the initial condition, and to separately name the other server that transmits the received setting to the vehicle.
Furthermore, in addition to being capable of making this modification, one of ordinary skill in the art also would have been motivated to improve Kline’s remote server 30 and/or overall vehicle system 10 with Boyles’s notification function, 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 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.
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.
Claims 8 and 12–14
Claims 8 and 12–14 are directed to a general purpose computer apparatus programmed to perform exactly the same method as recited in claims 1, and 5–7. 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 23
Kline and Boyles teach the method according to claim 1,
wherein the initial condition is based on a sensor in the vehicle.
The vehicle safety event that server 540 analyzes to send the notification is generated by an “event detector 508” that is “configured to analyze various vehicle computer information and vehicle sensor information for possible violation of one or more predetermined safety parameter violations.” Boyles ¶ 35. “It is understood that the collected data includes data produced during the safety event.” Boyles ¶ 35.
Claim 25
Kline and Boyles teach the method according to claim 1,
wherein the initial condition comprises a vehicle speed of the vehicle exceeding a speed limit.
According to various embodiments, the event detector 508 is configured to analyze various vehicle computer information and vehicle sensor information for possible violation of one or more predetermined safety parameter violations. For example, the event detector 508 can be programmed to detect events of sudden acceleration, sudden deceleration,” and thresholds thereof. Boyles ¶ 35.
II. Liffman and Boyles teach at least claims 1, 8, 15, and 23–25.
Claim(s) 1, 8, 15, and 23–25 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 Boyles.
Claim 1
Liffman teaches:
A method,
Reference is made to the system 400 in FIG. 4, which as part of its normal operation, performs the method of claim 1 for the reasons discussed herein. A prior art system that performs a method necessarily teaches that method. MPEP § 2112.02.
implemented by programmed one or more processors in a client terminal, for setting an operational rule of a vehicle, the method comprising:
System 400 includes “user devices 420,” one of which is operated by an “owner.” Liffman ¶¶ 47–48.
receiving a message from a server related to an initial condition;
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, and that one of those actions includes opening the communication link with the owner being one such action.
“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.
wherein the one or more components includes an autonomous driving control of the vehicle;
“A smart vehicle 430 can be an autonomous (i.e., self-driving vehicle) or a semi-autonomous vehicle.” Liffman ¶ 55.
receiving, via a user input to the user interface, a setting of the operational rule,
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.
wherein the operational rule assists in avoiding unsafe driving; and
“With respect to some operational constraints, the smart vehicle 430 may [provide for] ‘strict enforcement’ of the constraints by taking over control of from the driver.” Liffman ¶ 56.
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 data input into the user interface “may be used by the policy management server 410 to facilitate an operationally customized access to (or rental of) a smart vehicle 430.” Liffman ¶ 54.
Liffman does not explicitly say whether user device 420 outputs its user interface in response to receiving the violation message from the policy management server 410.
Boyles, however, teaches a method comprising:
receiving a message from a server related to an initial condition;
As shown in FIG. 5, a remote electronic device 560 receives, from a server 540, data 545 including “various graphs and maps, electronic driver log data, driver history information, vehicle history information, and hours of service (HOS) data,” all of which are transmitted by the server 540 based on, and in response to, “data collected during and surrounding a detected vehicle safety event.” Boyles ¶ 36. “This initial safety event notification to the supervisor's mobile device is intended to alert the supervisor to the occurrence of a vehicle safety situation and provide summary information regarding same.” Boyles ¶ 38.
in response to receiving the message, outputting a user interface for setting an operational rule
“The supervisor may, if desired, request additional information regarding the safety incident, such as by touching/clicking on the Event Alert 226 button shown in FIG. 2.” Boyles ¶ 38. “According to one illustrative scenario, clicking on an Event Alert message (e.g., see Event Alert 226 in FIG. 2) serves as a request from the supervisor to the central server for Event Detail information. In response, a panel 604 of Event Detail information is transmitted from the central office to the supervisor's mobile device.” Boyles ¶ 39. The interface enables the supervisor to communicate with the driver, or take other personnel-related actions concerning the driver’s behavior. Boyles ¶¶ 30–31.
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 Liffman’s user interface (and overall method) by following Boyles’s technique of outputting the user interface in response to receiving the server’s message about the unsafe driving condition. One would have been motivated to copy Boyles’s technique in this respect 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.
Claims 8 and 15
Claim 8 is directed to a general purpose computer apparatus programmed to perform exactly the same method as recited in claim 1. Therefore, the findings from those rejections are hereby reincorporated by reference, taken together with Liffman’s further disclosure of the computer hardware itself. See Liffman ¶¶ 54, 55 and 76.
Claim 15 is 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 claim 8. Therefore, claim 15 is rejected over the same findings and rationale as provided above for claims 8, with the understanding that the additional computer components in those claims (e.g., the processor) simply fall within the open-ended “comprising” scope of claim 15. See also Liffman ¶ 77.
Claim 23
Liffman and Boyles teach the method according to claim 1,
wherein the initial condition is based on a sensor in the vehicle.
“In some embodiments of the invention, the vehicle policy may include instructions for providing sensor data to policy management server 410 and policy management server 410. Sensor data can include speed, direction, acceleration, deceleration, proximity to other objects, vehicle component failure warnings, tire pressures, gas or battery power levels, data relating to the steering of the vehicle (e.g., data indicative of steady vs. erratic driving), location data (e.g., GPS coordinates), and any other such data that may be derived from a sensor disposed on or about a smart vehicle 430.” Liffman ¶ 49.
Boyles similarly provides an overlapping teaching: the vehicle safety event that server 540 analyzes to send the notification is generated by an “event detector 508” that is “configured to analyze various vehicle computer information and vehicle sensor information for possible violation of one or more predetermined safety parameter violations.” Boyles ¶ 35. “It is understood that the collected data includes data produced during the safety event.” Boyles ¶ 35.
Claim 24
Liffman, as combined with Boyles, teaches the method according to claim 1,
wherein the initial condition comprises the vehicle leaving a designated location set by the user.
“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.” Liffman ¶ 49; see also Liffman ¶ 46 (describing “permissible geographic locations” as one of the constraints). Hence, the violation occurs when the geographical limit is broken, and Liffman’s system responds in the manner discussed in the rejection of claim 1.
Claim 25
Liffman, as combined with Boyles, teaches the method according to claim 1,
wherein the initial condition comprises a vehicle speed of the vehicle exceeding a speed limit.
“In exemplary embodiments of the invention, the system can allow an owner of a smart vehicle to specify constraints on the operation of the smart vehicle accessed by a third party, such as during a rental of the smart vehicle. For example, the owner may specify constraints that restrict the top speed [and/or] acceleration.” Liffman ¶ 46.
III. Kline, Boyles, 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 in view of Boyles 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.
IV. Liffman and Aust teach claims 21 and 22.
Claims 21 and 22 are rejected under 35 U.S.C. § 103 as being unpatentable over 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, and that one of those actions includes 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 in response to receiving the notification from the server,
The above claim language describes how the user terminal functions, rather than claiming a particular structure of the user terminal. As the MPEP explains, “[f]unctional claim language that is not limited to a specific structure covers all devices that are capable of performing the recited function. Therefore, if the prior art discloses a device that can inherently perform the claimed function, a rejection under 35 U.S.C. § 102 and/or 35 U.S.C. § 103 may be appropriate.” MPEP § 2114 (subsection IV.).
Claim 21 does not contain a single limitation about the structure of the claimed user terminal. Claim 21 also fails to recite anything about the notification that prevents additional inputs from also being received at any other non-recited time. See MPEP § 2111.03 (claims with the “comprising” transitional phrase may include features that are not recited in the claim). Claim 21 doesn’t require the input to include any reference to the notification. For example, the notification of claim 21 doesn’t even solicit the user input, let alone modify the state of the claimed application or browser web page—the claimed notification merely informs the user terminal of the violation, leaving it to the user to operate the application or browser web page to provide the input. Contrast this with claim 21’s sister claims 1, 8, and 15, each of which display the user interface in response to the notification. “When different words or phrases are used in separate claims, a difference in meaning is presumed.” Nystrom v. TREX Co., Inc., 424 F.3d 1136, 1143 (Fed. Cir. 2005).
Consequently, the scope of claim 21 includes a system with a user terminal that is always configured to receive an input—either before or after receiving a notification from the server—falls within the scope of claim 21 (so long as the input includes all of the limitations that claim 21 recites for the input).
In this case, Liffman teaches that “[u]ser devices 420 can include an input device,” Liffman ¶ 54, meaning each user device 420 it is at least “configured to” receive an input from its user, with or without receiving a notification from policy management server 410.
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
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 C.F.R. § 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 C.F.R. § 1.17(a)) pursuant to 37 C.F.R. § 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 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
Prosecution Insights