DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This Office action is in response to communications filed on 12/29/2025.
Claims 1, 3-13, and 15-20 have been amended.
Claims 1-20 are pending.
Specification
The disclosure is objected to because of the following informalities:
Paragraph [0066] of the specification, as filed, recites “It seems the activate is initiated at the private digital key. The request is activated through the private digital key.” The examiner suggests amending the phrase to - - The request is activated through the private digital key - -.
Appropriate correction is required.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 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 § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 6 and 16 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claim 6, the limitations recite "the private digital key is a key fob". The specification does not offer support for a private digital key to be a key fob. In paragraph [0024] of the specification, as published, the instant application defines a "digital key" as containing "encrypted data that serves as a digital representation of a physical key or key fob used to access and operate a vehicle" but this does not mean the digital key is the key fob. Instead, as established by ¶[0054], "digital keys and associated permissions can be stored and managed on cloud-based servers maintained by the vehicle manufacturer or a related service provider" and are thus not a key fob. Therefore, it's unclear how the private digital key can be a key fob.
Regarding claim 16, the limitations recite features similar in scope to those of claim 6. Therefore, claim 6 is rejected for the same reasons as set forth in the rejection of claim 6, above.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
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.
Claims 6 and 16 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 6, the limitations recite "the private digital key is a key fob". The specification does not offer support for a private digital key to be a key fob. In paragraph [0024] of the specification, as published, the instant application defines a "digital key" as containing "encrypted data that serves as a digital representation of a physical key or key fob used to access and operate a vehicle" but this does not mean the digital key is the key fob. Instead, as established by ¶[0054], "digital keys and associated permissions can be stored and managed on cloud-based servers maintained by the vehicle manufacturer or a related service provider" and are thus not a key fob. Therefore, it's unclear how the private digital key can be a key fob.
Regarding claim 16, the limitations recite features similar in scope to those of claim 6. Therefore, claim 6 is rejected for the same reasons as set forth in the rejection of claim 6, above.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
Claim(s) 1, 4-9, 11, 14-19 is/are rejected under 35 U.S.C. 102(A)(1) as being anticipated by McFarland, JR. et al. (US 20240135006 A1, hereinafter McFarland).
Regarding claim 1, McFarland, JR. discloses a system, comprising: a memory configured to store computer-executable instructions; and a processor; configured to execute at least one of the computer-executable instructions (¶[0176], "embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination of the above. A computer program may be embodied on a computer readable medium, such as a storage medium") that:
associates a private digital key to a portable device associated with a user (¶[0051], "associates a first device 101 of a first user with a first profile key 105. For example, first device 101 may comprise a smartphone or other mobile device"; ¶[0060], "a first user type may be a vehicle owner. The vehicle owner is assigned a vehicle owner permission level that provides full rights to vehicle key distribution, privacy and permission settings for non-owner users, with limitations on dynamic changes to permissions and privacy"; Fig. 1B, a second profile key may be associated with a second device (of a second user, see ¶[0065]); ¶[0051], "first device 101 may comprise a smartphone or other mobile device"),
wherein the private digital key is assigned to the user (¶[0051], "first profile key 105 may provide the first user with the capability to lock, unlock, start, and stop the vehicle 102 via an application running on the first device 101"; ¶[0060], "The vehicle owner is assigned a vehicle owner permission level that provides full rights to vehicle key distribution. The duration of the vehicle owner permission level can be indefinite until the vehicle is transferred to another owner" (likewise, second profile key assigned to second user, see Fig. 1B and ¶[0065])), and
wherein the private digital key is configured to: store permission data for controlling privacy of user data associated with the user in a group of vehicles (¶[0060], "The vehicle owner is assigned a vehicle owner permission level that provides full rights to vehicle key distribution, privacy and permission settings for non-owner users"; Fig. 1A, the permission level is stored by the first profile key 105; ¶[0075], "configuring a second profile key with the second permission level 245D"; ¶[0067], "The second user can be in the same vehicle as the first user, or in any vehicle that the first user supervises (i.e., in a fleet setting)"),
wherein the group of vehicles comprises a variety of brands of vehicles (¶[0001], "Vehicles or transports, such as cars, motorcycles, trucks, planes, trains, etc." - suggesting the invention works with multiple brands of vehicles as no single brand manufactures all types of those vehicles), and
enables the user to control functions of the group of vehicles (¶[0051], "first profile key 105 may provide the first user with the capability to lock, unlock, start, and stop the vehicle 102 via an application running on the first device 101"; ¶[0067], "the at least one vehicle function 112 is associated with the first permission level 131 for the first user and the second permission level 132 for the second user. The second profile key 135 is configured for customizing the at least one vehicle function 112 for a second user. The second user can be in the same vehicle as the first user, or in any vehicle that the first user supervises (i.e., in a fleet setting)"); and
employs a security protocol with the private digital key to regulate consent management for a vehicle of the group of vehicles (¶[0066], "the first profile key 105 is configured with a supervisory permission level for customizing at least one vehicle function 112 of the vehicle 102 for the first user. The first profile key 105 can be configured to permit access to the at least one vehicle function 112 for a second user by the first user"; ¶[0067], "the at least one vehicle function 112 is associated with the first permission level 131 for the first user and the second permission level 132 for the second user. The second profile key 135 is configured for customizing the at least one vehicle function 112 for a second user").
Regarding claim 4, McFarland, JR. discloses the system of claim 1, wherein the security protocol is an extension of the private digital key and its functions (¶[0057], "In some embodiments, the first profile key 105 is associated with at least one vehicle function 112. As mentioned previously, some illustrative examples of vehicle functions include window lock controls, cruise control, child safety locks, airbag deactivation (for rear-facing baby seats), seat adjustments, wing mirror adjustments, seat headrest adjustments, parking sensors, infotainment system adjustments, volume muting, power outlet enable/disable, voice commands, limits on maximum speed, driving mode control (sport mode, economy mode, performance mode, etc.), and/or drivetrain mode control (4-wheel drive, front-wheel drive, all-wheel drive)" (i.e., the regular functions of the key); ¶[0066], "In some embodiments, the first profile key 105 is configured with a supervisory permission level for customizing at least one vehicle function 112 of the vehicle 102 for the first user. The first profile key 105 can be configured to permit access to the at least one vehicle function 112 for a second user by the first user" (i.e., functions beyond those described in ¶[0057])).
Regarding claim 5, McFarland, JR. discloses the system of claim 1, wherein the portable device is a smartphone (¶[0051], "first device 101 may comprise a smartphone or other mobile device").
Regarding claim 6, McFarland, JR. discloses the system of claim 1, wherein the private digital key is a key fob (¶[0051], "The first profile key 105 may provide the first user with the capability to lock, unlock, start, and stop the vehicle 102 via an application running on the first device 101" - a key fob is typically a device used to lock, unlock, start, and stop a vehicle. Therefore, the profile keys are digital representations of a key fob).
Regarding claim 7, McFarland, JR. discloses the system of claim 1, wherein the private digital key stores and keeps track of the permissions per function and per vehicle (¶[0075], establishing a permission level based upon the at least one function; and configuring the first profile key with the permission level 244D; determining a first permission level for the first user in a hierarchical arrangement related to the vehicle; determining a second permission level for a second user in the hierarchical arrangement, wherein the second permission level is different from the first permission level; configuring the first profile key with the first permission level; and configuring a second profile key with the second permission level 245D; associating the encrypted data with a time stamp including a time of day, and/or a location identifier specifying a current location of the vehicle; and controlling access to the encrypted data and the other data in response to the time stamp, and/or the location identifier 246D"; ¶[0064], "In some embodiments, while the vehicle owner and/or vehicle manager may make changes to permission levels and driver types, these changes are not implemented immediately unless the vehicle 102 and/or the first device 101 is reported as stolen. For example, changing a user's privacy permissions while they are using the vehicle 102 to force them to either find other transportation or accept tracking may not be an acceptable use case unless this functionality is approved when the first profile key 105 is initially distributed to the user. Likewise, the lifetime of the first profile key 105 may be permanent, with any permission changes requiring an advance notification period ranging from a few hours to a few days. For a rental use case, the lifetime of the first profile key 105 may include a permission guarantee wherein the permissions cannot be changed until the end of the rental or on renewal of the rental"; ¶[0062], "For example, these constraints may include any of a maximum daytime speed, a maximum nighttime speed, advanced driver assistance systems (ADAS) configurations, entry of a personal identification (PIN) number to start the vehicle 102, administration of a hand-eye coordination test to drive, controlled access to a glove compartment in the vehicle 102, controlled access to a trunk of the vehicle 102").
Regarding claim 8, McFarland, JR. discloses the system of claim 1, wherein the group of vehicles further comprises at least one of a personal vehicle, a loaned vehicle, or a rented vehicle (¶[0059], "the hierarchical arrangement of permission levels comprises any of a vehicle owner permission level, a vehicle manager permission level, a vehicle leasing permission level, an unsupervised driver permission level, a supervised driver permission level, and a vehicle servicer permission level").
Regarding claim 9, McFarland, JR. discloses the system of claim 1, wherein the private digital key is transferable to another user (¶[0060], "The vehicle owner is assigned a vehicle owner permission level that provides full rights to vehicle key distribution, privacy and permission settings for non-owner users, with limitations on dynamic changes to permissions and privacy. The duration of the vehicle owner permission level can be indefinite until the vehicle is transferred to another owner").
Regarding claims 11 and 14-19, McFarland JR. discloses a computer implemented method (¶[0122], "Some of the subject matter and operations described in this disclosure can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures described in this disclosure and their structural equivalents, or in combinations of one or more of them").
The remaining limitations of claims 11 and 14-19 are similar in scope to those of claims 1 and 4-9. Therefore, claims 11 and 14-19 are rejected for the same reasons as set forth in the rejection of claims 1 and 4-9, above.
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.
Claim(s) 2-3, 10, 12-13, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over McFarland, JR. (US 20240135006 A1) in view of Blais et al. (US 20240286630 A1, hereinafter Blais).
Regarding claim 2, McFarland, JR. discloses the system of claim 1.
McFarland, JR. does not disclose that the private digital key uses an open vehicle data standard.
Blais discloses a private digital key using an open vehicle standard (¶[0031], "At 202, the vehicle receives an access request for a vehicle signal or a node in a signal catalog […] the request can be received from an application, e.g., the application 122 in FIG. 1. The application can execute on an electronic device outside of the vehicle, where the request can be sent by using a wireless or wireline connection"; ¶[0039], "The request can also include the permission(s) the application has been assigned to"; ¶[0041], "one or more permission elements can be defined for the vehicle signal or each node in a signal catalog"; ¶[0042], "The permission elements can be set directly at a user interface of the vehicle, or through a server"; ¶[0078], "the permission value can be assigned to the application (e.g., by using an authorization server or application) by the manufacturer of the vehicle, the operation administrator of the vehicle, the owner of the vehicle, the driver of the vehicle, or any combination thereof"; ¶[0043], "the permission element can be defined as part of the VSS").
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify McFarland, JR. in view of Blais so that the private digital key uses an open vehicle data standard.
One of ordinary skill in the art would have been motivated because VSS "can be used to provide the common format/structure for the vehicle signals" (Blais, ¶[0033]).
Regarding claim 3, the combined system of McFarland, JR. and Blais discloses the invention substantially as applied to claim 2, above, wherein the open vehicle data standard vehicle signal specification (VSS) (Blais, ¶[0043], "the permission element can be defined as part of the VSS").
Regarding claim 10, McFarland, JR. discloses the system of claim 1.
McFarland, JR. does not disclose that services and applications associated with functions check the private digital key for acceptance or rejection when they are executed.
Blais discloses services and applications associated with functions check a private digital key for acceptance or rejection when they are executed (¶[0074], "In some implementations, at 204, the vehicle determines whether to grant the access request by comparing the permission value of the permission element of the signal/node with the permission value of the application that requests the signal/node. For example, the application may be assigned the permission value of “READ_ACCESS”. In this case, the vehicle can determine that the application is allowed to obtain any signal/node whose read permission element is set to “READ_ACCESS”. However, if the permission value of the read permission element of a signal/node is set to “PERSONAL_INFO” (e.g., “Vehicle.VehicleIdentification.VIN”), and the permission value of the application is set to “READ_ACCESS”, which does not match the permission value of the read permission element of the signal/node, in this case, the vehicle can reject the request from the application").
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify McFarland, JR. in view of Blais so that services and applications associated with functions check the private digital key for acceptance or rejection when they are executed.
One of ordinary skill in the art would have been motivated because it would prevent unauthorized functions from being performed.
Regarding claims 12-13 and 20, McFarland JR. discloses the computer implemented method of claim 10.
The remaining limitations of claims 12-13 and 20 are similar in scope to those of claims 2-3 and 20. Therefore, claims 12-13 and 20 are rejected for the same reasons as set forth in the rejection of claims 2-3 and 20, above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 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 BORIS D GRIJALVA LOBOS whose telephone number is (571)272-0767. The examiner can normally be reached M-F 10:30AM to 6:30PM EST.
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, Brian Gillis can be reached at 571-272-7952. 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.
/BORIS D GRIJALVA LOBOS/ Primary Patent Examiner, Art Unit 2446
Prosecution Insights