DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Claims 1-9 are presented for examination on the merits.
Claim Rejections – 35 USC § 101
2. 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.
3. Claims 1-9 rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1: Claim 1-9 are directed to a computer system and non-transitory computer readable medium and thus fall within the statutory categories of machine and manufacture.
Step 2A: Prong one: Judicial exception,
Claims 1-9 are directed to the abstract idea of credential authorization and provisioning using multiple computer systems, with is a form of identity verification and access control.
The claim recites:
receiving a request to provision a secure credential,
initiating a provisioning process,
prompting for authorization via a second computer system,
receiving credential information upon authorization, and
provisioning the computer system with the credential to enable use of vehicle function.
These limitations describe managing authorization and credential transfer between entities. Such activity constitutes certain methods of organizing human activity, including security interactions and access control, which are abstract ideas.
Accordingly, the claims recite an abstract idea.
Step 2A: Prong Two: No integration into a practical application:
The additional elements beyond the abstract idea include:
a computer system
one or more processors
memory storing program
a second computer system, and
generic communication with input device,
These elements are recited at a high level of generality and perform their typical functions of receiving, processing, transmitting, and storing data. The claim do not recite any specific improvement to the computer functionality, networking technology, vehicle systems, or security
architecture. Nor do the claims recite any particular cryptographic technique, hardware-based security mechanism, or specialized data structure. The claims merely use generic computer
components as tools to implement the abstract idea. Therefore, the judicial exception is not integrated into a practical application.
Step 2B: No Invention concept
The additional elements, considered individually and as an ordered combination, amount to no more than well understood, routine, and conventional computer activities, such as:
receive data
prompting for authorization,
transmitting credential information, and
storing and provisioning credentials.
Implementing an abstract idea using generic computer components does not amount to significantly more than the abstract idea itself.
There is no indication in the claims that the recited computer components operate in an unconventional manner or that the ordered combination improves the functioning of the computer or another technology.
Therefore, claims 1-9 are directed to an abstract idea and do not include additional elements that amounts to significantly more than the judicial exception. Accordingly, Claims 1-9 are rejected under U.S.C. § 101.
Claim Rejections – 35 USC § 112
4. The following is a quotation of the second paragraph of 35 U.S.C. 112:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
5. Applicant’s claim 3 includes a negative limitation. The boundaries of the patent protection sought are not set forth definitely. The claim limitation in claim 3 includes “one or more functions of the vehicle does not include communication with the vehicle” are critical of negative{e limitations because it tended to define the invention in terms of what it was not, rather than pointing out the invention.
Any negative limitation or exclusionary proviso must have basis in the original disclosure. If alterna-tive elements are positively recited in the specifica-tion, they may be explicitly excluded in the claims. See In re Johnson, 558 F.2d 1008, 1019, 194 USPQ 187, 196 (CCPA 1977) (“[the] specification, having described the whole, necessarily described the part remaining.”). See also Ex parte Grasselli, 231 USPQ 393 (Bd. App. 1983), aff’d mem., 738 F.2d 453 (Fed. Cir. 1984). The mere absence of a positive recitation is not basis for an exclusion.
Claim Rejections - 35 USC § 103
6. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
7. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
8. Claim 1-9 are rejected under 35 U.S.C. 103 as being unpatentable over Xu (US 20250083640 A1).
As to claim 1, Xu discloses in unified cloud between a fleet of heterogeneous vehicles and the vehicles' cloud services for providing a unified user interface to remotely control the fleet of vehicles having claimed:
a. a computer system configured to communicate with one or more input devices, comprising: one or more processors; and memory storing one or more programs configured to be executed by the one or more processors, the one or more programs including instructions for: during a setup process of the computer system read on ¶ 0007, (a non-transitory computer-readable storage medium storing one or more programs configured to be executed by one or more processors of a computer system that is in communication with one or more input devices, and one or more display generation components is described. In some embodiments, the one or more programs includes instructions for: displaying, via the one or more display generation components, a user interface including a first user interface element and a second user interface element different from the second user interface element; while displaying the first user interface element and the second user interface element, detecting, via the one or more input devices, an input corresponding to a respective user interface element; and in response to detecting the input corresponding to the respective user interface element);
b. receiving, via the one or more input devices, a request to provision the computer system with a secure credential that is configured to provide authorization to use one or more functions of a vehicle read on ¶ 0050 & ¶ 0051, (the first phase is an initialization phase 400, during which the vehicles are registered at step 402, vehicle's corresponding cloud APIs are triggered at step 404 to generate vehicle keys at step 406, various vehicle APIs are collected at step 407 and mapped to a set of unified APIs at step 408. The unified APIs may be exposed to the users as a graphic user interface (GUI). For example, the unified cloud may build a set of unified APIs in which each API may trigger multiple APIs of multiple vehicle clouds according to the vehicle's type or model. After the initialization phase 400, two service phases 410 and 420 may be implemented. During the service phase 1 410, a user may send a request (e.g., a rental request or a lease request) for a vehicle at step 412 using the unified API of the unified cloud);
c. in response to receiving the request to provision the computer system with a secure credential that is configured to provide authorization to use one or more functions of the vehicle, initiating a process to provision the computer system with a secure credential that is configured to provide authorization to use one or more functions of the vehicle wherein as part of the process a second computer system, different from the computer system, that is provisioned with a secure credential that is configured to provide authorization to use one or more functions of the vehicle read on ¶ 0051, (If the requested vehicle is available, it generates a digital user-token at step 414. The digital user-token is uniquely associated with the user's account. In some embodiments, a valid time window may be configured for the digital user-token based on the requested time window. The valid time window may be in a form of time stamp and embedded into the digital user-token. For example, the valid time window may be appended to the digital user-token, e.g., a hash value generated for the user account. The digital user-token may be mapped to the digital vehicle-key of the requested vehicle at step 416, indicating the user account possessing the digital user-token can remotely access and manage the requested vehicle through the digital vehicle-key. One user account may possess multiple digital user-tokens for managing multiple vehicles),
d. prompts for authorization to provide credential information corresponding to the vehicle to the computer system read on ¶ 0052, (the digital user-token may be signed with a private key of the unified cloud. The digital user-token may be bound to the user's smart device such that only the user's smart device can use such digital user-token (e.g., not allowing other means of using the digital user-token). When the user's device receives the user-token, it may authenticate the digital user-token with a public key of the unified cloud at step 418)
in some embodiments:
e. receiving, as part of the process to provision the computer system with a secure credential that is configured to provide authorization to use one or more functions of the vehicle, credential information from the second computer system based on the second computer system receiving authorization to provide the credential information to the computer system; and provisioning, using the credential information, the computer system with a secure credential that is configured to provide authorization to use one or more functions of the vehicle read on ¶ 0053 & ¶ 0054, (the service phase II 420 includes how a user remotely manages the requested vehicle. In some embodiments, the user may send one or more user-commands (such as unlocking or locking doors, turning on or off AC or windows) for managing the vehicle through the unified APIs of the unified cloud at step 422. The user-commands may be generated by the user triggering one or more of the pluralities of unified APIs, and one of the one or more unified APIs comprises a parameter for specifying the digital user-token for the unified cloud to authenticate the user-commands. In some cases, the unified cloud may decode the user-commands to extract the valid time window of the digital user-token, and validate the user-commands based on the valid time window. If the digital user-token is expired, the unified cloud may return an error message to the user indicating invalid operations. If the digital user-token is valid, the unified cloud may determine the vehicle information from the user-commands, and retrieve corresponding vehicle-cloud APIs and encryption scheme at step 424. Then the unified cloud may construct vehicle control commands based on the user-commands using the retrieved APIs and encryption algorithms at step 426. In some embodiments, the vehicle-cloud APIs may include HTTP requests, such as one or more of GET, POST, PUT, DELETE with a payload based on the one or more user-commands. These HTTP requests may then be transmitted to the corresponding vehicle-cloud for control the vehicle at step 428. Here, the “unified cloud” performing the above-described steps refer to one or more computing devices associated with the unified cloud).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the techniques for managing accessories of Xu in order to provide digital vehicle keys obtained through the corresponding vehicle clouds, and each vehicle key may be mapped to one unique digital token of a corresponding vehicle and one digital token of the vehicle mapped to one or more digital vehicle keys. These vehicle keys allow the unified cloud, acting as an owner of the vehicles, to remotely mange the vehicles by sending vehicle management commands through corresponding vehicle clouds.
As to claim 2, Xu further discloses:
a. the one or more programs further including instructions for: during the setup process of the computer system: receiving, via the one or more input devices, account credentials corresponding to a first user of a service; and logging into the service, using the account credentials, as the first user; wherein the request to provision the computer system with a secure credential that is configured to provide authorization to use one or more functions of a vehicle is received while logged into the service as the first user; and wherein the second computer system is logged into the service as the first user read on ¶ 0007 & ¶ 0034 and ¶ 0046, the techniques described herein relate to a method, wherein the generating the digital user-token includes: signing the digital user-token using a private key of the computing device, such that the digital user-token is verifiable by the user using a public key of the computing device. The user-commands may identify the unique digital token of the vehicle as the target vehicle and be authenticated (signed) by the digital vehicle-key. When the vehicle cloud receives the user-commands, it identifies the vehicle based on the unique digital token and decodes the user-commands to manage the vehicle accordingly. When a user requests for a vehicle managed by the unified cloud 300 (or the entity manages the unified cloud), the request may be received from the user's account logged in on a smart phone or computer. The user-token generating module 310 may be configured to generate a digital user-token based on the request and transmit the digital user-token back to the user's account. The digital user-token may be generated using a cryptographic hash function. This digital user-token is different from the digital vehicle-keys owned by the unified cloud 300 and the digital vehicle-tokens of the vehicles. The digital user-token is a unique string that is allocated for the user account for authenticating further user-commands sent from the user account. If the vehicle requested by the user is available, the digital user-token is mapped to the digital vehicle-key of the vehicle by the token mapping module 320).
As to claim 3, Xu further discloses:
a. wherein provisioning, using the credential information, the computer system with the secure credential that is configured to provide authorization to use one or more functions of the vehicle does not include communication with the vehicle read on ¶ 0036, (FIG. 2 illustrates an example system diagram of the unified cloud for managing vehicles from different vehicle clouds, in accordance with some embodiments. As shown, the unified cloud 210 provides a unified user interface to the user 200, allowing the user 200 to access different vehicle cloud services 220, 222, and 224 that respectively manage different models/types of vehicles. With the unified cloud 210, the user 200 does not need to install different applications corresponding to the vehicle cloud services 220, 222, and 224. Note: user 200 does not communicate with vehicle).
As to claim 4, Xu further discloses:
a. wherein provisioning, using the credential information, the computer system with the secure credential that is configured to provide authorization to use one or more functions of the vehicle occurs independent of the computer system being within range of the vehicle read on ¶ 0020, (he techniques described herein relate to a system including one or more processors and one or more non-transitory computer-readable memories coupled to the one or more processors and configured with instructions executable by the one or more processors to cause the system to perform operations including: obtaining a plurality of digital vehicle-keys corresponding to a plurality of vehicles, wherein the plurality of vehicles are registered with a plurality of vehicle-clouds associated with the plurality of vehicles and allow remotely controlling the vehicles through the plurality of vehicle-clouds; obtaining a plurality of sets of APIs corresponding to the plurality of vehicle-clouds associated with the plurality of vehicles; receiving a first request for a vehicle from a user; generating a digital user-token based on the request and transmitting the digital user-token to the user; mapping the digital user-token and the digital vehicle-key of the vehicle; receiving a second request from the user including the digital user-token and one or more user-commands for managing the vehicle; retrieving the digital vehicle-key of the vehicle based on the digital user-token in the second request; constructing one or more vehicle commands based on the one or more user-commands using the set of APIs of the vehicle-cloud associated with the vehicle; and transmitting the digital vehicle-key of the vehicle and the one or more vehicle commands to a vehicle-cloud corresponding to the vehicle for managing the vehicle according to the one or more vehicle commands).
As to claim 5, Xu further discloses:
a. wherein during the process to provision the computer system with a secure credential that is configured to provide authorization to use one or more functions of the vehicle, one or more credentials configured to provide authorization to use one or more functions of the vehicle are removed from the second computer system read on ¶ 0054 -0055, (Then the unified cloud may construct vehicle control commands based on the user-commands using the retrieved APIs and encryption algorithms at step 426. In some embodiments, the vehicle-cloud APIs may include HTTP requests, such as one or more of GET, POST, PUT, DELETE with a payload based on the one or more user-commands. These HTTP requests may then be transmitted to the corresponding vehicle-cloud for control the vehicle at step 428. Here, the “unified cloud” performing the above-described steps refer to one or more computing devices associated with the unified cloud. FIG. 5 illustrates example security measurements implemented in the unified cloud, in accordance with some embodiments. These security measurements may be implemented to prevent fraud and malicious acts, and enhance data security.
As to claim 6, Xu further discloses:
a. wherein subsequent to provisioning the computer system with a secure credential that is configured to provide authorization to use one or more functions of the vehicle, the second computer system maintains one or more credentials configured to provide authorization to use one or more functions of the vehicle read on ¶ 0047, (The user-commands may include locking or unlocking of the vehicle, locating the vehicle, opening or closing one or more windows, opening or closing a compartment of the vehicle, controlling air conditioner or windows, or summoning the vehicle. In some embodiments, the user-commands may include the digital user-token of the user account for authentication purposes. Based on the digital user-token in the received user commands, the unified cloud 300 may retrieve the digital vehicle-key that is mapped to the digital user-token. Then the vehicle-command generating module 340 may be configured to generate specific vehicle commands based on the user commands using the APIs of the corresponding vehicle cloud. The vehicle commands may be authenticated by the digital vehicle key and transmitted to the vehicle cloud. The vehicle cloud may then identify the target vehicle based on a mapping between the digital vehicle key and the unique vehicle token, and execute the vehicle commands to control the vehicle, such as to unlock, lock, turn on or off AC or windows, etc.).
As to claim 7, Xu further discloses:
a. wherein the prompt for authorization by the second computer system to provide credential information corresponding to the vehicle includes a prompt for a password, a passcode, and/or biometric authentication read on ¶ 0004, (receiving, by the computing device, a second request from the user including the digital user-token and one or more user-commands for managing the vehicle; retrieving, by the computing device, the digital vehicle-key of the vehicle based on the digital user-token in the second request; constructing, by the computing device, one or more vehicle commands based on the one or more user-commands using the set of APIs of the vehicle-cloud associated with the vehicle; and transmitting, by the computing device, the digital vehicle-key of the vehicle and the one or more vehicle commands to a vehicle-cloud corresponding to the vehicle for managing the vehicle according to the one or more vehicle commands).
As to claim 8, the claim is interpreted and rejected as to claim 1.
As to claim 9, the claim is interpreted and rejected as to claim 1.
Citation of pertinent Prior Arts
9. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: see PTO-892 Notice of References Cited.
Conclusion
10. If the claimed invention is amended, Applicant is respectfully requested to indicate the portion(s) of the specification, which dictate(s) the structure/description relied upon to assist the Examiner in proper interpretation of the amended language and also to verify and ascertain the metes and bounds of the claimed invention. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Fekadeselassie Girma whose telephone number is (571) 270-5886. The examiner can normally be reached on Monday thru Friday, 8:30 – 5:00. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Davetta W. Goins can be reached on (571) 272-2957. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Fekadeselassie Girma/
Primary Examiner Art Unit 2689