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 action is responsive to an amendment filed on 3/31/2026. Claims 1, 6-8 and 12 have been amended. Claims 4-5 and 9-10 have been canceled. Claims 13-16 have been added. Claims 1-3, 6-8 and 11-16 are pending.
Response to Arguments
Applicant’s arguments, see Applicant Arguments/Remarks, filed on 3/31/2026, with respect to the rejection of the pending claims under 35 U.S.C. §102 have been fully considered. But they are not persuasive.
Applicant argues that the claimed "V2X enrollment process" is performed entirely after the manufacture of the claimed "general hardware vehicle connectivity unit" (i.e., the first and second phases are during/after vehicle manufacturing). Thus, this discussion in the Held reference fails to read upon the generation of the "first asymmetric key pair'' during "the first phase" as claimed. (Arg./Rem. Page 10)
Examiner respectfully disagrees. Held teaches during vehicle manufacture at the OEM, a control device-individual pair of keys GerlndPub, GerlndPriv [i.e., first asymmetric key pair] is generated for the control device having the identity GerlD. …The identity GerID, the control device type GerTyp and the public key GerlndPub are transmitted to the GCA [i.e., a first certificate signing request], where a certificate GerlndCert [i.e., a signed identity certificate] is generated for this data GerID, GerlndPub, and GerTyp using GerRootPriv, Subsequently, the data as a whole is signed with GerRootPriv [¶¶ 0040-0043]. Held further teaches if the vehicle requires a certificate from the point of view of the control device, the control device determines its control device-specific fingerprint FzgFAGerSpez, by collecting the necessary information, determines the identity FzgID of the vehicle in which it is installed [i.e., during a subsequent second phase after the assembly (after manufacturing) of the vehicle is complete], generates a pair of keys FzglndPub, FzglndPriv [i.e., a second asymmetric key pair] in a secure environment for the vehicle-individual certificate FzglndCert for the vehicle with the identity FzgID. …creates a certificate signing request (CSR) [i.e., a second certificate signing request] for FzgID [i.e., a vehicle identification number], FzglndPub [i.e., a public key of the second symmetric key pair] and GerTyp [¶¶ 0053-0058] it sends the CSR(FzgID, FzglndPub, GerTyp) for the vehicle identity FzgID and the public key FzglndPub over a protected channel [i.e., secure communication channel] to the vehicle-CA FCA [¶ 0068]. Accordingly, Held teaches a multi-stage certificate provisioning process substantially corresponding to the claim first and second phases.
Therefore, Examiner is not persuaded and finds that the applied reference, Held, teaches the limitations recited in Claim 1. For details, see the rejection, infra.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a transceiver”, “a controller” couple with functional language “communication with…”, “perform V2X enrollment process…” ,”transmitting”, “receiving”, “storing”. in claims 1-3 and 11.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
A review of the specification shows that the following appears to be the corresponding structure described in the specification for the 35 U.S.C. 112(f) or pre-AIA 35 USC. 112, sixth paragraph limitation: Fig. 1, Para 0012 discloses a vehicle 100 comprises a vehicle connectivity unit 120, which generally comprises a transceiver 124 and a controller 128.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
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 1 and 6 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 pre-AIA the applicant, regards as the invention.
Claims 1 and 6 recite “…a controller integrated in a vehicle connectivity unit provided by a third-party supplier that does not have access to the OEM backend system,…”, which is unclear, because it is not clear whether the phrase “provided by a third-party supplier that does not have access to the OEM backend system” modifies by the “controller”, the “vehicle connectivity unit” or both. The grammatical structure permits multiple reasonable interpretations, each of which materially alters the scope of the claims. As a result one of ordinary skill in the art cannot determine with reasonable certainty which component must be supplied by the third-party supplier and which component lacks access to the OEM backend system.
Claim Rejections - 35 USC § 103
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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 6 and 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over US 2023/0291574 (Held et al.) in view of US 20230076726 (Roehrig et al.).
Regarding Claim 1, Held teaches a vehicle-to-everything (V2X) communication system of a vehicle, the V2X communication system comprising: a transceiver configured for communication with other original equipment manufacturer (OEM) vehicles and an OEM backend system ([¶ 0002] Modern vehicles are characterized by an increased amount of networking. The vehicles are …connected to systems such as the world wide web …also to systems and servers operated by the vehicle manufacturer or OEM, …referred to as the vehicle backend [i.e., V2X communication]. All this together is referred to as the vehicle ecosystem. [¶ 0004], control devices installed in the vehicles that establish or maintain a connection to the backend. Note: Since a communication link to the backend is discloses, therefore, it would be realized that the presence of a transceiver in necessarily present); and a controller integrated in a vehicle connectivity unit provided by a third-party supplier…, wherein the controller is in communication with the transceiver and configured to perform a V2X enrollment process ( [¶ 0004], individual control devices installed in the vehicles that establish or maintain a connection to the backend. [¶ 0010], the control device [i.e., controller] is usually manufactured by a company [i.e., third-party supplier] other than the OEM. Note: Held teaches a two-phase, certificate based onboarding workflow, which is exact functional equivalent of a V2X enrollment process) including: during a first phase during assembly of the vehicle in a secure facility operated by the OEM, establishing a digital identify of the vehicle by: generating a first asymmetric key pair for the digital identity ([¶ 0040] Setting up the control device with initial cryptographic material, in particular with a control device-individual certificate. This is done once per control device with the individual identity GerlD, the type GerTyp, for example during the manufacture thereof. [¶ 0046] Recording the vehicle identity FzglD and a vehicle fingerprint FzgFA. This is done once per control device of the type GerTyp with the identity GerlD, when it is installed in a vehicle with the identity FzgID, for example during vehicle manufacture at the OEM. [¶ 0032], Setting up a vehicle infrastructure for public keys, a so-called public key infrastructure (PKI) for vehicle-individual certificates. [¶ 0041] A control device-individual pair of keys GerlndPub, GerlndPriv [i.e., first asymmetric key pair] is generated for the control device having the identity GerlD [i.e., a digital ID], preferably in a hardware security module (HSM) installed in this control device), performing attestation of the digital identity by transmitting a first certificate signing request to the OEM backend system, wherein receipt of the first certificate signing request causes the OEM backend system to generate a signed identify certificate corresponding to a public key of the first asymmetric key pair ([¶0043] The identity GerID, the control device type GerTyp and the public key GerlndPub are transmitted to the GCA [i.e., a first certificate signing request], where a certificate GerlndCert [i.e., a signed identity certificate] is generated for this data GerID, GerlndPub, and GerTyp using GerRootPriv, Subsequently, the data as a whole is signed with GerRootPriv), and receiving, from the OEM backend system, and securely storing, at the vehicle, the signed identity certificate ([¶ 0044] GCA transmits GerlndCert back to the control device where it is stored); and
during a subsequent second phase after the assembly of the vehicle is complete and the vehicle has left the secure facility ([Fig. 1, ¶ 0030] The sole figure illustrated vehicle 1 twice, namely once during manufacture labelled 1′ and once during operation labelled 1″. A control device 2 is also shown several times, once labelled 2′ during manufacture, a further time labelled 2″ in the vehicle 1′ during manufacture thereof and a further time in the vehicle 1″ during operation), obtaining a V2X enrollment certificate by: generating a second asymmetric key pair for V2X enrollment ([¶¶ 0053-0057] If the vehicle requires a certificate from the point of view of the control device, the control device determines its control device-specific fingerprint FzgFAGerSpez, by collecting the necessary information, determines the identity FzgID of the vehicle in which it is installed, generates a pair of keys FzglndPub, FzglndPriv [i.e., a second asymmetric key pair] in a secure environment for the vehicle-individual certificate FzglndCert for the vehicle with the identity FzgID), generating a second certificate signing request including at least a vehicle identification number (VIN) of the vehicle and a public key of the second symmetric key pair ( [¶ 0058] creates a certificate signing request (CSR) for FzgID [i.e., a vehicle identification number], FzglndPub [i.e., a public key of the second symmetric key pair] and GerTyp. [¶ 0007], the associated certificate must be issued by a trusted central certification authority (CA) within the vehicle ecosystem to an individual vehicle identity, i.e., to the vehicle identification number (VIN)), establishing a secure communication channel with the OEM backend system using the signed identify certificate [¶ 0068] sends the CSR for the vehicle identity FzgID and the public key FzglndPub over a protected channel to the vehicle-CA FCA), transmitting, to the OEM backend system and via the secure communication channel, the second certificate signing request, wherein receipt of the second certificate signing request causes the OEM backend system to generate the V2X enrollment certificate ([¶¶ 0058-0070] creates a certificate signing request (CSR) for FzgID, FzglndPub and GerTyp, …generates the signature Sign, by signing the data packet (CSR(FzgID, FzglndPub, GerTyp), FzgFAGerSpez) with the control device-individual private key GerlndPriv, …sends the data packet ((CSR(FzgID, FzglndPub, GerTyp), FzgFAGerSpez), Sign, GerlndCert(GerlD, GerlndPub, GerTyp)) to the backend. The backend 3 receives the data packet and checks the correctness of the control device-individual certificate GerlndCert using the public key of the control device certification authority GCA GerRootPub that is stored therein, …checks the correctness of the signature Sign of the data packet using the public key GerlndPub contained in the control device-individual certificate GerlndCert which is also sent, …extracts the vehicle identity FzglD from the CSR, extracts the identity GerlD and the control device type GerTyp of the control device from the control device-individual certificate GerlndCert and checks whether an entry for FzgID, GerTyp, and GerlD has been stored in the backend, …checks whether an entry FzgID, FzgFA has been stored for the identity FzglD of the vehicle, … checks whether the control device-specific vehicle fingerprint FzgFAGerSpez contained in the received message matches the general vehicle fingerprint FzgFA, … it sends the CSR(FzgID, FzglndPub, GerTyp) for the vehicle identity FzgID and the public key FzglndPub over a protected channel [i.e., secure communication channel] to the vehicle-CA FCA …the FCA issues a vehicle-individual certificate FzglndCert [i.e. enrollment certificate] signed with FzgRootPriv based on the CSR(FzglD, FzglndPub, GerTyp) for the vehicle identity FzglD and the public key FzglndPub, and …the FCA sends the vehicle-individual certificate FzglndCert back to the backend), and receiving, from the OEM backend system and via the secure communication channel, and securely storing, at the vehicle, the V2X enrollment certificate ([¶¶ 0071-0073] sends the vehicle-individual certificate FzglndCert [i.e. enrollment certificate] to the control device installed in the vehicle. The control device checks the received certificate FzglndCert, [¶ 0076] stores the vehicle-individual certificate FzglndCert locally. [¶ 0077] From now in, the control device with the identity GerlD is in possession of a vehicle-individual certificate FzglndCert issued to the vehicle identity FzgID and the associated vehicle-individual private key FzglndPriv and can securely perform the tasks assigned to this control device by the vehicle. [¶ 0068] it sends the CSR(FzgID, FzglndPub, GerTyp) for the vehicle identity FzgID and the public key FzglndPub over a protected channel [i.e., secure communication channel] to the vehicle-CA FCA).
Held does not explicitly teach, however, Roehrig teaches the third-party supplier that does not have access to the OEM backend system ([¶ 0029] FIG. 1a shows a block diagram of an electronic control unit 10 for a vehicle 100. The electronic control unit 10 comprises processing circuitry 14 and an interface 12 (e.g. interface circuitry 12), which is coupled to the processing circuitry 14. [¶ 0033] These electronic control units are often manufactured by third-party suppliers of the manufacturer of the vehicle (i.e. of the Original Equipment Manufacturers, OEMs). At the same time, OEMs often wish to limit the access to said electronic control units, e.g. in order to avoid manipulations of the electronic control units by malicious actors).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Roehrig’s teaching of limit the access to said electronic control units to the teachings of Held, because such incorporation would have allowed maintaining security, control, and trust over the vehicle’s critical system.
Claim 6 is identical and/or equivalent in scope to claim 1, therefore, Claim 6 is rejected under the same rationale as claim 1.
Regarding Claim 13, Held teaches the V2X communication system of claim 1, wherein the V2X enrollment process by the controller includes, during the first phase: a hardware security module (HSM) of the vehicle connectivity unit that creates the first asymmetric key pair and the first certificate signing request and stores the signed identity certificate ([¶ 0008] private key should ideally be generated together with the associated public key in a secure hardware area (e.g., a hardware security module/HSM) of a control device located in the vehicle to which the certificate is to belong and should never leave this secure area of this control device. [¶ 0014], a certificate for a unique and forgery-proof, for example read-only, identity of the control device which has installed the hardware security module (HSM) in which the private key belonging to the vehicle-individual certificate is later to be securely stored. [¶ 0026] the respective individual pair of keys is generated by the control device in a hardware security module (HSM) and/or is at least securely stored there. [¶ 0041] A control device-individual pair of keys GerlndPub, GerlndPriv is generated for the control device having the identity GerlD, preferably in a hardware security module (HSM) installed in this control device. [¶ 0043] transmitting [i.e., the first certificate signing request] the identity GerlD and the public key GerlndPub to a certificate authority GCA); and an identity application that requests the first certificate signing request from the HSM, provides the first certificate signing request to an identity manager at the OEM backend system, and receives the signed identity certificate from the identity manager of the OEM backend system ([¶ 0007], the associated certificate must be issued by a trusted central certification authority (CA) within the vehicle ecosystem to an individual vehicle identity. [¶¶ 0041-0044], control device-individual pair of keys GerlndPub, GerlndPriv is generated for the control device having the identity GerlD, preferably in a hardware security module (HSM) installed in this control device…The identity GerID, the control device type GerTyp and the public key GerlndPub are transmitted [i.e., first certificate signing request] to the control device certification authority GCA [i.e., identity manager], where a certificate GerlndCert is generated for this data… Subsequently, the data as a whole is signed with GerRootPriv. GCA transmits GerlndCert back to the control device. Note: Held teaches generation of cryptographic keys within the HSM and subsequently transmitted the ID and public key to GCA for certification, therefore, it would be realized the control device software necessarily interface with, and transmits information from, the HSM. Under BRI, such software corresponds to the claimed “identity application”).
Regarding Claim 14, Held teaches the V2X communication system of claim 13, wherein the V2X enrollment process by the controller includes, during the second phase: the HSM creates the second asymmetric key pair and the second certificate signing request and validates and stores the V2X enrollment certificate ([¶ 0008] private key should ideally be generated together with the associated public key in a secure hardware area (e.g., a hardware security module/HSM) of a control device located in the vehicle to which the certificate is to belong and should never leave this secure area of this control device. [¶ 0014], a certificate for a unique and forgery-proof, for example read-only, identity of the control device which has installed the hardware security module (HSM) in which the private key belonging to the vehicle-individual certificate is later to be securely stored. [¶ 0026] the respective individual pair of keys is generated by the control device in a hardware security module (HSM) and/or is at least securely stored there. [¶¶ 0057-0058], control device generates a pair of keys FzglndPub, FzglndPriv in a secure environment for the vehicle-individual certificate FzglndCert for the vehicle…creates a certificate signing request (CSR). [¶¶ 0076-0077], The control device stores the vehicle-individual certificate FzglndCert locally…the control device is in possession of a vehicle-individual certificate FzglndCert issued to the vehicle identity FzgID and the associated vehicle-individual private key FzglndPriv and can securely perform the tasks assigned to this control device by the vehicle); and an enrollment application, separate from the identity application, that requests the second certificate signing request from the HSM, provides the second certificate, including at least the VIN of the vehicle and the public key of the second asymmetric key pair, to a V2X enrollment authority of the OEM backend system, separate from the identity manager, which establishes the secure communication channel based on the VIN and the public key of the second asymmetric key pair and obtains, from an enrollment certificate authority of the OEM backend system, the signed identity certificate, and that provides the signed identity certificate to the enrollment application via the secure communication channel ([¶¶ 0058-0077] The control device creates a certificate signing request (CSR) for FzgID, FzglndPub [i.e., the public key of the second asymmetric key pair] and GerTyp, …generates the signature Sign, by signing the data packet (CSR(FzgID, FzglndPub, GerTyp), FzgFAGerSpez) with the control device-individual private key GerlndPriv, …sends the data packet ((CSR(FzgID, FzglndPub, GerTyp), FzgFAGerSpez), Sign, GerlndCert [i.e., the second certificate] (GerlD, GerlndPub, GerTyp)) to the backend. …after check the correctness of the certificate the backend sends the CSR(FzgID, FzglndPub, GerTyp) for the vehicle identity FzgID and the public key FzglndPub over a protected channel to the vehicle-CA FCA [i.e. V2X enrollment authority separate from the identity manager (i.e., GCA)]… the FCA issues a vehicle-individual certificate FzglndCert signed with FzgRootPriv based on the CSR(FzglD, FzglndPub, GerTyp) for the vehicle identity FzglD and the public key FzglndPub, and the FCA sends the vehicle-individual certificate FzglndCert back to the backend, this sends the vehicle-individual certificate FzglndCert to the control device installed in the vehicle …the control device stores the vehicle-individual certificate FzglndCert locally. From now in, the control device with the identity GerlD is in possession of a vehicle-individual certificate FzglndCert issued to the vehicle identity FzgID and the associated vehicle-individual private key FzglndPriv and can securely perform the tasks assigned to this control device by the vehicle. [¶ 0007] the associated certificate must be issued by a trusted central certification authority (CA) within the vehicle ecosystem to an individual vehicle identity, i.e., to the vehicle identification number (VIN). Note: Held teaches generation of cryptographic keys within the HSM of the control device and subsequently transmitted the ID and public key to GCA for certification, therefore, it would be realized the control device software necessarily interface with, and transmits information from, the HSM. Under BRI, such software corresponds to the claimed “enrollment application”).
Claims 15 and 16 is identical and/or equivalent in scope to claims 13 and 14, therefore, Claims 15 and 16 are rejected under the same rationale as claims 13 and 14.
Claims 2, 3, 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Held in view of Roehrig, and further in view of US 10951418 (Graziano et al.) and US 2021/0091887 (Cho et al.).
Regarding Claim 2, Held in view of Roehrig do not explicitly teach, however, Graziano teaches the V2X communication system of claim 1, wherein the controller is further configured to transmit a V2X enrollment status to the OEM backend system upon receiving and securely storing the V2X enrollment certificate ([C.6:L.25-55], line-replaceable unit (LRU) in an aircraft may determine that the validation is successful and may store the public certificate. …To guarantee the establishment of the digital identity, the LRU may generate an enrollment status message to notify the ground-based server whether the validation of the public certificate was successful).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Graziano's notifying enrollment message to server to the combined teachings of Held and Roehrig, because such incorporation would have allowed the server to perform a corresponding action based on the enrollment status.
Graziano teaches notify an enrollment status to the server, however, Held in view of Roehrig and Graziano do not explicitly teach, however, Cho teaches transmit, via a different communication channel ([¶ 0097], the transmitting device may receive a codeword acknowledgement from the receiving device via a second wireless channel of a second wireless link. By transmitting the codeword acknowledgement on a different wireless channel and wireless link than the first wireless channel).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Cho's second wireless channel to transmit acknowledgement to the combined teachings of Held, Roehrig and Graziano, because such incorporation would have improved reliability, reduce congestion on the primary channel and ensured successful completion of critical security process.
Regarding Claim 3, Held in view of Roehrig and Cho do not explicitly teach, however, Graziano teaches the V2X communication system of claim 2, wherein transmitting the V2X enrollment status to the OEM backend system indicates that the V2X communication system is enrolled and authenticated for V2X communication with other same or different OEM vehicles and/or road-side units ([C.1:L.65-67], the enrollment status message may include selecting the at least one status code indicating that the public certificate is valid or that the validation is successful. [C.13:L.28-39] If the public certificate is valid or the validation of the public certificate is successful, the certificate validator may select a status code indicating that the public certificate is valid or the validation of the public certificate is successful. In some embodiments, the certificate validator may determine that the establishment of the digital identity is complete, responsive to the determination that the public certificate is valid or that the validation is successful. …the status code may also indicate to the ground-based server that the digital identity and/or the secure communication session with the LRU have been established).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Graziano's notifying status code to server, responsive to determination that the public certificate is valid or that the validation is successful, to the combined teachings of Held, Roehrig and Cho, because such incorporation would have allowed the server to perform a corresponding action based on the status code.
Claims 7 and 8 are identical and/or equivalent in scope to claims 2 and 3, respectively, therefore, Claims 7 and 8 are rejected under the same rationale as claims 2 and 3.
Claims 11 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Held in view of Roehrig, and further in view of WO 2024101511 (Park et al.).
Regarding Claim 11, Held in view of Roehrig do not explicitly teach, however, Park teaches the V2X communication system of claim 1, wherein the controller is configured to generate the second asymmetric key pair for V2X enrollment based on regional cryptographic requirements and V2X standards ([Page 4-5], IEEE 1609.2 defines protocols to protect messages in vehicle-to-vehicle (V2V) or vehicle-to-infrastructure (V2I) communication based on WAVE (Wireless Access in Vehicular Environment). Curve cryptography can be used. … in the signature verification process, IEEE 1609.2 applies the elliptic curve encryption method, and domain parameters defining the elliptic curve required for verification may be included in the signature data. … ECDSA (Elliptic Curve Digital Signature Algorithm), a digital signature algorithm through elliptic curve, is a digital signature method that performs a digital signature using an elliptic curve. ECDSA is also an asymmetric key and generates a pair of private key and public key. When the recipient receives the message and signature encrypted through the private key, the message is sent through the public key. The authenticity of the signature is verified by decrypting it and comparing the signature and the decrypted value).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Park’s IEEE 1609.2 elliptic curve encryption method to the combined teachings of Held and Roehrig, because such incorporation would have ensured that the key generation and cryptographic operation are compatible with V2E security protocols.
Claim 12 are identical and/or equivalent in scope to claim 11, therefore, Claim 12 is rejected under the same rationale as claim 11.
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 MOHAMMAD YOUSUF A MIAN whose telephone number is (571)272-9206. The examiner can normally be reached Monday-Friday 9am-5:30pm.
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, ARIO ETIENNE can be reached at 571-272-4001. 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.
/MOHAMMAD YOUSUF A. MIAN/ Examiner, Art Unit 2457
/ARIO ETIENNE/ Supervisory Patent Examiner, Art Unit 2457