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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Response to Arguments
Applicant’s arguments, see pages 7-13, filed 12/24/2025, with respect to the rejection(s) of claims 1-9 rejected under 35 U.S.C. 103 as being unpatentable over Misuraca et al. (US 20230188361 A1 hereinafter --referred--“Misuraca”) in view of Shin US 20230327886 A1 in further view of Markham US 20170305368have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Sorensen (et al. US 20210288822 A1—hereinafter –" Sorensen”). Based on the applicant’s amendment to claim 9, the rejection of claim 9 as being rejected under 35 U.S.C. 101 for the claimed invention being directed to non-statutory subject matter has been withdrawn.
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-9 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.
Claim 7 recites the limitation "the DM server" in line 6.
Claims 1, 7 and 8 recite the limitation "each performance controller" in lines 6, 14 and 7 respectively.
There is insufficient antecedent basis for this limitation in the claim.
Independents claims 1, 7 and 8 recite a limitations for “obtaining or generating a private root key and a private root certificate” presenting in alternative to choose either “Obtaining” or “generating” for broader BRI considerations. However, the currently amended limitation of claims 1, 7 and 8 overriding the alternative presentation of “Obtaining” or “generating” by asserting “the private root private key” is generated. Therefore , the limitation “obtaining or generating a private root key and a private root certificate” is ambiguously nullified therefore claims 1, 7 and 8 are rendered indefinite. Dependent claims 2-6 and 9, failed to remedy the deficiencies of claims 1, 7 and 8, and therefore claims 1-9 are rejected for indefiniteness.
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-9 are rejected under 35 U.S.C. 103 as being unpatentable over Misuraca et al. (US 20230188361 A1 hereinafter --referred--“Misuraca”) in view of Shin US 20230327886 A1 in further view of Markham US 20170305368 in further view of Sorensen (et al. US 20210288822 A1—hereinafter –" Sorensen”).
As per claim 1: Misuraca discloses a method by which an integrated communication control unit performs authentication on a vehicle on-demand service ([0030] Typically, there are automatically generated certificates provisioned for authentication between services. Services in this context can include any services that run on vehicle devices (inclusive of their components, equipment, etc.) and that communicate to other vehicle devices. This can also include communicating with services running on the backend and interacting with other backend services. Additionally, this could include communications between the vehicle and the backend. In some cases, certificate revocation is based on values stored in the actual certificate that is sought to be revoked. This could force an architecture to track and, thereby, make a copy of every certificate that the system seeks to revoke. As can be appreciated, in robust systems, automatically generated certificates often lead to thousands, or to millions of certificates being generated per day. This number can grow exponentially depending on the scale of the fleet of vehicles being managed. The volume of certificates is such that is not feasible to maintain them for the purpose of revocation. Certain systems with short-lived certificates generally do not implement revocation because they rely purely on a shorter lifespan paradigm. [0048] In various examples, the onboard computer 104 includes a registration module and a session module (as illustrated and described below with reference to FIG. 2A). These elements can coordinate to receive certificates and to distribute the certificates to the appropriate services in the autonomous vehicle 110A. This would involve communications with the online server 120, which could assist in both session service and registration service, as detailed more fully below. In one example embodiment, the online server 120 includes (or at least maintains a logical communication pathway to) a registration service, a session service, a device certificate authority, a session certificate authority, a certificate revocation service, a device registration authority, and/or a vehicle module database to achieve the certificate revocation activities outlined herein) the method comprising:
storing, in a service authentication server, a first option value related to a vehicle service, received from a tool in factory (TIF) device ([0044] A database at the online server 120 can store account information such as subscriber authentication information, vehicle identifiers, profile records, behavioral patterns, and other pertinent subscriber information. The online server 120 may also include a database of roads, routes, locations, etc. permitted for use by AV 110A. The online server 120 may communicate with the AV 110A to provide route guidance in response to a request received from the vehicle. [0151] For new vehicle initialization, once a new vehicle is sought to be put into service, a technician can log into a web interface to access vehicle module database 846. This web application can use a two-factor authentication mechanism. At this point, a technician can enter that a new vehicle has arrived with a particular VIN. On the backend of this system, this process will subsequently create an entry in vehicle module database 846 with that VIN with no other values entered);
obtaining or generating a private key and a certificate; and generating, for each performance controller, a device certificate and a device private key signed with the private key ([0011] a method for managing a device in an AV includes communicating a device registration request for the device, wherein the device registration request includes trace data that is unique to the device; receiving a device certificate to authorize registration of the device; providing a signature for the device certificate; communicating a session registration request for the device; and receiving a signed session certificate to authorize a session for the device, wherein the signed session certificate includes a session key that is valid for a designated time period (e.g., 60 seconds, 1 hour, 24 hours, etc.). In various implementations, the communicating of the request for the device registration certificate includes: generating a keypair and a certificate signing request (CSR) based, at least in part, on the keypair. Each of these certificates can include any suitable digital information associated with authorizing, securing, or otherwise validating an identity, a device, a session, or a registration. [0031] certificates are provisioned to include a unique ID. The system discussed herein can store this unique ID in the certificate common name field (e.g., CN field), although it could be stored in any certificate field (e.g., a subject alternative name (SAN) or it could be spread out over multiple fields). The unique ID can operate as the identifier for the specific service/device. [0039] In operation, consider the general case in which a device seeks a valid device registration certificate to perform one or more computing functions for the AV. The device can generate a public/private keypair, as well as a CSR that is based on the aforementioned keypair. The device can store the private key in any suitable storage location. In one implementation, the private key can be stored in secure hardware (e.g., a TPM). The device can then extract unique identifying information about itself and other devices in the AV to form the trace data. The device can subsequently bundle up the CSR, along with the trace data, and send it to a DR service (e.g., a server). The DR server can then validate the trace data and return a signed certificate to the device).
Misuraca does not explicitly disclose the private key is a private root private key and the certificate is a private root certificate. Shin, in analogous art however, discloses the private key is a private root private key ([0149] the signed installation data type may include the contract certificate chain, encryption that the TPM supports (Encrypted for TPM), an elliptic curve Diffie-Hellman curve (ECDHCurve), a DH public key, an SECP521-encrypted private key (SECP521_EncryptedPrivateKey), X448-encrypted private key (X448_EncryptedPrivateKey), and TPM-encrypted private key (TPM_EncryptedPrivateKey). [0153] when the SA uses a first ECC curve designated in advance to generate an encryption key of the contract certificate private key through ECDHE, the SA may set the ECDHCurve parameter to ‘SECP521’. In addition, when the SA uses a second ECC curve designated in advance to generate an encryption key for encrypting the contract certificate private key through ECDHE, the SA may set the ECDHCurve parameter to ‘X448’); and the certificate is a private root certificate ([0050] “Original equipment manufacturer (OEM)”: An EV manufacturer or a server operated by the EV manufacturer. It may include a root certification authority (CA) or a root certification server that issues an OEM root certificate. [0085] The EV manufacturer (i.e., OEM) server 400 (hereinafter abbreviated as ‘OEM’) is a root certification authority (CA) that issues an OEM root certificate, and also operates and manages its subordinate certification authorities (OEM SubCA 1, OEM SubCA 2). When the EV 10 is manufactured, the OEM 400 may create an OEM provisioning certificate using an OEM intermediate chain certificate (OEM SubCA 2 cert.) and install it in the EV 10. [0104] The OEM provisioning certificate (OEM Prov cert.) and the contract certificate (Contract Certificate) may be created respectively based on the root certificates (OEM RootCA cert., MO RootCA cert.) created by the OEM and MO themselves, and may also be created based on a global root certificate (V2G RootCA cert.). They may be independent of certificates used by other actors. However, as indicated by a dashed line in FIG. 3, the OEM provisioning certificate (OEM Prov cert.) and contract certificate (Contract Certificate) may be created using the V2G root certificate (V2G RootCA cert.) instead of the root certificates (OEM RootCA cert., MO RootCA cert.) of the OEM).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the private key and certificate disclosed by Misuraca to include the private key is a private root private key and the certificate is a private root certificate. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a method for safely transmitting a message for installing a contract certificate, etc. to an EVCC that does not have a trusted platform module (TPM) in communication related to EVs, and increasing reliability of message security as suggested by Shin ([0010]).
Misuraca and Shin do not explicitly disclose generating a service token for the first option value by using the private root certificate and the private root private key; and transmitting, for each performance controller, the generated service token, the private root certificate, and the device private key. Markham, in analogous art however, discloses generating a service token for the first option value by using the private root certificate and the private root private key; and transmitting, for each performance controller, the generated service token, the private root certificate, and the device private key ([0017] The system and approach use unique authorization “tokens” that dictate exactly what level of access is granted to the VSM and/or what changes can be made to the VSM policy, and may have, for example, a public/private key pairing that is used to ensure only an authorized entity is using the token. There may be several ways to ensure that the authorization token is securely passed to and accepted by the VSM. transmitting, for each performance controller, the generated service token, the private root certificate, and the device private key. [0024] There may be many variations for securely distributing a policy change authorization token to the vehicle security module. One approach may incorporate a dongle pair. An example is given in the following. Key creation and loading of authorization token into dongle may occur. Public key material and a corresponding public key infrastructure may be created as shown in view of a diagram 60 in FIG. 2, the following items: 1) An original equipment manufacturer (OEM) 61 may create a public/private key pair at corner 62 of diagram 60; 2) A vehicle security module 63 may also create its own public/private key pair; OEM 61 may embed along line 64 the OEM public key into vehicle security module 63; 3) A policy change requestor (PCR) 65 may create a public/private key pair at a corner 66 at an end of a line 69 from corner 62 of diagram 60; 4) OEM 61 may use the OEM private key to digitally sign a certificate (e.g., X.509v3) containing a PCR 65 identity and a PCR public key; 5) Vehicle OEM 61 may create a policy change authorization token which includes the changes to the policy and a dongle ID of a set of dongles associated with this authorization token; the authorization token may be signed using the OEM private key; 6) A public/private key pair may be created for a dongle 67 at corner 68 of a line 70 from corner 66 of diagram 60; and 7) PCR 65 may use the PCR private key to sign a certificate for dongle 67 containing the dongle ID, and PCR 65 may also load a copy of the PCR certificate into dongle 67. [0025] An authorization token use may be noted. When dongle 67 is plugged into a vehicle, there may be a protocol exchange along a line 71 between corners 68 and 72, which allows the vehicle security module 63 to confirm the identity of dongle 67, allows the vehicle security module 63 to confirm that the authorization token is bound to dongle 67, and allows the vehicle security module 63 to confirm that the authorization token was authorized by vehicle OEM 61. [0064-0065] There may be multiple ways to securely pass an authorization token to the vehicle. Some of the ways may be noted herein. One way is that the vehicle manufacturer may act as a certificate authority and sign a certificate (e.g., X.509 v3) for a developer of the policy change requester. This approach may allow the policy change requester to use a local private key to generate and sign authorization tokens. The vehicle may then use the vehicle manufacturer public key to “walk the certificate chain” to validate the authorization token. [0066] Another way is that the vehicle manufacturer may create authorization tokens which combine an identity of the policy change requestor with the authorization token as an approach of binding the token to the requestor).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by Misuraca and Shin to include generating a service token for the first option value by using the private root certificate and the private root private key; and transmitting, for each performance controller, the generated service token, the private root certificate, and the device private key. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide vehicle security modules, and to keep unauthorized intruders out of them while letting in legitimate individuals (e.g., authorized mechanics) and further propose an electronic key system that gives a vehicle manufacturer an ability to dictate who can get into a vehicle security module (VSM), and once in, which portions or bits of it they can change as suggested by Markham ([0016]).
Misuraca, Shin and Markham do not explicitly disclose wherein the integrated communication control unit is included in a vehicle, and the private root private key is uniquely generated for the vehicle by the integrated communication control unit. Sorensen, in analogous art however, discloses wherein the integrated communication control unit is included in a vehicle ([0115] As illustrated, FIG. 1 shows a system 100 that includes the vehicle 102; a communications network 108; an operations computing system 104; one or more remote computing devices 106; the vehicle computing system 112; one or more sensors 114; sensor data 116; a positioning system 118; an autonomy computing system 120; map data 122; a perception system 124; a prediction system 126; a motion planning system 128; state data 130; prediction data 132; motion plan data 134; a communication system 136; a vehicle control system 138; a human-machine interface 140; and a security database 150), and
the private root private key is uniquely generated for the vehicle by the integrated communication control unit ([0154] The certificate authority 320 can include a certificate granting service running on a security process 330 of at least one of the one or more vehicle device(s) of the plurality of devices of the computing system. The plurality of devices of the computing system can include a master device 310 and one or more requesting devices. The certificate authority 320 can include a certificate granting service running as part of the security process 330 of the master device 310 of the plurality of devices. [0159] FIG. 4A depicts an intra-device process configuration process 400A according to example implementations of the present disclosure. The master device 310 can be configured to run and authenticate a plurality of processes (e.g., requesting process 440). The master device 310 can include a master host security service 420, a trusted platform module 430, a secondary orchestration service 440, and a requesting process 450. [0062] The private root key corresponding to the root certificate can include a private string of letters and/or numbers known only to the master device. For example, the private root key can include a randomly generated (e.g., via a random number generator of a respective trusted platform module) string of letters and/or numbers securely stored on one or more memories of the master device. [0163] Generally, the master device 310 can include hardware components such as one or more processors, one or more memories, a trusted platform module 430 (e.g., a TPM 2.0, etc.), and/or any additional hardware for establishing trust between processes of the master device 310. In addition, the master device 310 can include software components such as an operating system, a certificate authority 330, a secondary orchestration service 440, and/or one or more processes (e.g., requesting process 450). In addition, the master device 310 can include a master host security service 420 configured to facilitate the establishment of trust between the one or more processes).
Sorensen further discloses the private root private key is uniquely generated for the vehicle by the integrated communication control unit in ([0167] The process manifest for the requesting process 450 can include a process name, a manifest key, and/or a root certificate generated by the certificate authority 330 of the master host security service 420. The process name, for example, can include a process-specific identifier corresponding the requesting process 450. For instance, in some implementations, the vehicle computing system (e.g., the one or more vehicle devices of the plurality of devices) can be configured to run a finite number of processes. In such a case, the master host security service 420 can include and/or have access to a process name for each vehicle process configured to run on the vehicle computing system. The manifest key can include a shared cryptographic key (e.g., a symmetric key) that can be used to encrypt and decrypt one or more messages (e.g., in accordance with one or more symmetric signing techniques). In addition, or alternatively, the manifest key can include an asymmetric cryptographic key that can be used to encrypt and decrypt one or more messages (e.g., in accordance with one or more asymmetric signing techniques). And, the root certificate, for example, can include a public key certificate that identifies the certificate authority 330. [0168] For example, the certificate authority 330 can generate the root certificate and a private root key corresponding to the root certificate. The root certificate can include a public key corresponding the private root key. The public key can include a publicly accessible string of letters, numbers, and/or letters and numbers. For example, the public key can include a randomly generated (e.g., via a random number generator of trusted platform module 430) string of letters and/or numbers. The private root key corresponding to the root certificate can include a private string of letters and/or numbers known only to the master host security service 420, the certificate authority 330, and/or security process 305. For example, the private root key can include a randomly generated (e.g., via a random number generator of the trusted platform module 430) string of letters and/or numbers securely stored on one or more memories of and/or accessible to the master device 310. By way of example, the private root key can be stored on the file system of the master device 310. The private root key can be protected by one or more file system permissions to restrict accessibility of the private root key to security process 305, master host security service 420, and/or the certificate authority 330. [0169] The public key can correspond to the private root key. For example, the public key can enable a process to decrypt a value encrypted by the private root key, and/or vice versa (e.g., such as in asymmetric encryption algorithms). The certificate authority 330 can sign the root certificate with the corresponding private root key. By way of example, the certificate authority 330 can generate a signature for the root certificate. The signature, for example, can be indicative of the identity of the certificate authority (e.g., an identity of the master device 310, the security process 305, etc.) encrypted by the private root key. In this manner, the certificate authority 330 can generate a self-signed root certificate).
Sorensen further discloses ([0214] More particularly, turning to FIG. 11, FIG. 11 depicts an example process diagram 1100 for distributing trust among processes of a vehicle computing system according to example implementations of the present disclosure. The certificate authority of the master device 310 can generate a root certificate and a private root key corresponding to the root certificate (at 1102). As discussed herein with reference to FIGS. 3-6, the root certificate can include a public key corresponding the private root key. The master device 310 can sign the root certificate with the corresponding private root key. By way of example, the master device 310 can generate a signature for the root certificate. The signature, for example, can be indicative of the identity of the master device 310 (e.g., an identity certificate for the master device 310, etc.). In this manner, the master device 310 can run a certificate authority 330 that generates a self-signed root certificate and a private root key corresponding to the root certificate).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the integrated communication control unit disclosed by Misuraca, Shin and Markham is included in a vehicle, and the private root private key is uniquely generated for the vehicle by the integrated communication control unit. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide vehicle security infrastructure having cryptographic signing techniques that can be utilized to authorize different processes interacting with a vehicle as suggested by Sorensen ([0005]).
As per claim 2: Misuraca in view of Shin and in further view of Markham and Sorensen discloses the method of claim 1, wherein the private root private key and the private root certificate are generated within a secure world of the integrated communication control unit (Shin [0080] During a communication process for the charging process, the EV may first verify an identity of the charging station to identify whether it is a trusted facility, and establish a secure channel with the charging station to protect communication from unauthorized access. The secure channel may be established by a transport layer security (TLS). A TLS session may be performed according to a TLS session establishment procedure after an Internet protocol (IP)-based communication connection establishment procedure).
As per claim 3: Misuraca in view of Shin and in further view of Markham and Sorensen discloses the method of claim 2, wherein the service token is generated within a normal world of the integrated communication control unit (Markham [0031] 5) The vehicle security module may the use an OEM public key to validate a digital signature on an authorization token. Assuming the digital signature to be valid, the vehicle security module may know that the authorization token is authorized by the vehicle OEM).
As per claim 4: Misuraca in view of Shin and in further view of Markham and Sorensen discloses the method of claim 1, wherein the private root private key and the private root certificate are generated in the service authentication server of the integrated communication control unit (Shin [0085] The EV manufacturer (i.e., OEM) server 400 (hereinafter abbreviated as ‘OEM’) is a root certification authority (CA) that issues an OEM root certificate, and also operates and manages its subordinate certification authorities (OEM SubCA 1, OEM SubCA 2). When the EV 10 is manufactured, the OEM 400 may create an OEM provisioning certificate using an OEM intermediate chain certificate (OEM SubCA 2 cert.) and install it in the EV 10).
As per claim 5: Misuraca in view of Shin and in further view of Markham and Sorensen discloses the method of claim 4, wherein the service token is generated within a normal world of the integrated communication control unit (Markham [0039] 6) An authorization token distribution—the authorization token may be distributed via the dongle such that the dongle is the transport mechanism. The authorization token may be embedded in the VSM firmware and activated when an authorized dongle authenticates itself to the VSM. The authorization token may be fetched in real time by either the VSM or the dongle.
As per claim 6: Misuraca in view of Shin and in further view of Markham and Sorensen discloses the method of claim 1, wherein the generating of the service token comprises:
generating an advanced encryption standard (AES) symmetric key, AES-encoding the first option value, and storing the same in a payload field in the service token (Shin [0118] In other words, the contract private key 380 may be encrypted with an advanced encryption standard (AES) in a Galois/counter mode (GCM) having an authentication tag based on an elliptic-curve Diffie-Hellman (EDCH) shared secret key generated from the public key 412 of the OEM provisioning certificate 411. The ECDH shared secret key may correspond to the encryption parameter M3).
encoding the AES symmetric key with the device certificate by using Rivest, Shamir, Adleman (RSA), and adding the same to a header field in the service token; and digitally signing the service token with the private root private key (Shin [0117] In addition, in the encryption of the contract certificate private key, that is, the contract private key K1, the contract public key 370 of the contract certificate, an encryption parameter M3 of an OEM provisioning public key (prov. public key) 412 included in the OEM provisioning certificate (prov. certificate) 411, and an ephemeral DH public key K2 372 may be used. A data packet (CCDP) of the encrypted contract private key K1 may include a mobility account identifier (eMAID) corresponding to the EV user).
As per claim 7: Claim 7 is directed to a method by which an integrated communication control unit for performing authentication on a vehicle on-demand service, wherein the integrated communication control unit having substantially similar corresponding claimed limitation features of claim 1, except claim 7 is reciting “a second option value” while claim 1 is reciting “a first option value”. However, under BRI consideration the difference between “a first option value” of claim 1 and “a second option value” of claim 7 is not established or recited in the respective claims and therefore claim 7 is rejected with the same rationale given above to reject claim 1.
As per claim 8: Claim 8 is directed to an integrated communication control unit for performing authentication on a vehicle on-demand service, wherein the integrated communication control unit having substantially similar corresponding claimed limitation features of claim 1 and therefore, claim 8 is rejected with the same rationale given above to reject claim 1.
As per claim 9: Claim 9 is directed to a computer-readable recording medium having recorded thereon a program for executing the method of claim 1 on a computer, claim 9 having substantially similar corresponding claimed limitation features of claim 1 and therefore claim 9 is rejected with the same rationale given above to reject claim 1.
BRI (Broadest Reasonable Interpretation)
The above claims under examination have been given their BRI consistent with the applicant’s disclosure as they would be interpreted by one of ordinary skill in the art at the time of filing of the invention. In order to construe, appraise boundary and scope of the claimed limitations, the following claim words or terms or phrases or languages have been given to them their BRI considerations and context in view of the applicant’s disclosure. For example, for the following claim words or terms or phrases or languages, the examiner recites BRI considerations from the applicant’s disclosure as follows:
Private Root Private key [Application: 0043] The private root private key is a key issued by the service authentication server 122 and may be used to generate a private root certificate. The private root certificate is a private root CA certificate issued by the service authentication server 122. [0070] Then, the service agent 121 requests the service authentication server 122 to generate a private root key (operation 503). According to an embodiment, the private root key may include the private root private key and the private root certificate (also referred to as a private root public key). The private root key be characterized in using an asymmetric key, being stored in the integrated communication control unit 120, and being generated in only one pair.
Vehicle On-Demand [Application 0030] According to an embodiment, the vehicle on-demand service is a function that allows a consumer to selectively purchase a software function according to his/her needs, and is a function that is installed in a vehicle and allows the consumer to customize a desired vehicle function whenever he/she wants. A vehicle equipped with the vehicle on-demand service is also referred to as a software defined vehicle (SDV). According to an embodiment, a consumer who has purchased an SDV may activate a desired function by additionally purchasing the function for a set period of time (permanently or for a specific period) by using the vehicle on-demand service. [0031] Also, the vehicle on-demand service according to an embodiment is executed based on a public key infrastructure (PKI) in a secure world of the integrated communication control unit, and thus, the vehicle on-demand service may be safely provided against hacking, and the service authentication system 100 of the disclosure may implement the same.
First/Second Option value [Application: 0068] Referring to FIG. 5, first, the TIF device 150 injects the first option value (the service pre-purchase option value as service data) into the service agent 121 of the integrated communication control unit 120 (operation 501). [0091] First, the DM server 110 stores a service post-purchase option value obtained from the purchase server 140, in the database. In the following specification, the service pre-purchase option value may be referred to as a second option value. Here, a security requirement ID is SRV02.
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure. See the notice of reference cited in form PTO-892 for additional prior arts.
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 TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6: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, LINGLAN EDWARDS can be reached at (571) 270-5440. 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.
/TECHANE GERGISO/Primary Examiner, Art Unit 2408 1