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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claim 20 is objected to because of the following informalities: last limitation recites “… receive the service response from the second network element; and send the service response to the second network element.” – A system typically does not receive the response and send the received response to the same system/entity. It appears to be a typographical error. Appropriate correction is required.
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: “… the first network element is configured to: calculate…, … the second network element is configured to: receive …” in claim 17.
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.
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.
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 – 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims of U.S. Patent No. 12052233. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant application claims are made obvious by said patent claims and further in view of Brockhaus et al (US 10,511,587), Bro and Birgisson et al (US 20170214664), Bir.
Instant App. 18786610
Patent No. 12052233
1. (New) An identity verification method for a network function service, comprising: calculating, by a first network element, an input parameter using a private key corresponding to a public key in a certificate to obtain a digital signature, wherein the input parameter comprises information about a second network element, the first network element is a requester of the network function service, and the second network element is a provider of the network function service or a control plane network element; sending, by the first network element, a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; and receiving, by the first network element, a service response from the serving communication proxy in the case that the digital signature is verified to be correct and an identity of the first network element in the certificate is consistent with an identity of the first network element in the token.
2. (New) The identity verification method according to claim 1, wherein the information about the second network element comprises at least one of a type of the second network element, a group identifier of the second network element, a set identifier of the second network element, or address information of the second network element.
3. (New) The identity verification method according to claim 1, wherein the input parameter further comprises information about a consumer service communication proxy, and the information about the consumer service communication proxy comprises at least one of the following: an instance identifier of the consumer service communication proxy, address information of the consumer service communication proxy, a group identifier of the consumer service communication proxy, or a set identifier of the consumer service communication proxy.
4. (New) The identity verification method according to claim 1, wherein the input parameter further comprises slice information, and the slice information comprises a network slice instance identifier or single network slice selection assistance information (S-NSSAI).
5. (New) The identity verification method according to claim 1, wherein the input parameter further comprises at least one of the token or the identity of the first network element.
6. (New) The identity verification method according to claim1, further comprising: receiving, by the first network element, an error code from the serving communication agent in the case that the digital signature is verified to be incorrect or the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token.
7. (New) An identity verification method for a network function service, comprising: receiving, by a second network element, a service request from a serving communication proxy, wherein the service request comprises a digital signature, a certificate, and a token; verifying, by the second network element, whether the digital signature is correct based on the certificate and whether an identity of a first network element in the certificate is consistent with an identity of the first network element in the token, wherein the first network clement is a requester of the network function service, and the second network element is a provider of the network function service or a control plane network element; and when the digital signature is verified to be correct and the identity of the first network element in the certificate is consistent with the identity of the first network element in the token, sending, by the second network element, a service response.
8. (New) The identity verification method according to claim 7, further comprising: when the digital signature is verified to be incorrect or the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token, sending, by the second network element, an error code.
9. (New) The identity verification method according to claim 8, wherein the error code indicates that the digital signature is verified to be incorrect, or the error code indicates that the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token.
10. (New) An apparatus comprising: a memory storing executable instructions; and a processor configured to execute the executable instructions to: calculate an input parameter using a private key corresponding to a public key in a certificate to obtain a digital signature, wherein the input parameter comprises information about a second network element, the apparatus is a requester of a network function service, and the second network element is a provider of the network function service or a control plane network element; send a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; and receive a service response from the serving communication proxy in the case that the digital signature is verified to be correct and an identity of the apparatus in the certificate is consistent with an identity of the apparatus in the token.
11. (New) The apparatus according to claim 10, wherein the information about the second network element comprises at least one of a type of the second network clement, a group identifier of the second network element, a set identifier of the second network clement, or address information of the second network clement.
12. (New) The apparatus according to claim 10, wherein the input parameter further comprises at least one of the token or the identity of the apparatus.
13. (New) The apparatus according to claim 10, wherein the processor is further configured to: receive an error code from the serving communication agent in the case that the digital signature is verified to be incorrect or the identity of the apparatus in the certificate is inconsistent with the identity of the apparatus in the token.
14. (New) An apparatus comprising: a memory storing executable instructions; and a processor configured to execute the executable instructions to: receive a service request from a serving communication proxy, wherein the service request comprises a digital signature, a certificate, and a token; verify whether the digital signature is correct based on the certificate and whether an identity of a first network element in the certificate is consistent with an identity of the first network element in the token, wherein the first network element is a requester of a network function service, and the apparatus is a provider of the network function service or a control plane network element; and when the digital signature is verified to be correct and the identity of the first network element in the certificate is consistent with the identity of the first network element in the token, send a service response.
15. (New) The apparatus according to claim 14, wherein the processor is further configured to: when the digital signature is verified to be incorrect or the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token, send an error code.
16. (New) The apparatus according to claim 14, wherein the error code indicates that the digital signature is verified to be incorrect, or the error code indicates that the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token.
17. (New) A system comprising: a first network element; and a second network element, wherein the first network element is a requester of a network function service, the second network element is a provider of the network function service or a control plane network element, and wherein the first network element is configured to: calculate an input parameter using a private key corresponding to a public key in a certificate to obtain a digital signature, wherein the input parameter comprises information about the second network element; andsend a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token, wherein the second network element is configured to: receive the service request from the serving communication proxy; verify whether the digital signature is correct based on the certificate and whether the identity of the first network element in the certificate is consistent with the identity of the first network element in the token; and when the digital signature is verified to be correct and the identity of the first network element in the certificate is consistent with the identity of the first network element in the token, send a service response to the serving communication proxy, wherein the first network element is further configured to: receive the service response from the serving communication proxy.
18. (New) The system according to claim 17, wherein the information about the second network element comprises a type of the second network element, and the input parameter further comprises the identity of the first network element.
19. (New) The system according to claim 17, wherein the second network element is further configured to: when the digital signature is verified to be incorrect or the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token, send an error code to the serving communication proxy, and wherein the first network element is further configured to: receive the error code from the serving communication proxy.
20. (New) The system according to claim 17, wherein the system comprises the serving communication proxy, and the communication proxy is configured to: receive the service request from the first network element; send the service request to the second network element; receive the service response from the second network element; and send the service response to the second network element.
(Currently Amended) An identity verification method performed by a managing network element in a service network, comprising: receiving, via the service network, a network function (NF) service request from a requesting network element in the service network, wherein the NF service request comprises a service token for a first NF service provided by the managing network element, the service token is provided by a service token server of the service network for the first NF service and comprises first certificate information, wherein the first certificate information is related to a certificate of a requester of the service token and comprises identity information of the requester of the service token as used in the certificate of the requester of the service token, wherein the managing network element is a control plane network element of the service network, and the first certificate information comprises an identifier or an NF type of the requester of the service token; obtaining, via the service network, a certificate of the requesting network element; determining
2. (Canceled)
3. (Previously Presented) The method according to claim 1, wherein the identity information of the requester of the service token in the first certificate information comprises an identifier of
4. (Previously Presented) The method according to claim 1, wherein the first certificate information comprises an NF type of the requester of the service token, and the certificate of the requesting network element indicates an NF type of the requesting network element.
5. (Canceled)
6. (Currently Amended) A requester identity verification method performed by a requesting network element in a service network, comprising:
obtaining, from a service token server in the service network, a service token corresponding to a first NF service provided by a managing network element in the service network, wherein the service token comprises first certificate information related to a certificate of a requester of the service token and comprising identity information of the requester of the service token as used in the certificate of the requester of the service token, wherein the managing network element is a control plane network element of the service network, and the first certificate information comprises an identifier or an NF type of the requester of the service token;
sending an NF service request for the first NF service to the managing network element, wherein the NF service request comprises the service token; and
receiving a reject message from the managing network element, wherein receiving the reject message indicates that the managing network element fails to verify the requesting network element based on the service token in the NF service request.
7. (Previously Presented) The method according to claim 6, wherein the identity information in the first certificate information comprises an identifier of the requester of the service token.
8. (Previously Presented) The method according to claim 6, wherein the identity information in the first certificate information comprises an NF type of the requester of the service token.
9. (Previously Presented) The method according to claim 6, wherein the step of obtaining the service token corresponding to the first NF service comprises:
sending a token obtaining request to the service token server in a control plane network of the service network; and
receiving, by the requesting network element, the service token returned by the service token server.
10. (Currently Amended) A network element in a service network comprising:
a transceiver for network communications;
a memory storing executable instructions;
a processor configured to execute the executable instructions to:
receive, via the service network, a network function (NF) service request for a first NF service from a requesting network element in the service network, wherein the NF service request comprises a service token provided by a service token server of the service network for the first NF service, the service token comprises first certificate information related to a certificate of a requester of the service token and comprising identity information of the requester of the service token as used in the certificate of the requester of the service token, wherein the network element is a control plane network element of the service network, and the first certificate information comprises an identifier or an NF type of the requester of the service token;
obtaining, via the service network, a certificate of the requesting network element;
determine whether the identity information of the requester of the service token in the first certificate information is consistent with identity information of the requesting network element in the certificate of the requesting network element; and
upon determining that the identity information of the requester in the service token in the first certificate information is inconsistent with the identity information of the requesting network element in the certificate of the requesting network element, reject the NF service request.
11. (Previously Presented) The network element according to claim 10, wherein the processor is further configured to:
process the NF service request when the identity information of the requester of the service token in represented by the first certificate information is consistent with the identity information of the requesting network element in the certificate of the requesting network element.
12. (Canceled)
13. (Canceled)
14. (Currently Amended) The network element according to claim 10 identifier of the requesting network element.
15. (Currently Amended) The network element according to claim 10
Pat. # 12052233 teaches the concept of instant application but is silent on sending, by the first network element, a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; and receiving, by the first network element, an error code from the serving communication agent in the case that the digital signature is verified to be incorrect or the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token.
But analogous art Bro teaches sending, by the first network element, a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; (C6L35-47: the device sends a request message CSReq including the public key Kpub..., an identifier IDxn, (the serial number of the device), information about the domain in which the device is installed Wx, a digital signature generated using any authentication parameter such as the private key related to the device certificate, and also the device certificate itself).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of 12052233 to include the idea of sending service request comprising the digital signature, the certificate, and a token as taught by Bro so that hackers attacking an automatic enrollment process is repelled with high probability, as they would have to fulfill all conditions implied by the context information (C2L57-59).
Analogous art Bir teaches receiving, by the first network element, an error code from the serving communication agent in the case that the digital signature is verified to be incorrect or the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token. ([012] receiving a cryptographic hash of the token data, determining that the received cryptographic hash is invalid, generating an error message indicative of the invalid hash, and transmitting the error message to the client device).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of 12052233 and Bro to include the idea of error code when signature is invalid as taught by Bir so that the security of communications sessions between devices can be enhanced [07].
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1 – 5, 7, 10 – 12, 14, 17, 18, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Li et al (US 20190373471), Li and Brockhaus et al (US 10,511,587), Bro.
Claim 1: Li teaches a identity verification method for a network function service, comprising: calculating, by a first network element, an input parameter using a private key corresponding to a public key in a certificate to obtain a digital signature ([025-26] the request includes a digital signature that is established using the private key associated with the managing entity … where the managing entity possesses a public key that is counterpart to the private key. [033] Certificates used for authentication and confidentiality purposes are generated by a trusted certificate issuer).
wherein the input parameter comprises information about a second network element, the first network element is a requester of the network function service, and the second network element is a provider of the network function service or a control plane network element; ([053] Responsive to receipt of the user input, the existing device sends a swap account message which includes the carrier token and additional information and/or credentials, … and one or more equipment identifiers (EIDs) (i.e., input param). [039, Fig. 1] the existing device (i.e., requester)110 sends a message to the entitlement server (i.e., provider) to sign up for cellular wireless service for the new device 150).
and receiving, by the first network element, a service response from the serving communication proxy in the case that the digital signature is verified to be correct and an identity of the first network element in the certificate is consistent with an identity of the first network element in the token. ([027] when the MNO verifies that the digital signature is valid and that the trust score is satisfactory, the MNO can provide the authentication token to the existing mobile device… [041, 62] The entitlement server verifies the carrier token obtained from the existing device and responds with additional credentials and/or information, an EID, a fully qualified domain name (FQDN), and the new eICCID).
Li is silent on sending, by the first network element, a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token;
But analogous art Bro teaches sending, by the first network element, a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; (C6L35-47: the device sends a request message CSReq including the public key Kpub..., an identifier IDxn, (the serial number of the device), information about the domain in which the device is installed Wx, a digital signature generated using any authentication parameter such as the private key related to the device certificate, and also the device certificate itself).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Li to include the idea of sending service request comprising the digital signature, the certificate, and a token as taught by Bro so that hackers attacking an automatic enrollment process is repelled with high probability, as they would have to fulfill all conditions implied by the context information (C2L57-59).
Claim 2: the combination of Li and Bro teaches the identity verification method according to claim 1, wherein the information about the second network element comprises at least one of a type of the second network element, a group identifier of the second network element, a set identifier of the second network element, or address information of the second network element. (Li: [053] credentials include an EID, a fully qualified domain name (FQDN), and/or a new eICCID).
Claim 3: the combination of Li and Bro teaches the identity verification method according to claim 1, wherein the input parameter further comprises information about a consumer service communication proxy, and the information about the consumer service communication proxy comprises at least one of the following: an instance identifier of the consumer service communication proxy, address information of the consumer service communication proxy, a group identifier of the consumer service communication proxy, or a set identifier of the consumer service communication proxy. (Li: [038] The pre-flight request can include the information provided by the remote server including the trust score, credentials, and nonce as signed by the entitlement server).
Claim 4: the combination of Li and Bro teaches the identity verification method according to claim 1, wherein the input parameter further comprises slice information, and the slice information comprises a network slice instance identifier or single network slice selection assistance information (S-NSSAI). (Li: [041] entitlement server verifies and responds with additional credentials and/or information such as an EID, a fully qualified domain name (FQDN), and the new eICCID (i.e., slice)).
Claim 5: the combination of Li and Bro teaches the identity verification method according to claim 1, wherein the input parameter further comprises at least one of the token or the identity of the first network element. (Li: [012] the current device can provide the carrier token obtained from the entitlement server).
Claim 7: Li teaches an identity verification method for a network function service, comprising: verifying, by the second network element, whether the digital signature is correct based on the certificate and whether an identity of a first network element in the certificate is consistent with an identity of the first network element in the token, wherein the first network element is a requester of the network function service, and the second network element is a provider of the network function service or a control plane network element; and when the digital signature is verified to be correct and the identity of the first network element in the certificate is consistent with the identity of the first network element in the token, sending, by the second network element, a service response. ([025-26] the request includes a digital signature that is established using the private key associated with the managing entity… where the managing entity possesses a public key that is counterpart to the private key. [033] Certificates used for authentication and confidentiality purposes are generated by a trusted certificate issuer; [053] Responsive to receipt of the user input, the existing device sends a swap account message which includes the carrier token and additional information and/or credentials, such as an ICCID associated with a SIM card, an eICCID associated with an eSIM, and one or more equipment identifiers (EIDs). [039, Fig. 1] the existing device 110 sends a message to the entitlement server to sign up for cellular wireless service for the new device 150; [027] when the MNO verifies that the digital signature is valid and that the trust score is satisfactory, the MNO can provide the authentication token to the existing mobile device… [041, 62] The entitlement server verifies the carrier token obtained from the existing device and responds with additional credentials and/or information, an EID, a fully qualified domain name (FQDN), and the new eICCID).
Li is silent on receiving, by a second network element, a service request from a serving communication proxy, wherein the service request comprises a digital signature, a certificate, and a token;
But analogous art Bro teaches receiving, by a second network element, a service request from a serving communication proxy, wherein the service request comprises a digital signature, a certificate, and a token; (C6L35-47: the device sends a request message CSReq including the public key Kpub..., an identifier IDxn, (the serial number of the device), information about the domain in which the device is installed Wx, a digital signature generated using any authentication parameter such as the private key related to the device certificate, and also the device certificate itself).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Li to include the idea of sending service request comprising the digital signature, the certificate, and a token as taught by Bro so that hackers attacking an automatic enrollment process is repelled with high probability, as they would have to fulfill all conditions implied by the context information (C2L57-59).
Claim 10: Li teaches an apparatus comprising: a memory storing executable instructions; and a processor configured to execute the executable instructions to (Fig. 7): calculate an input parameter using a private key corresponding to a public key in a certificate to obtain a digital signature, wherein the input parameter comprises information about a second network element, the apparatus is a requester of a network function service, and the second network element is a provider of the network function service or a control plane network element; and receive a service response from the serving communication proxy in the case that the digital signature is verified to be correct and an identity of the apparatus in the certificate is consistent with an identity of the apparatus in the token. ([025-26] the request includes a digital signature that is established using the private key associated with the managing entity… where the managing entity possesses a public key that is counterpart to the private key. [033] Certificates used for authentication and confidentiality purposes are generated by a trusted certificate issuer; [053] Responsive to receipt of the user input, the existing device sends a swap account message which includes the carrier token and additional information and/or credentials, such as an ICCID associated with a SIM card, an eICCID associated with an eSIM, and one or more equipment identifiers (EIDs). [039, Fig. 1] the existing device 110 sends a message to the entitlement server to sign up for cellular wireless service for the new device 150; [027] when the MNO verifies that the digital signature is valid and that the trust score is satisfactory, the MNO can provide the authentication token to the existing mobile device… [041, 62] The entitlement server verifies the carrier token obtained from the existing device and responds with additional credentials and/or information, an EID, a fully qualified domain name (FQDN), and the new eICCID).
Li is silent on send a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token;
But analogous art Bro teaches send a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; (C6L35-47: the device sends a request message CSReq including the public key Kpub..., an identifier IDxn, (the serial number of the device), information about the domain in which the device is installed Wx, a digital signature generated using any authentication parameter such as the private key related to the device certificate, and also the device certificate itself).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Li to include the idea of sending service request comprising the digital signature, the certificate, and a token as taught by Bro so that hackers attacking an automatic enrollment process is repelled with high probability, as they would have to fulfill all conditions implied by the context information (C2L57-59).
Claim 11: the combination of Li and Bro teaches the apparatus according to claim 10, wherein the information about the second network element comprises at least one of a type of the second network element, a group identifier of the second network element, a set identifier of the second network clement, or address information of the second network element. (Li: [053] credentials include an EID, a fully qualified domain name (FQDN), and/or a new eICCID).
Claim 12: the combination of Li and Bro teaches the apparatus according to claim 10, wherein the input parameter further comprises at least one of the token or the identity of the apparatus. (Li: [012] the current device can provide the carrier token obtained from the entitlement server).
Claim 14: Li teaches an apparatus comprising: a memory storing executable instructions; and a processor configured to execute the executable instructions to (Fig. 7): verify whether the digital signature is correct based on the certificate and whether an identity of a first network element in the certificate is consistent with an identity of the first network element in the token, wherein the first network element is a requester of a network function service, and the apparatus is a provider of the network function service or a control plane network element; and when the digital signature is verified to be correct and the identity of the first network element in the certificate is consistent with the identity of the first network element in the token, send a service response. ([025-26] the request includes a digital signature that is established using the private key associated with the managing entity… where the managing entity possesses a public key that is counterpart to the private key. [033] Certificates used for authentication and confidentiality purposes are generated by a trusted certificate issuer; [053] Responsive to receipt of the user input, the existing device sends a swap account message which includes the carrier token and additional information and/or credentials, such as an ICCID associated with a SIM card, an eICCID associated with an eSIM, and one or more equipment identifiers (EIDs). [039, Fig. 1] the existing device 110 sends a message to the entitlement server to sign up for cellular wireless service for the new device 150; [027] when the MNO verifies that the digital signature is valid and that the trust score is satisfactory, the MNO can provide the authentication token to the existing mobile device… [041, 62] The entitlement server verifies the carrier token obtained from the existing device and responds with additional credentials and/or information, an EID, a fully qualified domain name (FQDN), and the new eICCID).
Li is silent on receive a service request from a serving communication proxy, wherein the service request comprises a digital signature, a certificate, and a token;
But analogous art Bro teaches receive a service request from a serving communication proxy, wherein the service request comprises a digital signature, a certificate, and a token; (C6L35-47: the device sends a request message CSReq including the public key Kpub..., an identifier IDxn, (the serial number of the device), information about the domain in which the device is installed Wx, a digital signature generated using any authentication parameter such as the private key related to the device certificate, and also the device certificate itself).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Li to include the idea of sending service request comprising the digital signature, the certificate, and a token as taught by Bro so that hackers attacking an automatic enrollment process is repelled with high probability, as they would have to fulfill all conditions implied by the context information (C2L57-59).
Claim 17: Li teaches a system comprising: a first network element; and a second network element, wherein the first network element is a requester of a network function service, the second network element is a provider of the network function service or a control plane network element, and wherein the first network element is configured to (Fig. 7): calculate an input parameter using a private key corresponding to a public key in a certificate to obtain a digital signature, wherein the input parameter comprises information about the second network element; and, wherein the second network element is configured to: receive the service request from the serving communication proxy; verify whether the digital signature is correct based on the certificate and whether the identity of the first network element in the certificate is consistent with the identity of the first network element in the token; and when the digital signature is verified to be correct and the identity of the first network element in the certificate is consistent with the identity of the first network element in the token, send a service response to the serving communication proxy, wherein the first network element is further configured to: receive the service response from the serving communication proxy. ([025-26] the request includes a digital signature that is established using the private key associated with the managing entity… where the managing entity possesses a public key that is counterpart to the private key. [033] Certificates used for authentication and confidentiality purposes are generated by a trusted certificate issuer; [053] Responsive to receipt of the user input, the existing device sends a swap account message which includes the carrier token and additional information and/or credentials, such as an ICCID associated with a SIM card, an eICCID associated with an eSIM, and one or more equipment identifiers (EIDs). [039, Fig. 1] the existing device 110 sends a message to the entitlement server to sign up for cellular wireless service for the new device 150; [027] when the MNO verifies that the digital signature is valid and that the trust score is satisfactory, the MNO can provide the authentication token to the existing mobile device… [041, 62] The entitlement server verifies the carrier token obtained from the existing device and responds with additional credentials and/or information, an EID, a fully qualified domain name (FQDN), and the new eICCID).
Li is silent on send a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token;
But analogous art Bro teaches send a service request to a serving communication proxy, wherein the service request comprises the digital signature, the certificate, and a token; (C6L35-47: the device sends a request message CSReq including the public key Kpub..., an identifier IDxn, (the serial number of the device), information about the domain in which the device is installed Wx, a digital signature generated using any authentication parameter such as the private key related to the device certificate, and also the device certificate itself).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Li to include the idea of sending service request comprising the digital signature, the certificate, and a token as taught by Bro so that hackers attacking an automatic enrollment process is repelled with high probability, as they would have to fulfill all conditions implied by the context information (C2L57-59).
Claim 18: the combination of Li and Bro teaches the system according to claim 17, wherein the information about the second network element comprises a type of the second network element, and the input parameter further comprises the identity of the first network element. (Li: [053] credentials include an EID, a fully qualified domain name (FQDN), and/or a new eICCID; [042-43, Fig. 3] the first mobile device is added to an existing wireless service account without requiring use of MNO login credentials … the second mobile device authenticates with an entitlement server associated with the MNO, such as by providing SIM data that is possessed by the second mobile device).
Claim 20: the combination of Li and Bro teaches the system according to claim 17, wherein the system comprises the serving communication proxy, and the communication proxy is configured to: receive the service request from the first network element; send the service request to the second network element; receive the service response from the second network element; and send the service response to the second network element. ([035-039, Fig. 1]: The remote server 120 provides information that assists with authentication by the network-based servers to validate providing cellular wireless service to the new wireless device. At 132, the existing device 110 performs an extensible authentication protocol (EAP) authentication key agreement (AKA) procedure with an entitlement server 130 of an MNO to establish a secure communication link between the existing device 110 and the entitlement server 130. At 112, the existing device 110 initiates authentication with the entitlement server 130, which responds to the existing device 110 at 134 with a nonce generated at 133. At 113, the existing device 110 sends an authentication request to the remote server 120 to obtain a trust score from the remote server).
Claim(s) 6, 8, 9, 13, 15, 16, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Li and Bro as applied to claims above, and further in view of Birgisson et al (US 20170214664), Bir.
Claim 6: the combination of Li and Bro teaches the identity verification method according to claim 1, analogous art Bir teaches further comprising: receiving, by the first network element, an error code from the serving communication agent in the case that the digital signature is verified to be incorrect or the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token. ([012] receiving a cryptographic hash of the token data, determining that the received cryptographic hash is invalid, generating an error message indicative of the invalid hash, and transmitting the error message to the client device).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Li and Bro to include the idea of error code when signature is invalid as taught by Bir so that the security of communications sessions between devices can be enhanced [07].
Claim 8: the combination of Li and Bro teaches the identity verification method according to claim 7, analogous art Bir teaches further comprising: when the digital signature is verified to be incorrect or the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token, sending, by the second network element, an error code. ([012] receiving a cryptographic hash of the token data, determining that the received cryptographic hash is invalid, generating an error message indicative of the invalid hash, and transmitting the error message to the client device).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Li and Bro to include the idea of error code when signature is invalid as taught by Bir so that the security of communications sessions between devices can be enhanced [07].
Claim 9: the combination of Li and Bro teaches the identity verification method according to claim 8, analogous art Bir teaches wherein the error code indicates that the digital signature is verified to be incorrect, or the error code indicates that the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token. ([061] determine that the computed digital signature fails to match the received digital signature, client device establishes that resource device failed to prove its possession of the client-specific cryptographic key, and client device transmits a message indicative of a failed connection to resource device).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Li and Bro to include the idea of error code when signature is invalid as taught by Van so that the said control access server determines in a request validation step whether for the authenticated secret mobile communication device identifying code, the access request to the protected area within said predetermined time period of access is a validated access request for the authenticated secret mobile communication device identifying code [0138].
Claim 13: the combination of Li and Bro teaches the apparatus according to claim 10, wherein the processor is further configured to: receive an error code from the serving communication agent in the case that the digital signature is verified to be incorrect or the identity of the apparatus in the certificate is inconsistent with the identity of the apparatus in the token. ([012] receiving a cryptographic hash of the token data, determining that the received cryptographic hash is invalid, generating an error message indicative of the invalid hash, and transmitting the error message to the client device).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Li and Bro to include the idea of error code when signature is invalid as taught by Bir so that the security of communications sessions between devices can be enhanced [07].
Claim 15: the combination of Li and Bro teaches the apparatus according to claim 14, wherein the processor is further configured to: when the digital signature is verified to be incorrect or the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token, send an error code. ([012] receiving a cryptographic hash of the token data, determining that the received cryptographic hash is invalid, generating an error message indicative of the invalid hash, and transmitting the error message to the client device).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Li and Bro to include the idea of error code when signature is invalid as taught by Bir so that the security of communications sessions between devices can be enhanced [07].
Claim 16: the combination of Li and Bro teaches the apparatus according to claim 14, wherein the error code indicates that the digital signature is verified to be incorrect, or the error code indicates that the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token. ([061] determine that the computed digital signature fails to match the received digital signature, client device establishes that resource device failed to prove its possession of the client-specific cryptographic key, and client device transmits a message indicative of a failed connection to resource device).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Li and Bro to include the idea of error code when signature is invalid as taught by Van so that the said control access server determines in a request validation step whether for the authenticated secret mobile communication device identifying code, the access request to the protected area within said predetermined time period of access is a validated access request for the authenticated secret mobile communication device identifying code [0138].
Claim 19: the combination of Li and Bro teaches the system according to claim 17, wherein the second network element is further configured to: when the digital signature is verified to be incorrect or the identity of the first network element in the certificate is inconsistent with the identity of the first network element in the token, send an error code to the serving communication proxy, and wherein the first network element is further configured to: receive the error code from the serving communication proxy. ([012] receiving a cryptographic hash of the token data, determining that the received cryptographic hash is invalid, generating an error message indicative of the invalid hash, and transmitting the error message to the client device).
Therefore, it is prima facie obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined inventions of Li and Bro to include the idea of error code when signature is invalid as taught by Bir so that the security of communications sessions between devices can be enhanced [07].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Badri Champakesan whose telephone number is (571)270-3867. The examiner can normally be reached M-F: 8.30am-4.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, Jung Kim can be reached at (571) 272-3804. 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.
/BADRINARAYANAN /Primary Examiner, Art Unit 2494.