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 .
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-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter because they recite a system with no tangible parts.
Per MPEP 2106.03, “[p]roducts that do not have a physical or tangible form” are not directed to any statutory category. For example, a machine is “a concrete thing, consisting of parts, or of devices and combination of devices,” a manufacture is “a tangible article . . . given new form,” and a composition of matter comprises multiple substances in combination with one another. MPEP 2106.03. While a product claim need not fit one specific category of invention to fall into one of the statutory categories, it must “fall . . . into at least one category.” Id..
Claims 1-19 fail to positively recite any limitations that cause the claims to fall into a statutory category. All recited elements that could be considered tangible or concrete are not mentioned in the body of the claim itself. Therefore, the control system of claim 1 does not represent anything tangible or concrete, preventing it from fitting into any of the statutory categories.
In the interest of compact prosecution, the examiner notes that moving components of the system out of the preamble and positively reciting that the system comprises tangible components appears to overcome the §101 rejection.
For further explanation, the examiner notes that independent claims 22-23 are directed to statutory categories. By claiming a mobile device comprising the control system that performs various actions, claim 22 claims a concrete thing, a mobile device, that fits the claim into the “machine” statutory category. By claiming a non-transitory computer readable medium storing a set of instructions that causes the various actions to occur, claim 23 claims a tangible article given a new form (various materials structured into a non-transitory computer readable medium) that fits the claim into the “manufacture” statutory category.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3, 5, 8, 10, 17, 19, and 22-23 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 20150148990 A1 to Patel, Dipam (“Patel”).
Regarding claim 1, Patel discloses a control system for use at a mobile device to control a digital key system of a vehicle (Patel Claim 1: “A mobile telephone comprising: an executable program which enables said mobile telephone to control a remote keyless system and onboard computer installed on an automobile . . ..”), wherein the digital key system is implemented according to a predetermined vehicle digital key specification (Patel [0021]: “In a preferred embodiment, the remote keyless system uses the Bluetooth protocol to communicate with its remote controllers. . . . Bluetooth uses frequency-hopping spread spectrum to split up the data being sent into packets, optionally encrypts the data using at least one encryption algorithm, and transmits the packets on up to 79 frequencies on the 2.4 GHz radio frequency bandwidth.”) to enable one or more vehicle functions to be performed at the vehicle without using a physical key for the vehicle (Patel [0022]: Understood that a remote keyless system does not require a key to perform vehicle functions.), and wherein the control system, when executed by a processor of the mobile device, is arranged to:
communicate, in accordance with the predetermined vehicle digital key specification, with the digital key system via at least one short range communication protocol to cause performance of at least one of the one or more vehicle functions (Patel [0021]: “In this case, a Bluetooth-capable mobile telephone is loaded with an executable program that enables the telephone to communicate with and control the remote keyless system.”; Patel [0023]: “In one embodiment, the executable program comprises a number of virtual toggle switches and slide bars which allow the user to manipulate any of the various functions of the automobile.”); and
provide a secured software runtime environment at the mobile device for the control system to perform one or more secured operations (Patel [0021]: Environment where encryption is performed in the software taken as the runtime environment. Performance of encrypted communication taken as a secured operation.), the one or more secured operations including the control system acting as a software root of trust, in accordance with the predetermined vehicle digital key specification (Patel [0021]: “Bluetooth uses frequency-hopping spread spectrum to split up the data being sent into packets, optionally encrypts the data using at least one encryption algorithm, and transmits the packets on up to 79 frequencies on the 2.4 GHz radio frequency bandwidth.” Encryption algorithm understood as being aboard the mobile device and the keyless system. The algorithm taken as a software root of trust, in accordance with the Bluetooth protocol.), for performance of at least one of the one or more vehicle functions (Patel [0021]: “ . . . the remote keyless system uses the Bluetooth protocol to communicate with its remote controllers.” Understood that commands given from the remote controllers to control the vehicle’s various functions are given over Bluetooth.).
Regarding claim 2, Patel discloses the control system of claim 1, wherein the control system is arranged to perform the one or more secured operations independent of any keyless vehicle control functionality provided by a manufacture of the mobile device (Patel [0023]: “ . . . a slide bar controls the interior temperature of the automobile by manipulating the air conditioning and heating system settings.”.).
Regarding claim 3, Patel discloses the control system of claim 1, wherein the control system is arranged to perform the one or more secured operations independent of any keyless vehicle control functionality provided as part of an operating system of the mobile device (Patel [0017]: “The mobile telephone of the present invention is a mobile telephone with an application installed on it that allows the user of the mobile telephone to interact with a remote keyless system . . ..” Understood that an executable application is not part of the operating system of a mobile device. See [0017], where Patel discloses that an operating system may run applications programmed by another developer. Such a distinction is taken as the operating system of the smartphone not containing keyless vehicle control functionality alone.).
Regarding claim 5, Patel discloses the control system of claim 1,wherein the secured software runtime environment is provided based on one or more of:
(a) the control system being implemented, at least in part, using whitebox cryptography for (i) securing storage of some or all of the data used for the control of the digital key system;
and/or (ii) securing some or all of the instructions used to implement the control system;
(b) the control system being implemented, at least in part, using obfuscation of one or more of: (i) instructions used to implement the control system; (ii) control flow for the control system; and (iii) runtime data of the control system (Patel [0021]: Data sent/received by the application implemented on the mobile device to control the vehicle keyless system taken as runtime data of the control system. It is obfuscated by merit of being encrypted.);
(c) the control system comprising one or more secure storage functions for performing secure storage of one or more cryptographic keys and/or sensitive data;
(d) the control system being arranged to perform node locking to lock execution of the control system to the mobile device;
(e) the control system being arranged to perform integrity verification for the control system and/or the digital key system; and
(f) the control system being arranged to perform anti-debug functionality.
Regarding claim 8, Patel discloses the control system of claim 1, wherein the predetermined vehicle digital key specification specifies one or more protocols and/or one or more functions and/or one or more requirements that enable the one or more vehicle functions to be performed at the vehicle without using a physical key for the vehicle (Patel [0021]: Bluetooth taken as the one or more protocols. Encryption key knowledge taken as the one or more requirements.).
Regarding claim 10, Patel discloses the control system of claim 1, wherein the one or more vehicle functions comprises one or more of:
(a) physical unlocking and/or physical locking of at least a part of the vehicle (Patel [0023]: “Toggle switches are capable of controlling . . . the door locks . . ..”);
(b) physical opening and/or physical closing of at least a part of the vehicle (Patel [0022]: Operation of window movement systems understood as systems that open or close the windows.);
(c) starting and/or stopping an engine or a motor of the vehicle (Patel [0023]: “Toggle switches are capable of controlling the engine ignition system . . ..”); and
(d) operating an auxiliary system of the vehicle (Patel [0022]: Functions like lights, air conditioning, heating, video and so on taken as auxiliary systems of the vehicle.).
Regarding claim 17, Patel teaches the control system of claim 1, wherein the one or more secured operations include one or more of:
(a) authenticating an identity of the vehicle and/or an identity of the digital key system in accordance with the predetermined vehicle digital key specification (Patel [0020]: “In another embodiment, the executable program improves on previous remote keyless systems by providing a means for "two-way" authentication and identification, where both the remote keyless system and mobile telephone satisfy predetermined authentication requirements . . . .”);
(b) enabling the digital key system to authenticate an identity of the mobile device and/or an identity of the control system in accordance with the predetermined vehicle digital key specification;
(c) sharing a digital key secured, at least in part, by the control system with another mobile device;
(d) digital key management for one or more cryptographic keys used in accordance with the predetermined vehicle digital key specification; and
(e) secured storage of data used for performance of at least one of the one or more vehicle functions.
Regarding claim 19, Patel teaches the control system of claim 1, wherein the mobile device is a smartphone (Patel [0016]: “In a preferred embodiment, the mobile telephone is a mobile smartphone . . . .”).
Claim 22 is rejected over similar reasons to claim 1, applied to a mobile device comprising a control system.
Claim 23 is rejected over similar reasons to claim 1, applied to a non-transitory computer readable medium.
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 4, 6, 7, and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Patel, and further in view of US 20170105120 A1 to Kang, Jong et al. (“Kang”).
Regarding claim 4, Patel teaches the control system of claim 1.
While teaching a method of secure wireless control of a vehicle using a Bluetooth-enabled smartphone, Patel does not appear to expressly teach wherein the control system is arranged to perform the one or more secured operations without using a secure element of the mobile device for: (a) storage of data used for the control of the digital key system; and (b) execution of instructions for implementing the control of the digital key system.
However, Kang teaches wireless control of a vehicle from a smartphone using NFC instead of Bluetooth (See FIG. 1).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present invention to have combined the system for wireless control of vehicles using Bluetooth taught by Patel with the system for wireless control of vehicles using NFC taught by Kang. Doing so would have “provide[d] an efficient security solution in order to integrate communication among various devices for a technological trend such as IoT” as suggested in [0027] of Kang.
Kang further teaches wherein the control system is arranged to perform the one or more secured operations without using a secure element of the mobile device for: (a) storage of data used for the control of the digital key system (Kang [0075]: “Embodiments of the present invention propose a plan that uses HCE (Host Card Emulation) and TEE (Trusted Execution Environment) to solve the problem due to a property right and safely implement a vehicle entrance/start secure logic through a smartphone application.”; Kang [0078]: “The TEE is a method of prevents a common developer from access to a corresponding portion by opening a safety security OS area in a CPU itself. When a key, a secure algorithm and the like are implemented in the security OS portion, it is possible to solve security problems without using an SE.”); and (b) execution of instructions for implementing the control of the digital key system.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present invention to have further combined the NFC-based communication control system of the above combination of Patel and Kang with the TEE for exchanging encryption keys further taught by Kang. Doing so would have eliminated “defects of delay due to every connection to a cloud authentication server and unavailability due to disconnection from a cloud authentication server” that come along with using a secure element as taught in [0077] in Kang.
Regarding claim 6, Patel teaches the control system of claim 1.
Patel does not appear to expressly teach wherein the control system is arranged to cause data received from the vehicle via the at least one short range communication protocol to be routed to the control system instead of being routed to a secure element of the mobile device.
However, Kang teaches wireless control of a vehicle from a smartphone using NFC instead of Bluetooth (See FIG. 1).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present invention to have combined the system for wireless control of vehicles using Bluetooth taught by Patel with the system for wireless control of vehicles using NFC taught by Kang. Doing so would have “provide[d] an efficient security solution in order to integrate communication among various devices for a technological trend such as IoT” as suggested in [0027] of Kang.
Kang further teaches wherein the control system is arranged to cause data received from the vehicle via the at least one short range communication protocol to be routed to the control system instead of being routed to a secure element of the mobile device (Kang [0075]: “Embodiments of the present invention propose a plan that uses HCE (Host Card Emulation) and TEE (Trusted Execution Environment) to solve the problem due to a property right and safely implement a vehicle entrance/start secure logic through a smartphone application.”; Kang [0078]: “The TEE is a method of prevents a common developer from access to a corresponding portion by opening a safety security OS area in a CPU itself. When a key, a secure algorithm and the like are implemented in the security OS portion, it is possible to solve security problems without using an SE.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present invention to have further combined the NFC-based communication control system of the above combination of Patel and Kang with the TEE for exchanging encryption keys further taught by Kang. Doing so would have eliminated “defects of delay due to every connection to a cloud authentication server and unavailability due to disconnection from a cloud authentication server” that come along with using a secure element as taught in [0077] of Kang.
Regarding claim 7, the above combination of Patel and Kang teaches the control system of claim 6, wherein the control system is arranged perform host card emulation to enable communication of said data from a transceiver of the mobile device that implements the at least one short range communication protocol to the control system (Kang [0079]: “Embodiments of the present invention provide a security technology using HCE and TEE to implement a vehicle entrance/start function using the smartphone 210 and the NFC module 220 in a vehicle control system.”).
Regarding claim 11, Patel teaches the control system of claim 1.
While teaching wireless control of the vehicle using Bluetooth, Patel does not appear to expressly teach wherein the at least one short range communication protocol comprises at least one of: a near field communication (NFC) protocol; a Bluetooth Low Energy (BTLE) protocol; and an Ultra- Wideband (UWB) protocol.
However, Kang teaches wherein the at least one short range communication protocol comprises at least one of: a near field communication (NFC) protocol (Kang FIG. 1); a Bluetooth Low Energy (BTLE) protocol; and an Ultra- Wideband (UWB) protocol.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present invention to have combined the system for wireless control of vehicles using Bluetooth taught by Patel with the system for wireless control of vehicles using NFC taught by Kang. Doing so would have “provide[d] an efficient security solution in order to integrate communication among various devices for a technological trend such as IoT” as suggested in [0027] of Kang.
Claims 9 and 12-15 are rejected under 35 U.S.C. 103 as being unpatentable over Patel, and further in view of US 20210058252 A1 to Jung, Sooyeon et al. (“Jung”).
Regarding claim 9, Patel teaches the control system of claim 1.
Patel does not appear to expressly teach wherein the predetermined vehicle digital key specification is one of: (a) a Car Connectivity Consortium specification; and (b) an Intelligent Car Connectivity Industry Ecosystem Alliance specification.
However, Jung teaches wherein the predetermined vehicle digital key specification is one of: (a) a Car Connectivity Consortium specification; and (b) an Intelligent Car Connectivity Industry Ecosystem Alliance specification (Jung [0091]: “The transaction may denote the mutual authentication procedure using the digital key between the vehicle 400 and the digital key applet 321 of the electronic device 300, which is defined in the car connectivity consortium (CCC) standard.” See for example Jung [0092]-[0093], digital key operations like an RKE session are disclosed as derived from the CCC specification transaction of s301.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present invention to have combined the system for wireless control of a vehicle’s key system taught by Patel with the system for wireless control of a vehicle’s key system per the Car Connectivity Consortium taught by Jung. Doing so would have provided a common standard for connecting to and controlling a vehicle wirelessly, improving the control system’s versatility by allowing it to connect to any compatible vehicles.
Regarding claim 12, Patel teaches the control system of claim 1.
Patel does not appear to expressly teach wherein the control system acting as the software root of trust comprises the control system:
storing one or more cryptographic keys; and
using the one or more cryptographic keys to authenticate one or more digital signatures and/or to issue one or more digital certificates.
However, Jung teaches wherein the control system acting as the software root of trust comprises the control system:
storing one or more cryptographic keys (Jung [0083]: “Here, a digital key may be used for transmission and reception of encrypted data and for secure ranging.”); and
using the one or more cryptographic keys to authenticate one or more digital signatures and/or to issue one or more digital certificates (Jung [0096]: “ . . . the electronic device 101 accesses the secure element 107 and signs (e.g., needs to access and sign) by using a digital key stored in the secure element 107 whenever a remote control command is transmitted to the vehicle 103.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present invention to have combined the control system controlling vehicle functions wirelessly taught by Patel with the control system that stores a digital key for transmission and reception of encrypted data and signs using that key taught by Jung. Doing so would have improved system accessibility while maintaining security by allowing those with the digital key to access the vehicle controls.
Regarding claim 13, Patel teaches the control system of claim 1.
Patel does not appear to expressly teach wherein the control system exposes an API configured for receiving, from an application that is user- installable on the mobile device, a command for the control system to cause performance of at least one of the one or more vehicle functions.
However, Jung teaches wherein the control system exposes an API configured for receiving, from an application that is user- installable on the mobile device, a command for the control system to cause performance of at least one of the one or more vehicle functions (Jung FIG. 4B: The framework 310, disclosed as an API in [0080] of Jung, depicted as where user commands are input, then sent to the vehicle 400. Understood that the control systems expose the API by allowing it to receive user commands. Taken in combination with Patel above, one of ordinary skill in the art would have recognized that the user-installable application for vehicle control of Patel would have exposed the API of Jung.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present invention to have combined the system for wireless control of a vehicle taught by Patel with the system for wireless control of a vehicle that exposes an API for controlling the vehicle taught by Jung. Doing so would have increased the versatility of the control system by allowing it to be accessed by many kinds of external entities as suggested in for example [0081] of Jung.
Regarding claim 14, the above combination of Patel and Jung teaches the control system of claim 13, wherein the command is based on input provided to the application by a user of the mobile device (Patel [0017]: “The mobile telephone of the present invention is a mobile telephone with an application installed on it that allows the user of the mobile telephone to interact with a remote keyless system . . . .”).
Regarding claim 15, the above combination of Patel and Jung teaches the control system of claim 13, wherein the application is a native application for the mobile device (Patel [0016], [0017]: Understood a native application is one that is downloaded and run on a device.).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Patel in view of US 20210058252 A1 to Jung, Sooyeon et al. (“Jung”), further in view of US 20190215370 A1 to Granda, Shawn et al. (“Granda”)
Regarding claim 16, the above combination of Patel and Jung teaches the control system of claim 13.
This combination does not appear to expressly teach wherein the application is provided, at least in part, by a manufacturer of the vehicle.
However, Granda teaches wherein the application is provided, at least in part, by a manufacturer of the vehicle (Granda [0039]: “The mobile device processor and software stored in the memory enable various software applications, which may be preinstalled or installed by the user (or manufacturer) (e.g., having a software application or graphical user interface (GUI)). This may include an application 92 that can allow a vehicle user to communicate with vehicle 12 and/or to control various aspects or functions of the vehicle—e.g., among other things, allowing the user to remotely lock/unlock vehicle doors, turn the vehicle ignition on or off, check the vehicle tire pressures, fuel level, oil life, etc.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present invention to have combined the system for wireless control of a vehicle using a smartphone app taught by the above combination of Patel and Jung with the system for wireless control of a vehicle using a smartphone app installed by a vehicle manufacturer taught by Granda. Doing so would have improved compatibility of the app with a particular vehicle by ensuring it comes from the same manufacturer of the vehicle.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Patel in view of US 20210058252 A1 to Jung, Sooyeon et al. (“Jung”), further in view of US 20170311161 A1 to Kuenzi, Adam (“Kuenzi”).
Regarding claim 18, Patel teaches the control system of claim 1.
Patel does not appear to expressly teach wherein the control system, when executed by the processor of the mobile device, is arranged to bind with the vehicle, said binding controlled by a server in communication with the control system.
However, Kuenzi teaches a system for wirelessly controlling a lock from a smartphone (see [0053]), wherein the control system, when executed by the processor of the mobile device, is arranged to bind with the vehicle, said binding controlled by a server in communication with the control system (Kuenzi [0045]: “ . . . a credential representative of data that would normally be physically encoded on the key card 92 is retrieved in a digital form (step 110), encapsulated in an encrypted credential (step 112), downloaded to the mobile device 12 (step 114), securely passed to the credential module 36 (step 116) that decrypts and validates the credential (step 118), extracts the virtual card data (step 120), then passes the virtual card data into the lock controller 24 as a “virtual card read” (step 122). . . . The encrypted credential may be generated by the server 14 using well known techniques for digital certificate creation and encryption using cryptographic algorithms such as AES, ECC, RSA, and the like.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present invention to have combined the system for wireless control of a vehicle that uses encryption taught by Patel with the system that downloads an encryption key from a server for wireless control taught by Kuenzi. Doing so would have allowed permission to access encrypted controls to be given or revoked remotely, improving user convenience.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Gao, Yansong. US 20250136047 A1. Systems and Methods for Keyless Operation.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HENRY RICHARD HINTON whose telephone number is (703)756-1051. The examiner can normally be reached Monday-Friday 7:30-4:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hunter Lonsberry can be reached at (571) 272-7298. 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.
/HENRY R HINTON/ Examiner, Art Unit 3665
/HUNTER B LONSBERRY/ Supervisory Patent Examiner, Art Unit 3665