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 Status
Claims 1-20 are currently pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04-07-2025 has been considered by the examiner.
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) 1, 2, 4-6, 9, 10, 12-14, 17, 18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Farmer (US Patent 11,233,951) in view of Scarlata (US Publication 2017/0366359).
Regarding claims 1, 9 and 17,
Farmer teaches a vehicle computing system comprising a plurality of devices, the plurality of devices comprising:
one or more requesting devices (762), wherein each respective requesting device of the one or more requesting devices comprises:
a trusted platform module associated with an identity certificate and an identity private key, wherein the identity certificate identifies the respective requesting device (1016); and
a master device (760a), comprising:
one or more processors (840, fig. 8); and
one or more tangible, non-transitory, computer readable media storing instructions (860, fig. 8) that are executable by the one or more processors cause the master device to perform operations comprising:
generating a root certificate and a private root key corresponding to the root certificate and receiving, via a communication channel, a certificate signing request from the respective requesting device, wherein the certificate signing request comprises the identity certificate and a requesting signature encrypted by the identity private key (col. 16:53-62 teaches "Authentication information message 1110 can include App 1016, which is an identifier associated with application 1016, and Key 1016, which is information about a key or other secret associated with application 1016. For example, Key 1016 can be a public key associated with application 1016, a key generated by application 1016, a reference to a public key associated with application 1016, another key associated with application 1016, and/or some other information about a key or other secret associated with application 1016."; col. 17:37-44 teaches that if data request 1120 could be encrypted using a private key associated with Key 1016,...data request 1120 could include a digital signature, such as a nonce encrypted with a key associated with Key 1016);
validating the requesting signature by comparing the identity certificate to the certificate signing request (col. 16:63-col. 17:2 teaches that after receiving authentication information message 1110, security application 1014 of wearable device 760a can store the key and application identifier associated with application 1016. Security application 1014 of wearable device 760a can then generate authentication received message 1112 to indicate application 1016 is now authenticated to receive sensitive data from wearable device 760a; col. 21:5-15 teaches that at block 1222, upon reception of data request 1220, application 1010 and/or security application 1014 can attempt to authenticate data request 1220 based on digital signature E(Nonce3) and Key 1018. For example, application 1010 and/or security application 1014 can decrypt digital signature E(Nonce3) to recover Nonce3. Then, by comparing the decrypted digital signature with the value of Nonce3 sent as part of authentication request 1214 and determining the two nonces are equal, application 1010 and/or security application 1014 can authenticate data request 1210 as coming from application 1018); and
providing, via the communication channel, the signed certificate to the respective requesting device, wherein the respective requesting device is configured to decrypt the master signature of the signed certificate with the root certificate (col. 17:3-11 teaches security application 1014, and application 1016 can use a key exchange to exchange keys, such as Key 1016, and a key from application 1016 along with or instead of messages 1110 and/or 1112. The key-exchange protocol can be used to generate and/or communicate a shared key which can be used by device 760a and application 1016 for both encryption and decryption of messages/data).
Farmer fails to expressly teach that in response to validating the requesting signature, generating a signed certificate for the respective requesting device, wherein the signed certificate comprises a master signature encrypted by the private root key.
SCARLATA teaches that in response to validating the requesting signature, generating a signed certificate for the respective requesting device, wherein the signed certificate comprises a master signature encrypted by the private root key ([0022] teaches signatures produced by the key may be identified as originating from a particular one of the host devices for which a certificate is maintained based on the corresponding certificate; [0036] teaches that the signed public key can serve as a certification issued/signed using the provisioning attestation key; [0040] teaches that the packages can generate a platform key based on a random number or pseudo random number. Each package uses a device key to encrypt a copy of its platform key. Device keys are hardware specific to the package, so each platform key for the platform will include an indication of the device key used to encrypt the platform key(s); [0042] teaches that Package A can derive a private portion of a signing key from Package A's hardware key(s)... Package A, can use Package A's hardware key to encrypt {platform keys, Package B public key).
Before the effective filing date of the invention it would have been obvious to modify the system of Farmer per the teachings of Scarlata because Scarlata's disclosure provides an additional layer of trust wherein the verification shows that the requestor has the correct key and that the key came from a trusted source.
Regarding claims 2, 10 and 18,
Scarlata teaches that the operations further comprise: discarding the root certificate based, at least in part, on at least one of a first authorization time threshold or an occurrence of a first event ([0051] The registration service 910 can maintain a database of device/package certificates received from device manufacturers. The device certificates can be used to verify that packages listed on manifests received from platforms are genuine. The database can be updated periodically as new packages/parts are manufactured. The registration service 910 can also store revocation lists that can be used to revoke package authenticity).
Regarding claims 4, 12 and 20,
Scarlata teaches that the discarding the root certificate comprises: detecting the occurrence of the first event associated with the computing system; and discarding the root certificate based, at least in part, on the occurrence of the first event ([0032] teaches receipt of a revocation list which causes verification of authenticity).
Regarding claims 5 and 13,
Scarlata teaches that the master device is configured to generate the root certificate during a start-up operation of the vehicle computing system ([0061] teaches that each package in the platform can greet each other to generate a platform root key (1104), said greeting occurring at initial communication processing).
Regarding claims 6 and 14,
Scarlata teaches that the respective requesting device is configured to authenticate at least one process of the respective requesting device ([0030] teaches, "The provisioning certification enclave 260 can maintain a provisioning attestation key ... to support attestation of the trustworthiness of the provisioning enclave 250 to the provisioning system 120, such that the provisioning enclave 250 is authenticated prior to the provisioning system 120 entrusting the provisioning enclave 250 with an attestation key.”)
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 6, 9, 7, 15 and 17 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 10, 11 and 20 of U.S. Patent No. 12,294,663 to SORENSEN. Although the claims at issue are not identical, they are not patentably distinct from each other because of obvious wording variations.
Regarding claims 1, 6, 9 and 17,
Claims 1 and 11 teach “A vehicle computing system comprising a plurality of devices, the plurality of devices comprising: one or more requesting devices, wherein each respective requesting device of the one or more requesting devices comprises: a trusted platform module associated with an identity certificate and an identity private key, wherein the identity certificate identifies the respective requesting device; and a master device, comprising: one or more processors; and one or more tangible, non-transitory, computer readable media storing instructions that are executable by the one or more processors cause the master device to perform operations comprising: generating a root certificate and a private root key corresponding to the root certificate; receiving, via a communication channel, a certificate signing request from the respective requesting device, wherein the certificate signing request comprises the identity certificate and a requesting signature encrypted by the identity private key; validating the requesting signature by comparing the identity certificate to the certificate signing request; in response to validating the requesting signature, generating a signed certificate for the respective requesting device, wherein the signed certificate comprises a master signature encrypted by the private root key; and providing, via the communication channel, the signed certificate to the respective requesting device, wherein the respective requesting device is configured to decrypt the master signature of the signed certificate with the root certificate.”
Regarding claims 7 and 15,
Claims 10 and 20 teach “The vehicle computing system claim 6, wherein authenticating the at least one process comprises: generating a private key corresponding to the certificate signing request; and generating a signed per-process certificate and a per-process private key corresponding to the signed per-process certificate, wherein the signed per-process certificate comprises a process signature encrypted by the private key.”
Allowable Subject Matter
Claims 3, 8, 11, 16 and 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Regarding claims 3, 11 and 19,
The prior art of record fails to teach the vehicle computing system of claim 2, wherein discarding the root certificate comprises: measuring an elapsed time from the generation of the root certificate; comparing the elapsed time to the first authorization time threshold; and discarding the root certificate based, at least in part, on the comparison of the elapsed time to the first authorization time threshold.
Regarding claims 8 and 16,
The prior art of record fails to teach that the respective requesting device is configured to discard the private key based, at least in part, on at least one of a second authorization time threshold or an occurrence of a second event.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DIONNE PENDLETON whose telephone number is (571)272-7497. The examiner can normally be reached M-F 9a-5pm.
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, Davetta Goins can be reached at 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 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.
/DIONNE PENDLETON/Primary Examiner, Art Unit 2689
Prosecution Insights