DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1, 3-11, and 13-19 are pending.
Claims 2 and 12 have been cancelled.
Claims 1, 9, 10, 11, and 19 have been amended.
Response to Amendment
Objections to the Drawings: Applicant’s replacement sheet overcomes the objections of record. The objections to the drawings are withdrawn.
Rejections Under 35 U.S.C. §112(b): Applicant’s amended claims 9, 10, and 19 overcome the rejection of record. The 112(b) rejections are withdrawn.
Rejections Under 35 U.S.C. §101: Applicant’s amendments to the claims do not overcome the rejection of record. The 101 rejection is maintained.
Rejections Under 35 U.S.C. §103: Claims 1 and 11 have been amended to change the scope of the claimed invention. Specifically, limitations pertaining to “send the user answers to the vehicle controller for a validation of the user answers locally on the vehicle; and receive, from the vehicle controller, confirmation that the user answers are validated locally on the vehicle and correct based on a comparison to local vehicle data” which changes the scope of the claimed invention.
Response to Arguments
Rejections Under 35 U.S.C. §101: Applicant's arguments filed 12/18/2025 have been fully considered but they are not persuasive.
Applicant argues “Claims 1-19 stand rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception without significantly more.
At the outset, Applicant notes the Office states the claims are rejected because: "The claims recite a vehicle control apparatus" (OA, page 4). However, nowhere do the claims recite "a vehicle control apparatus." For at least this reason alone, Applicant submits the rejection is in error.”
Examiner respectfully disagrees, the rejection is an error due to the recitation of "The claims recite a vehicle control apparatus" in the office action as the portion of the rejection is merely a statement to establish whether the claims fall within one of the four statutory categories and although nowhere do the claims recite "a vehicle control apparatus” the analysis that the claims do fall within one of the four statutory categories remains the same, the rejection has been corrected in the present office action below, and further since the claims do fall within one of the four statutory categories the claims would be subject to subsequent analysis to determine whether the claims are directed to a judicial exception.
Applicant argues “Further, Applicant notes that independent claims 1 and 11 recite where the backend server includes one or more processors and a non-transitory memory to perform specifically recited steps, as well as interaction with a user electronic device, a user channel, and/or a vehicle controller.
Applicant submits that independent claims 1 and 11 do not recite a judicial exception. More specifically, the claims do not recite a mental process because the claims, under their broadest reasonable interpretation, do not cover performance in the mind but for the recitation of generic computer components. For example, the recited steps require action by a processor that cannot be practically applied in the mind (e.g., the mind cannot send random questions to the user electronic device, or validate user provided answers, by the vehicle controller). Such steps are not a mental process, but rather utilizing a physical system (e.g., backend server and vehicle controller with processors) for generating authentication questions, sending/receiving signals, and locally verifying data with a vehicle controller.”
Examiner respectfully disagrees, as the backend server includes one or more processors and a non-transitory memory to perform specifically recited steps, as well as interaction with a user electronic device, a user channel, and/or a vehicle controller (i.e., receiving and sensing steps) are not interpreted as the judicial exception (abstract idea/a mental process that can be performed in the mind), but are analyzed as additional elements which are analyzed on whether or not they integrate the judicial exception into a practical application. The judicial exception (abstract idea/a mental process that can be performed in the mind) is identified in the analysis as the “generating, at the backend server, one or more random questions about vehicle signals that are visible on the vehicle display” and “validating the user provided answers, by the vehicle controller, based on a comparison to local vehicle data” steps, which as drafted, are a processes that, under the broadest reasonable interpretation, cover performance of limitations in the mind but for the recitation of generic computer components (“backend server” and “vehicle controller”), as one can reasonably interpret the generation of one or more random questions about vehicle signals that are visible on the vehicle display can encompass a person looking at a screen and thinking of a question and further that validating the user provided answers, by the vehicle controller, based on a comparison to local vehicle data can encompass a person receiving an answer and making a determination of whether the answer is correct by comparing it to observed data. Therefore the claim(s) recite an abstract idea (mental process).
Applicant further argues “Moreover, even assuming arguendo that claims 1 and 11 are directed to an abstract idea, the claims constitute patentable subject matter under the practical application exception. Example 37 from the 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG) finds claim 1 to be patent-eligible. In Example 37, claim 1 generally recites receiving data/input, manipulating the data/input with a processor, and automatically preforming a task. This is similar to claims 1 and 11 of the present application. Specifically, the present claims 1 and 11 include recitations to a computer- implemented method that obtains a request, utilizes a processor to generate random questions about visible vehicle signals, and validates received answers locally with a vehicle controller. Claims 1 and 11 thereby provide a combination of additional elements that are integrated into a practical application, as claim 1 of Example 37. As such, the claims as a whole recite (or are integrated into) a practical application, which provides a specific improvement over prior systems that do not authenticate a vehicle for linking to a use case without sending any sensitive vehicle data, resulting in an improvement in the technology for vehicle authentication to a use case.
In light of the foregoing, Applicant respectfully submits that claims 1 and 11 are statutory under 35 U.S.C. §101. Claims 3-10 and 13-19 depend from claims 1 and 11 and are statutory for at least the same reasons. Accordingly, Applicant respectfully requests withdrawal of the rejection.”
Examiner respectfully disagrees, as claim 1 in Example 37 does not generally recites receiving data/input, manipulating the data/input with a processor, and automatically preforming a task, but specifically recites a manner of automatically displaying icons to the user based on usage which provides a specific improvement over prior systems, resulting in an improved user interface for electronic devices. Further in order to show an improvement to the functioning of a computer or to any other technology or technical field “the claims must recite the details regarding how a computer aids the method, the extent to which the computer aids the method, or the significance of a computer to the performance of the method. Merely adding generic computer components to perform the method is not sufficient. Thus, the claim must include more than mere instructions to perform the method on a generic component or machinery to qualify as an improvement to an existing technology” (see at least MPEP § 2106.05(a) and MPEP §2106.05(f)). Specifically the claim as drafted, merely recite instructions to perform a method for factor authenticating a vehicle for linking to a use case on generic component(s) (“backend server” and “vehicle controller”) or machinery. Therefore due to the recitation of the “backend server” and “vehicle controller” being recited at a high generality and the mere recitation of instructions to perform the method on these generic components for example “generating, at the backend server, one or more random questions about vehicle signals that are visible on the vehicle display” and “validating the user provided answers, by the vehicle controller, based on a comparison to local vehicle data” the claim would not qualify as an in an improvement in the technology for vehicle authentication to a use case. Claims 1 and 11 are similar in this way to claim 3 of Example 37 from the 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG) which was found to be patent-ineligible. Therefore the 101 rejection is maintained.
Rejections Under 35 U.S.C. §103: Applicant’s arguments with respect to claims 1, 2, 8, 11, 12, 18, and 19 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 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 3-11, and 13-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1 and 11 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1. A factor authentication system for a vehicle having a vehicle display, a telematics device, and a vehicle controller, the factor authentication system comprising:
a backend server configured to communicate with the vehicle and a user electronic device via a network,
wherein the backend server includes one or more processors and a non-transitory computer-readable storage medium, and is configured to:
receive a request from the user electronic device to link the vehicle to a use case;
generate one or more random questions about vehicle signals that are visible on the vehicle display;
send the one or more random questions to the user electronic device;
receive, from the user electronic device, user answers to the one or more random vehicle signal questions;
send the user answers to the vehicle controller for a validation of the user answers locally on the vehicle; and
receive, from the vehicle controller, confirmation that the user answers are validated locally on the vehicle and correct based on a comparison to local vehicle data, to thereby authenticate the vehicle and authorize the link to the use case,
wherein when the vehicle controller confirms the user answers locally on the vehicle, the vehicle controller sends a signal to the backend server indicating whether each of the user answers is correct or incorrect, without sending any sensitive vehicle data to the backend server.
Claim 11. A computer-implemented method for factor authenticating a vehicle for linking to a use case, the vehicle including a vehicle display, a telematics device, and a vehicle controller having one or more processors and a non- transitory computer-readable storage medium, the method comprising:
receiving, from a user channel and at a backend server having one or more processors and anon-transitory computer-readable storage medium, a user request to link the vehicle to the use case;
generating, at the backend server, one or more random questions about vehicle signals that are visible on the vehicle display;
sending, by the backend server, the one or more random vehicle signal questions to the user channel;
receiving, from the user channel and at the backend server, user provided answers to the one or more random vehicle signal questions;
sending, from the backend server, the user provided answers to the vehicle controller for validation of the user answers locally on the vehicle; and
validating the user provided answers locally on the vehicle, by the vehicle controller, based on a comparison to local vehicle data, to thereby authenticate the vehicle and link to the use case,
wherein when the vehicle controller validates the user provided answers locally on the vehicle, the vehicle controller sends a signal to the backend server indicating whether each of the user answers is correct or incorrect, without sending any sensitive vehicle data to the backend server.
101 Analysis - Step 1: Statutory category – Yes
The claims 1 and 11 recite a factor authentication system for a vehicle having a vehicle display, a telematics device, and a vehicle controller (i.e., a machine) and a computer-implemented method for factor authenticating a vehicle for linking to a use case (a method) including at least one step respectively. The claims fall within one of the four statutory categories (see at least MPEP 2106.03).
101 Analysis - Step 2A Prong one evaluation: Judicial Exception – Yes – Mental processes
In Step 2A, Prong one of the 2019 Patent Eligibility Guidance (PEG), a claim is to be analyzed to determine whether it recites subject matter that falls within one of the following groups of abstract ideas: a) mathematical concepts, b) mental processes, and/or c) certain methods of organizing human activity.
The Office submits that the foregoing bolded limitation(s) constitutes judicial exceptions in terms of “mental processes” because under its broadest reasonable interpretation, the limitations can be “performed in the human mind, or by a human using a pen and paper” (see at least MPEP 2106.04(a)(2)(III)).
The claims recite the limitation of generating, at the backend server, one or more random questions about vehicle signals that are visible on the vehicle display and validating the user provided answers locally on the vehicle, by the vehicle controller, based on a comparison to local vehicle data, to thereby authenticate the vehicle and link to the use case. This limitation, as drafted, is a simple process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of “at the backend server” and “by the vehicle controller”. That is, other than reciting “at the backend server” and “by a vehicle controller” nothing in the claim elements precludes the step from practically being performed in the mind. For example, but for the “at the backend server” and “by the vehicle controller” language, the claim encompasses a person looking at data collected and forming a simple judgement. The mere nominal recitation of by a controller does not take the claim limitations out of the mental process grouping.
Thus, the claim recites a mental process.
101 Analysis - Step 2A Prong two evaluation: Practical Application - No
In Step 2A, Prong two of the 2019 PEG, a claim is to be evaluated whether, as a whole, it integrates the recited judicial exception into a practical application. As noted in MPEP 2106.04(d), it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. The courts have indicated that additional elements such as: merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.”
The Office submits that the foregoing underlined limitation(s) recite additional elements that do not integrate the recited judicial exception into a practical application.
The claim recites additional elements or steps of receiving, from a user channel and at a backend server having one or more processors and a non-transitory computer-readable storage medium, a user request to link the vehicle to the use case; sending, by the backend server, the one or more random vehicle signal questions to the user channel; receiving, from the user channel and at the backend server, user provided answers to the one or more random vehicle signal questions; sending, from the backend server, the user provided answers to the vehicle controller for validation of the user answers locally on the vehicle, and sends a signal to the backend server indicating whether each of the user answers is correct or incorrect, without sending any sensitive vehicle data to the backend server. The receiving, from a user channel and at a backend server having one or more processors and a non-transitory computer-readable storage medium, a user request to link the vehicle to the use case; sending, by the backend server, the one or more random vehicle signal questions to the user channel; receiving, from the user channel and at the backend server, user provided answers to the one or more random vehicle signal questions; and sending, from the backend server, the user provided answers to the vehicle controller for validation of the user answers locally on the vehicle steps are recited at a high level of generality (i.e. as a general means of gathering vehicle data and/or authentication data (i.e., questions and answers) for use in the validating step), and amount to mere data gathering, which is a form of insignificant extra-solution activity. The sending a signal to the backend server indicating whether each of the user answers is correct or incorrect, without sending any sensitive vehicle data to the backend server step is also recited at a high level of generality (i.e. as a general means of displaying/outputting the validation result from the validating step), and amounts to mere post solution displaying/outputting, which is a form of insignificant extra-solution activity. The “factor authentication system” merely describes how to generally “apply” the otherwise mental judgements using a generic or general-purpose vehicle control environment, i.e. a computer. The factor authentication system is recited at a high level of generality and is merely automates the validating step.
Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
101 Analysis - Step 2B evaluation: Inventive concept - No
In Step 2B of the 2019 PEG, a claim is to be evaluated as to whether the claim, as a whole, amounts to significantly more than the recited exception, i.e., whether any additional element, or combination of additional elements, adds an inventive concept to the claim. See MPEP 2106.05.
As discussed with respect to Step 2A Prong Two, the additional elements in the claim amount to no more than mere instructions to apply the exception using a generic computer component. The same analysis applies here in 2B, i.e., mere instructions to apply an exception on a generic computer cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Under the 2019 PEG, a conclusion that an additional element is insignificant extra-solution activity in Step 2A should be re-evaluated in Step 2B. Here, the receiving and sending steps and the displaying/outputting (sending) step were considered to be insignificant extra-solution activity in Step 2A, and thus they are re-evaluated in Step 2B to determine if they are more than what is well-understood, routine, conventional activity in the field. The sensors and/or vehicle signal(s) are recited at a high generality and do not indicate anything other than signal(s) received from conventional sensors mounted on a vehicle, and the specification does not provide any indication that the vehicle controller and/or backend server are anything other than a conventional computer within a vehicle and server respectively. MPEP 2106.05(d)(II), and the cases cited therein, including Intellectual Ventures I, LLC v. Symantec Corp., 838 F.3d 1307, 1321 (Fed. Cir. 2016), TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610 (Fed. Cir. 2016), and OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015), indicate that mere collection or receipt of data over a network is a well‐understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here). Further, the Federal Circuit in Trading Techs. Int’l v. IBG LLC, 921 F.3d 1084, 1093 (Fed. Cir. 2019), and Intellectual Ventures I LLC v. Erie Indemnity Co., 850 F.3d 1315, 1331 (Fed. Cir. 2017), for example, indicated that the mere displaying/outputting of data is a well understood, routine, and conventional function. Accordingly, a conclusion that the collecting step is well-understood, routine, conventional activity is supported under Berkheimer.
Thus, the claim is ineligible.
Dependent Claims
Dependent claims 3-10 and 13-19 do not recite any further limitations that cause the claim(s) to be patent eligible. Rather, the limitations of the dependent claims are directed toward additional aspects of the judicial exception and/or well-understood, routine and conventional additional elements that do not integrate the judicial exception into a practical application such as mere post solution displaying/outputting similar to that detailed above and further limitations pertaining to receiving data which amounts to mere data gathering, which is a form of insignificant extra-solution activity and according to MPEP 2106.05(d)(II), and the cases cited therein, including Intellectual Ventures I, LLC v. Symantec Corp., 838 F.3d 1307, 1321 (Fed. Cir. 2016), TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610 (Fed. Cir. 2016), and OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015), indicate that mere collection or receipt of data over a network is a well‐understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here) and further, the Federal Circuit in Trading Techs. Int’l v. IBG LLC, 921 F.3d 1084, 1093 (Fed. Cir. 2019), and Intellectual Ventures I LLC v. Erie Indemnity Co., 850 F.3d 1315, 1331 (Fed. Cir. 2017), for example, indicated that the mere displaying/outputting of data is a well understood, routine, and conventional function. Therefore, dependent claims 3-10 and 13-19 are not patent eligible under the same rationale as provided for in the rejection of independent claims 1 and 11.
Therefore, claims 3-10 and 13-19 are ineligible under 35 USC §101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 7, 9-11, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Yager (US10623401B1) in view of Forster et al. (US2022/0379906A1) in view of Mouser et al. (US2016/0082926A1) in further view of Copejans (US2010/0287038A1), hereinafter Yager, Forster, Mouser, and Copejans respectively.
Regarding claim 1, (Currently Amended) Yager teaches a factor authentication system for a vehicle having a vehicle display (see at least Col. 15 lines 29-31 “In some embodiments, telematics device 222 may be configured to execute an authentication manager 213 that 30 presents a user interface for a driver”), a telematics device (see at least Fig. 2- Telematics Device 222), and a vehicle controller (see at least Fig. 2- Vehicle Ctrl. Computer 227), the factor authentication system comprising: a backend server configured to communicate with the vehicle and a user electronic device via a network (see at least Col. 6 lines 60-62 “FIG. 1A, the user device 104a is in signal communication with the vehicle 117 a and a computing system 106a via a network 108a.” also see at least Col.1 lines 44-47 “a system comprising a telematics device associated with a vehicle having one or more sensors arranged therein, a mobile device of a user associated with the vehicle, and a server computer”), wherein the backend server includes one or more processors and a non-transitory computer-readable storage medium (see at least Col.1 lines 47-48 “a server computer comprising hardware including a processor and memory”), and is configured to: receive a request from the user electronic device to link the vehicle to a use case (see at least Col. 7 lines 8-10 “In an example scenario, the user 102a may operate the user device 104a and request access to one of the computing resources 110a of the computing system 106a.”); generate one or more random questions about vehicle signals that are visible on the vehicle display (see at least Col. 7 lines 29-30 “generating a set of challenge questions to present to the user based on the telematics data” and Col.18 lines 10-14 “the authentication module 204 may be configured with programmed instructions to parse the different types of data accessible to the authentication system 200 and generate one or more challenge questions to be presented to a user during an authentication process.”); send the one or more random questions to the user electronic device (see at least Col. 7 lines 31-32 “transmitting the set of challenge questions to the user device 104a for presentation to the user”); receive, from the user electronic device, user answers to the one or more random vehicle signal questions (see at least Col. 7 lines 32-33 “receive answers to the challenge questions from the user device”).
Examiner interprets that vehicle having a vehicle display is encompassed at least by a user interface for a driver, user electronic device is encompassed at least by user device, backend server is encompassed at least by computing system and/or server computer, and a use case is encompassed at least by request access to one of the computing resources 110a.
Yager suggests receive, confirmation that the user answers are correct based on a comparison to local vehicle data, to thereby authenticate the vehicle and authorize the link to the use case (see at least Col. 3 lines 13-19 “If the user answers the one or more questions correctly (e.g., the response from the user matches the telematics data or determination made from the telematics data), then the user may be successfully authenticated, and the authentication system may grant the user access to the one or more computing resources.”) and sends a signal to the backend server indicating whether each of the user answers is correct or incorrect, without sending any sensitive vehicle data to the backend server (see at least Col.8 lines 28-31 “the authentication service 114b may determine whether to authenticate the user 102b (using challenge questions generated based on telematics data 118b) and provide the authentication result to the computing system 106b.”).
Examiner interprets that a comparison to local vehicle data is encompassed at least by the response from the user matches the telematics data or determination made from the telematics data, authorize the link to the use case is encompassed at least by grant the user access to the one or more computing resources, and a signal to the backend server indicating whether each of the user answers is correct or incorrect is encompassed at least by provide the authentication result to the computing system 106b.
Yager does not explicitly teach send the user answers to the vehicle controller for a validation of the user answers locally on the vehicle; and receive, from the vehicle controller, confirmation that the user answers are validated locally on the vehicle and correct based on a comparison to local vehicle data, to thereby authenticate the vehicle and authorize the link to the use case, wherein when the vehicle controller confirms the user answers locally on the vehicle, the vehicle controller sends a signal to the backend server indicating whether each of the user answers is correct or incorrect, without sending any sensitive vehicle data to the backend server.
Forster more explicitly teaches a factor authentication system for a vehicle having a vehicle display (see at least [0059] “The driving assistance system 100 comprises a user interface module 110” and [0068] “a user interface module with a display apparatus 200” also see at least [0038]), and a vehicle controller (see at least [0062] “a control module 120”), the factor authentication system comprising: generate one or more random questions about vehicle signals that are visible on the vehicle display (see at least [0070] “With reference to FIG. 2A, the display apparatus 200 shows a question 202 in relation to a functioning of a driving assistance function.”); and suggests send the user answers to the vehicle controller for a validation of the user answers locally on the vehicle (see at least [0062] “a control module 120 which is set up to activate and/or operate the driving assistance function 30 based on a correctness of the content of the answering of the at least two questions.”).
Mouser more explicitly teaches a validation of the user answers locally on the vehicle (see at least [0033] “The authentication system 10 may receive an authentication code, such as a PIN or password, from the user (e.g. on the touch display 12) and either authenticate the PIN locally”); and receive, from the vehicle controller, confirmation that the user answers are validated locally on the vehicle and correct based on a comparison to local vehicle data (see at least [0031] “the authentication system 10 may perform the authentication locally, if it has stored locally the authentication information required to be matched by the user.”), to thereby authenticate the vehicle and authorize the link to the use case (see at least [0036] “Once the authentication system 10 is able to completely authorize the user (e.g. once it has connectivity to authentication server 36), it can permit full operation of the vehicle 52”), wherein when the vehicle controller confirms the user answers locally on the vehicle (see at least [0033] “The authentication system 10 may receive an authentication code, such as a PIN or password, from the user (e.g. on the touch display 12) and either authenticate the PIN locally”).
Copejans suggests sends a signal to the backend server indicating whether each of the user answers is correct or incorrect, without sending any sensitive vehicle data to the backend server (see at least [0155] “The smart card provides interfaces to limit the privacy-sensitive information sent to the back-end server while still maintaining a high-level of security. The smart card only returns the status of integrity checks on event data it has performed, without disclosing the data themselves.”).
Examiner interprets that indicating whether each of the user answers is correct or incorrect is suggested at least by returns the status of integrity checks on event data it has performed and without sending any sensitive vehicle data to the backend server is encompassed at least by limit the privacy-sensitive information sent to the back-end server and/or without disclosing the data themselves.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Yager of a factor authentication system for a vehicle having a vehicle display, a telematics device, and a vehicle controller, the factor authentication system comprising: a backend server configured to communicate with the vehicle and a user electronic device via a network, wherein the backend server includes one or more processors and a non-transitory computer-readable storage medium, and is configured to: receive a request from the user electronic device to link the vehicle to a use case; generate one or more random questions about vehicle signals that are visible on the vehicle display; send the one or more random questions to the user electronic device; receive, from the user electronic device, user answers to the one or more random vehicle signal questions and the suggested teaching of Yager of receive, confirmation that the user answers are correct based on a comparison to local vehicle data, to thereby authenticate the vehicle and authorize the link to the use case and sends a signal to the backend server indicating whether each of the user answers is correct or incorrect, without sending any sensitive vehicle data to the backend server with the teaching of a factor authentication system for a vehicle having a vehicle display, and a vehicle controller, the factor authentication system comprising: generate one or more random questions about vehicle signals that are visible on the vehicle display of Forster, suggested teaching of send the user answers to the vehicle controller for a validation of the user answers locally on the vehicle found in Forster, the teaching of a validation of the user answers locally on the vehicle; and receive, from the vehicle controller, confirmation that the user answers are validated locally on the vehicle and correct based on a comparison to local vehicle data, to thereby authenticate the vehicle and authorize the link to the use case, wherein when the vehicle controller confirms the user answers locally on the vehicle found in Mouser, and the suggested teaching of sends a signal to the backend server indicating whether each of the user answers is correct or incorrect, without sending any sensitive vehicle data to the backend server found in Copejans. One could combine the teachings in order to have a factor authentication system for a vehicle having a vehicle display, a telematics device, and a vehicle controller, the factor authentication system comprising: a backend server configured to communicate with the vehicle and a user electronic device via a network, wherein the backend server includes one or more processors and a non-transitory computer-readable storage medium, and is configured to: receive a request from the user electronic device to link the vehicle to a use case; generate one or more random questions about vehicle signals that are visible on the vehicle display; send the one or more random questions to the user electronic device; receive, from the user electronic device, user answers to the one or more random vehicle signal questions; send the user answers to the vehicle controller for a validation of the user answers locally on the vehicle; and receive, from the vehicle controller, confirmation that the user answers are validated locally on the vehicle and correct based on a comparison to local vehicle data, to thereby authenticate the vehicle and authorize the link to the use case, wherein when the vehicle controller confirms the user answers locally on the vehicle, the vehicle controller sends a signal to the backend server indicating whether each of the user answers is correct or incorrect, without sending any sensitive vehicle data to the backend server with a reasonable expectation of success. One would have been motivated to do so in order to improve vehicle security.
Regarding claim 7, (Original) the combination of Yager, Forster, Mouser, and Copejans teaches the vehicle factor authentication system of claim 1 as detailed above.
Yager teaches wherein the vehicle signals are at least one of (i) an odometer reading, (ii) a vehicle tire pressure, or (iii) a vehicle range (see at least Col. 13 line 64 – Col. 14 line 2 “Additional sensors 218 may detect and store data relating to the maintenance of the vehicle 217, such as the engine status, oil level, engine coolant temperature, odometer reading, the level of fuel in the fuel tank, engine revolutions per minute (RPMs), software upgrades, and/or tire pressure.”).
Examiner interprets that the claim is written in the alternative and therefore only one of the limitations needs to be addressed.
Regarding claim 9, (Currently Amended) the combination of Yager, Forster, Mouser, and Copejans teaches the vehicle factor authentication system of claim 1 as detailed above.
Yager teaches wherein the vehicle signals are chosen from the group consisting of: (i) a vehicle tire pressure, (ii) a battery voltage, (iii) a range to empty, (iv) an oil life, and (v) an odometer reading (see at least Col. 13 line 64 – Col. 14 line 2 “Additional sensors 218 may detect and store data relating to the maintenance of the vehicle 217, such as the engine status, oil level, engine coolant temperature, odometer reading, the level of fuel in the fuel tank, engine revolutions per minute (RPMs), software upgrades, and/or tire pressure.” also see at least Col. 13 lines 39-43 “sensor 218 may detect and store data corresponding to the vehicle's location (e.g., GPS coordinates), time, travel time, speed and direction, rates of acceleration or braking, gas mileage, and specific instances of sudden acceleration, braking, swerving, and distance traveled.”).
Examiner interprets that the claim is written in the alternative and therefore only one of the limitations needs to be addressed.
Regarding claim 10, (Currently Amended) the combination of Yager, Forster, Mouser, and Copejans teaches the vehicle factor authentication system of claim 1 as detailed above.
Yager teaches wherein the vehicle signals are chosen from the group consisting of: (i) a vehicle tire pressure, (ii) a battery voltage, (iii) a high voltage battery state of charge, (iv) a total range, and (v) an odometer reading (see at least Col. 13 line 64 – Col. 14 line 2 “Additional sensors 218 may detect and store data relating to the maintenance of the vehicle 217, such as the engine status, oil level, engine coolant temperature, odometer reading, the level of fuel in the fuel tank, engine revolutions per minute (RPMs), software upgrades, and/or tire pressure.” also see at least Col. 13 lines 39-43 “sensor 218 may detect and store data corresponding to the vehicle's location (e.g., GPS coordinates), time, travel time, speed and direction, rates of acceleration or braking, gas mileage, and specific instances of sudden acceleration, braking, swerving, and distance traveled.”).
Examiner interprets that the claim is written in the alternative and therefore only one of the limitations needs to be addressed.
Regarding claim 11, (Currently Amended) Yager teaches a computer-implemented method for factor authenticating a vehicle for linking to a use case, the vehicle including a vehicle display (see at least Col. 15 lines 29-31 “In some embodiments, telematics device 222 may be configured to execute an authentication manager 213 that 30 presents a user interface for a driver”), a telematics device (see at least Fig. 2- Telematics Device 222), and a vehicle controller (see at least Fig. 2- Vehicle Ctrl. Computer 227) having one or more processors and a non- transitory computer-readable storage medium, the method comprising (see at least Col. 24 lines 31-35 “aspects may take the form of one or more computing devices configured to perform specified actions. Furthermore, such aspects may take the form of computer-executable instructions stored by one or more non-transitory computer-readable storage media.”): receiving, from a user channel and at a backend server having one or more processors and anon-transitory computer-readable storage medium (see at least Col.1 lines 47-48 “a server computer comprising hardware including a processor and memory”), a user request to link the vehicle to the use case (see at least Col. 7 lines 8-10 “In an example scenario, the user 102a may operate the user device 104a and request access to one of the computing resources 110a of the computing system 106a.”); generating, at the backend server, one or more random questions about vehicle signals that are visible on the vehicle display (see at least Col. 7 lines 29-30 “generating a set of challenge questions to present to the user based on the telematics data” and Col.18 lines 10-14 “the authentication module 204 may be configured with programmed instructions to parse the different types of data accessible to the authentication system 200 and generate one or more challenge questions to be presented to a user during an authentication process.”); sending, by the backend server, the one or more random vehicle signal questions to the user channel (see at least Col. 7 lines 31-32 “transmitting the set of challenge questions to the user device 104a for presentation to the user”); receiving, from the user channel and at the backend server, user provided answers to the one or more random vehicle signal questions (see at least Col. 7 lines 32-33 “receive answers to the challenge questions from the user device”).
Examiner interprets that vehicle having a vehicle display is encompassed at least by a user interface for a driver, user channel is encompassed at least by user device, backend server is encompassed at least by computing system and/or server computer, and a use case is encompassed at least by request access to one of the computing resources 110a.
Yager suggests validating the user provided answers based on a comparison to local vehicle data, to thereby authenticate the vehicle and link to the use case (see at least Col. 3 lines 13-19 “If the user answers the one or more questions correctly (e.g., the response from the user matches the telematics data or determination made from the telematics data), then the user may be successfully authenticated, and the authentication system may grant the user access to the one or more computing resources.”) and sends a signal to the backend server indicating whether each of the user answers is correct or incorrect, without sending any sensitive vehicle data to the backend server (see at least Col.8 lines 28-31 “the authentication service 114b may determine whether to authenticate the user 102b (using challenge questions generated based on telematics data 118b) and provide the authentication result to the computing system 106b.”).
Examiner interprets that validating the user provided answers based on a comparison to local vehicle data, to thereby authenticate the vehicle is encompassed at least by the response from the user matches the telematics data or determination made from the telematics data, link to the use case is encompassed at least by grant the user access to the one or more computing resources, and a signal to the backend server indicating whether each of the user answers is correct or incorrect is encompassed at least by provide the authentication result to the computing system 106b.
Yager does not explicitly teach sending, from the backend server, the user provided answers to the vehicle controller for validation of the user answers locally on the vehicle; and validating the user provided answers locally on the vehicle, by the vehicle controller, based on a comparison to local vehicle data, to thereby authenticate the vehicle and link to the use case, wherein when the vehicle controller validates the user provided answers locally on the vehicle, the vehicle controller sends a signal to the backend server indicating whether each of the user answers is correct or incorrect, without sending any sensitive vehicle data to the backend server.
Forster more explicitly teaches a computer-implemented method for factor authenticating a vehicle for linking to a use case, the vehicle including a vehicle display (see at least [0059] “The driving assistance system 100 comprises a user interface module 110” and [0068] “a user interface module with a display apparatus 200” also see at least [0038]) and a vehicle controller (see at least [0062] “a control module 120”) having one or more processors and a non- transitory computer-readable storage medium, the method comprising (see at least [0051] “The storage medium may comprise an SW program that is designed to be executed on one or more processors in order thereby to execute the driving assistance method described in this document for a vehicle.”): generating, at the backend server, one or more random questions about vehicle signals that are visible on the vehicle display (see at least [0070] “With reference to FIG. 2A, the display apparatus 200 shows a question 202 in relation to a functioning of a driving assistance function.”); and suggests sending the user provided answers to the vehicle controller for validation of the user answers locally on the vehicle (see at least [0062] “a control module 120 which is set up to activate and/or operate the driving assistance function 30 based on a correctness of the content of the answering of the at least two questions.”).
Mouser more explicitly teaches validation of the user answers locally on the vehicle (see at least [0033] “The authentication system 10 may receive an authentication code, such as a PIN or password, from the user (e.g. on the touch display 12) and either authenticate the PIN locally”); and validating the user provided answers locally on the vehicle, by the vehicle controller, based on a comparison to local vehicle data (see at least [0031] “the authentication system 10 may perform the authentication locally, if it has stored locally the authentication information required to be matched by the user.”), to thereby authenticate the vehicle and link to the use case (see at least [0036] “Once the authentication system 10 is able to completely authorize the user (e.g. once it has connectivity to authentication server 36), it can permit full operation of the vehicle 52”), wherein when the vehicle controller validates the user provided answers locally on the vehicle (see at least [0033] “The authentication system 10 may receive an authentication code, such as a PIN or password, from the user (e.g. on the touch display 12) and either authenticate the PIN locally”).
Copejans suggests sends a signal to the backend server indicating whether each of the user answers is correct or incorrect, without sending any sensitive vehicle data to the backend server (see at least [0155] “The smart card provides interfaces to limit the privacy-sensitive information sent to the back-end server while still maintaining a high-level of security. The smart card only returns the status of integrity checks on event data it has performed, without disclosing the data themselves.”).
Examiner interprets that indicating whether each of the user answers is correct or incorrect is suggested at least by returns the status of integrity checks on event data it has performed and without sending any sensitive vehicle data to the backend server is encompassed at least by limit the privacy-sensitive information sent to the back-end server and/or without disclosing the data themselves.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Yager of a computer-implemented method for factor authenticating a vehicle for linking to a use case, the vehicle including a vehicle display, a telematics device, and a vehicle controller having one or more processors and a non- transitory computer-readable storage medium, the method comprising: receiving, from a user channel and at a backend server having one or more processors and anon-transitory computer-readable storage medium, a user request to link the vehicle to the use case; generating, at the backend server, one or more random questions about vehicle signals that are visible on the vehicle display; sending, by the backend server, the one or more random vehicle signal questions to the user channel; receiving, from the user channel and at the backend server, user provided answers to the one or more random vehicle signal questions and the suggested teaching of Yager of validating the user provided answers based on a comparison to local vehicle data, to thereby authenticate the vehicle and link to the use case and sends a signal to the backend server indicating whether each of the user answers is correct or incorrect, without sending any sensitive vehicle data to the backend server with the teaching of a computer-implemented method for factor authenticating a vehicle for linking to a use case, the vehicle including a vehicle display and a vehicle controller having one or more processors and a non- transitory computer-readable storage medium, the method comprising: generating, at the backend server, one or more random questions about vehicle signals that are visible on the vehicle display found in Forster, the suggested teaching of sending the user provided answers to the vehicle controller for validation of the user answers locally on the vehicle found in Forster, the teaching of validation of the user answers locally on the vehicle; and validating the user provided answers locally on the vehicle, by the vehicle controller, based on a comparison to local vehicle data, to thereby authenticate the vehicle and link to the use case, wherein when the vehicle controller validates the user provided answers locally on the vehicle found in Mouser, and the suggested teaching of sends a signal to the backend server indicating whether each of the user answers is correct or incorrect, without sending any sensitive vehicle data to the backend server found in Copejans. One could combine the teachings in order to have a computer-implemented method for factor authenticating a vehicle for linking to a use case, the vehicle including a vehicle display, a telematics device, and a vehicle controller having one or more processors and a non- transitory computer-readable storage medium, the method comprising: receiving, from a user channel and at a backend server having one or more processors and anon-transitory computer-readable storage medium, a user request to link the vehicle to the use case; generating, at the backend server, one or more random questions about vehicle signals that are visible on the vehicle display; sending, by the backend server, the one or more random vehicle signal questions to the user channel; receiving, from the user channel and at the backend server, user provided answers to the one or more random vehicle signal questions; sending, from the backend server, the user provided answers to the vehicle controller for validation of the user answers locally on the vehicle; and validating the user provided answers locally on the vehicle, by the vehicle controller, based on a comparison to local vehicle data, to thereby authenticate the vehicle and link to the use case, wherein when the vehicle controller validates the user provided answers locally on the vehicle, the vehicle controller sends a signal to the backend server indicating whether each of the user answers is correct or incorrect, without sending any sensitive vehicle data to the backend server with a reasonable expectation of success. One would have been motivated to do so in order to improve vehicle security.
Regarding claim 17, (Original) the combination of Yager, Forster, Mouser, and Copejans teaches the method of claim 11 as detailed above.
Yager teaches wherein the vehicle signals are at least one of (i) an odometer reading, (ii) a vehicle tire pressure, or (iii) a vehicle range (see at least Col. 13 line 64 – Col. 14 line 2 “Additional sensors 218 may detect and store data relating to the maintenance of the vehicle 217, such as the engine status, oil level, engine coolant temperature, odometer reading, the level of fuel in the fuel tank, engine revolutions per minute (RPMs), software upgrades, and/or tire pressure.”).
Examiner interprets that the claim is written in the alternative and therefore only one of the limitations needs to be addressed.
Claims 3-6 and 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over Yager (US10623401B1) in view of Forster et al. (US2022/0379906A1) in view of Mouser et al. (US2016/0082926A1) in view of Copejans (US2010/0287038A1) in further view of Jiang et al. (US10404697B1), hereinafter Yager, Forster, Mouser, Copejans, and Jiang respectively.
Regarding claim 3, (Original) the combination of Yager, Forster, Mouser, and Copejans teaches the vehicle factor authentication system of claim 1 as detailed above.
Yager does not explicitly teach wherein the backend server sends the user answers to the vehicle controller along with a unique code.
However, Jiang more explicitly teaches wherein the backend server sends the user answers along with a unique code (see at least Col. 9 line 67- Col.10 line 3 “authentication module 112 may apply the same hash or encryption function to the user's response and compare the result of the encryption function to the encrypted correct answer.”).
Examiner interprets that backend server is encompassed at least by authentication module 112, user answers is encompassed at least by user's response, and a unique code is encompassed at least by hash or encryption function.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Yager with the teaching of wherein the backend server sends the user answers along with a unique code found in Jiang. One could combine the teachings in order to have a vehicle factor authentication system wherein the backend server sends the user answers to the vehicle controller along with a unique code with a reasonable expectation of success. One would have been motivated to do so in order to protect the privacy if the user (see at least Jiang, Col.9 lines 63-66).
Regarding claim 4, (Original) the combination of Yager, Forster, Mouser, Copejans, and Jiang teaches the vehicle factor authentication system of claim 3 as detailed above.
Yager teaches wherein if the vehicle controller confirms the user answer as correct, a notification is displayed to the user requesting the unique code (see at least Col. 10 lines 25-30 “Based on the answers submitted by the user for the one or more challenge questions, the authentication system 200 may transmit a notification to the mobile device 220 or the authentication user device 212 of whether or not the user is authenticated to access a requested resource.”).
Regarding claim 5, (Original) the combination of Yager, Forster, Mouser, Copejans, and Jiang teaches the vehicle factor authentication system of claim 4 as detailed above.
Yager does not explicitly teach wherein the notification is displayed on the vehicle display.
However, Forster more explicitly teaches wherein the notification is displayed on the vehicle display (see at least [0078] “If the driver selects a correct answer (for example answer 1), the display apparatus 200 can likewise output a corresponding notification 206 ("Correct answer!" or "That was correct") to the driver.”).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Yager with the teaching of wherein the notification is displayed on the vehicle display found in Forster. One could combine the teachings in order to have a vehicle factor authentication system wherein the notification is displayed on the vehicle display with a reasonable expectation of success. One would have been motivated to do so in order to offer a user convenient access to information.
Regarding claim 6, (Original) the combination of Yager, Forster, Mouser, Copejans, and Jiang teaches the vehicle factor authentication system of claim 4 as detailed above.
Yager teaches wherein the notification is displayed on the user electronic device (see at least Col. 10 lines 25-30 “Based on the answers submitted by the user for the one or more challenge questions, the authentication system 200 may transmit a notification to the mobile device 220 or the authentication user device 212 of whether or not the user is authenticated to access a requested resource.”).
Examiner interprets that user electronic device is encompassed at least by mobile device 220.
Regarding claim 13, (Original) the combination of Yager, Forster, Mouser, and Copejans teaches the method of claim 11 as detailed above.
Yager does not explicitly teach further comprising: sending, by the backend server, a unique code with the user provided answers.
However, Jiang more explicitly teaches further comprising: sending, by the backend server, a unique code with the user provided answers (see at least Col. 9 line 67- Col.10 line 3 “authentication module 112 may apply the same hash or encryption function to the user's response and compare the result of the encryption function to the encrypted correct answer.”).
Examiner interprets that backend server is encompassed at least by authentication module 112, user provided answers is encompassed at least by user's response, and a unique code is encompassed at least by hash or encryption function.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Yager with the teaching of further comprising: sending, by the backend server, a unique code with the user provided answers found in Jiang. One could combine the teachings in order to have a method further comprising: sending, by the backend server, a unique code with the user provided answers with a reasonable expectation of success. One would have been motivated to do so in order to protect the privacy if the user (see at least Jiang, Col.9 lines 63-66).
Regarding claim 14, (Original) the combination of Yager, Forster, Mouser, Copejans, and Jiang teaches the method of claim 13 as detailed above.
Yager teaches further comprising: displaying, by the vehicle controller or the backend server, a notification requesting the unique code (see at least Col. 10 lines 25-30 “Based on the answers submitted by the user for the one or more challenge questions, the authentication system 200 may transmit a notification to the mobile device 220 or the authentication user device 212 of whether or not the user is authenticated to access a requested resource.”).
Regarding claim 15, (Original) the combination of Yager, Forster, Mouser, Copejans, and Jiang teaches the method of claim 14 as detailed above.
Yager does not explicitly teach wherein the notification is displayed on the vehicle display by the vehicle controller.
Forster more explicitly teaches wherein the notification is displayed on the vehicle display by the vehicle controller (see at least [0078] “If the driver selects a correct answer (for example answer 1), the display apparatus 200 can likewise output a corresponding notification 206 ("Correct answer!" or "That was correct") to the driver.”).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Yager with the teaching of wherein the notification is displayed on the vehicle display by the vehicle controller found in Forster. One could combine the teachings in order to have a method wherein the notification is displayed on the vehicle display by the vehicle controller with a reasonable expectation of success. One would have been motivated to do so in order to offer a user convenient access to information.
Regarding claim 16, (Original) the combination of Yager, Forster, Mouser, Copejans, and Jiang teaches the method of claim 14 as detailed above.
Yager teaches wherein the notification is displayed on the user channel based on a signal from the backend server (see at least Col. 10 lines 25-30 “Based on the answers submitted by the user for the one or more challenge questions, the authentication system 200 may transmit a notification to the mobile device 220 or the authentication user device 212 of whether or not the user is authenticated to access a requested resource.”).
Examiner interprets that user electronic device is encompassed at least by mobile device 220.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Yager (US10623401B1) in view of Forster et al. (US2022/0379906A1) in view of Mouser et al. (US2016/0082926A1) in view of Copejans (US2010/0287038A1) in further view of Fuchs et al. (US2022/0123570A1), hereinafter Yager, Forster, Mouser, Copejans, and Fuchs respectively.
Regarding claim 8, (Original) the combination of Yager, Forster, Mouser, and Copejans teaches the vehicle factor authentication system of claim 1 as detailed above.
Yager suggests wherein the vehicle signals include all of (i) an odometer reading, (ii) a vehicle tire pressure, and (iii) a vehicle range (see at least Col. 13 line 64 – Col. 14 line 2 “Additional sensors 218 may detect and store data relating to the maintenance of the vehicle 217, such as the engine status, oil level, engine coolant temperature, odometer reading, the level of fuel in the fuel tank, engine revolutions per minute (RPMs), software upgrades, and/or tire pressure.” also see at least Col. 13 lines 39-43 “sensor 218 may detect and store data corresponding to the vehicle's location (e.g., GPS coordinates), time, travel time, speed and direction, rates of acceleration or braking, gas mileage, and specific instances of sudden acceleration, braking, swerving, and distance traveled.”).
However, Fuchs more explicitly teaches wherein the vehicle signals include all of (i) an odometer reading, (ii) a vehicle tire pressure, and (iii) a vehicle range (see at least [0080]-[0088] “The vehicle communication systems disclosed or referenced herein may provide vehicle health data to remote devices or the cloud for storage. Exemplary information is provided by one or more of the vehicle systems or sensors supported on the vehicle 100. Exemplary information includes:...Fuel Range...Odometer...Tire Pressures Front (if equipped w/TPMS)...Tire Pressure Rear (if equipped w/TPMS)”).
Examiner interprets that odometer reading is encompassed at least by odometer, a vehicle tire pressure is encompassed at least by Tire Pressures Front (if equipped w/TPMS) and/or Tire Pressure Rear (if equipped w/TPMS), and a vehicle range is encompassed at least by Fuel Range.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the suggested teaching of Yager of wherein the vehicle signals include all of (i) an odometer reading, (ii) a vehicle tire pressure, and (iii) a vehicle range with the more explicit teaching of the same found in Fuchs with a reasonable expectation of success. One would have been motivated to do so in order to diversify the possibility in the random questions about vehicle signals and thus further improve vehicle security.
Regarding claim 18, (Original) the combination of Yager, Forster, Mouser, and Copejans teaches the method of claim 11 as detailed above.
Yager suggests wherein the vehicle signals include all of (i) an odometer reading, (ii) a vehicle tire pressure, and (iii) a vehicle range (see at least Col. 13 line 64 – Col. 14 line 2 “Additional sensors 218 may detect and store data relating to the maintenance of the vehicle 217, such as the engine status, oil level, engine coolant temperature, odometer reading, the level of fuel in the fuel tank, engine revolutions per minute (RPMs), software upgrades, and/or tire pressure.” also see at least Col. 13 lines 39-43 “sensor 218 may detect and store data corresponding to the vehicle's location (e.g., GPS coordinates), time, travel time, speed and direction, rates of acceleration or braking, gas mileage, and specific instances of sudden acceleration, braking, swerving, and distance traveled.”).
However, Fuchs more explicitly teaches wherein the vehicle signals include all of (i) an odometer reading, (ii) a vehicle tire pressure, and (iii) a vehicle range (see at least [0080]-[0088] “The vehicle communication systems disclosed or referenced herein may provide vehicle health data to remote devices or the cloud for storage. Exemplary information is provided by one or more of the vehicle systems or sensors supported on the vehicle 100. Exemplary information includes:...Fuel Range...Odometer...Tire Pressures Front (if equipped w/TPMS)...Tire Pressure Rear (if equipped w/TPMS)”).
Examiner interprets that odometer reading is encompassed at least by odometer, a vehicle tire pressure is encompassed at least by Tire Pressures Front (if equipped w/TPMS) and/or Tire Pressure Rear (if equipped w/TPMS), and a vehicle range is encompassed at least by Fuel Range.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the suggested teaching of Yager of wherein the vehicle signals include all of (i) an odometer reading, (ii) a vehicle tire pressure, and (iii) a vehicle range with the more explicit teaching of the same found in Fuchs. One could combine the teachings in order to have a method wherein the vehicle signals include all of (i) an odometer reading, (ii) a vehicle tire pressure, and (iii) a vehicle range with a reasonable expectation of success. One would have been motivated to do so in order to diversify the possibility in the random questions about vehicle signals and thus further improve vehicle security.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Yager (US10623401B1) in view of Forster et al. (US2022/0379906A1) in view of Mouser et al. (US2016/0082926A1) in view of Copejans (US2010/0287038A1) in further view of Subramanian et al. (US2023/0089891A1), hereinafter Yager, Forster, Mouser, Copejans, and Subramanian respectively.
Regarding claim 19, (Currently Amended) the combination of Yager, Forster, Mouser, and Copejans teaches the method of claim 11 as detailed above.
Yager suggests wherein the vehicle must be on in order to initiate the of the vehicle (see at least Col. 3 lines 9-13 “the authentication system may receive and store telematics data collected from a user's vehicle while the user is driving and utilize the telematics data to generate one or more questions for authenticating the user to access one or more computing resources.”).
Subramanian more explicitly teaches wherein the vehicle must be on in order to initiate the of the vehicle (see at least [0132] “The method of working of the signal-based authentication system for electromechanical devices, comprising of the following steps...The start-up unit is switched on. An authentication code/image input is requested to be entered in the user device configured in the device.” and [0139] “e) Upon start of equipment, accept authentication from operator/signal device/master device.”).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the suggested teaching of Yager of wherein the vehicle must be on in order to initiate the factor authentication of the vehicle with the more explicitly teaching of the same found in Subramanian. One could combine the teachings in order to have a method wherein the vehicle must be on in order to initiate the factor authentication of the vehicle with a reasonable expectation of success. One would have been motivated to do so in order to provide continuous vehicle security.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hu et al. (US2018/0322603A1) Discloses a vehicle management method, system and server, and a vehicle. The vehicle management method comprises: acquiring by a client device a vehicle identification; receiving by a vehicle management server an authentication request from the client device, the authentication request including the vehicle identification and a user identification of the client device; authenticating by the vehicle management server the vehicle identification and the user identification to permit a continuously available state of the vehicle; sending by the vehicle management server a use permission of the continuously available state to a vehicle; and receiving by the vehicle the use permission to continue its available state.
Nakagawa (US2022/0274552A1) Discloses a method for granting access to vehicle functionalities. The method includes receiving a signal from a device that is external to the vehicle, the signal including identification data of an object associated with the device, comparing the identification data with user identifications stored in the memory of the vehicle, and granting, to the object, access to a first set of functionalities of the vehicle in response to determining that the identification data matches a first user identification of the user identifications stored in the memory of the vehicle.
Sherif et al. (US2020/0267143A1) Discloses multi-factor authentication systems and methods that include receiving a request to authenticate a user of a mobile device. The request for authentication may include credential information associated with the user and vehicle data. A determination may be made regarding whether the vehicle data was obtained from a vehicle via the mobile device. The received vehicle data and received credential information may be compared to stored data. When there is a match between the received vehicle data and received credential information and corresponding stored data, a notification may be provided to the user device, indicating that the user has been authenticated.
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 ALYSSA N RORIE whose telephone number is (571)272-6962. The examiner can normally be reached Monday - Friday (out of office every other Friday) 7:30 am - 5:00 pm.
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, Jelani Smith can be reached at 571-270-3969. 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.
/A.R./Examiner, Art Unit 3662
/JELANI A SMITH/Supervisory Patent Examiner, Art Unit 3662
Prosecution Insights