DETAILED ACTION
This action is in response to new application titled “SECURITY IMPLEMENTATION METHOD AND APPARATUS, DEVICE, AND NETWORK ELEMENT” filed 9/24/2024. Claims 1-20 were received for consideration.
Priority
Acknowledgment is made of applicant's claim for foreign priority under 35 U.S.C. 119(a)-(d). The certified copy has been received.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/13/2025 and 9/24/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-3, 12, 13 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Ying et al (US 2019/0335332).
With respect to claim 1 Ying teaches a security implementation method, wherein the method comprises:
sending, by a first device, first information, wherein the first device is associated with at least one second device; the first information comprises a device authentication code (DAC) and/or a service authentication code (SAC) (see Ying paragraph 0149-0151 i.e. Step 102: The relay device generates a first request message based on the communication request. The first request message includes the identifier of the remote device. Optionally, the first request message is a non-access stratum (NAS) message between the relay device (relay) and the mobility management entity (MME). In an example, after receiving the communication request from the remote device, the relay device may encapsulate related content of the communication request into the first request message of the relay device); and
the DAC is used to authenticate an association relationship between the first device and the at least one second device, and the SAC is used to authenticate whether the first device and/or the at least one second device support/supports a service type indicated by service identifier information, and/or whether the first device and/or the at least one second device support/supports a data type indicated by data identifier information (see Ying paragraph 0153 i.e. Specifically, the related content encapsulated into the first request message includes the identifier of the remote device in step 101, and may further include the NAS message of the remote device in step 101. Optionally, when the communication request in step 101 further includes the relay service code or the first random number, the related content encapsulated into the first request message further includes the relay service code or the first random number. The relay service code is used to represent a service type to be requested by the remote device, and is used for verifying the association relationship between the remote device and the relay device and paragraph 0204 i.e. When the communication request sent by the remote device to the relay device further includes the relay service code, the first request message generated by the relay device through integration also includes the relay service code, and the relay service code is used to represent a service type to be requested by the remote device).
With respect to claim 2 Ying teaches the method according to claim 1, wherein the first information further comprises at least one of the following: service identifier information, wherein the service identifier information is used to indicate a service type supported by the first device and/or the at least one second device; data identifier information, wherein the service identifier information is used to indicate a data type supported by the first device and/or the at least one second device; identifier information of the first device; identifier information of each of the at least one second device; a device key Secret; or a first message authentication code (MAC) corresponding to the first information, wherein the first MAC is used to authenticate whether a sender of the first information is a valid device (see Ying paragraph 0153 i.e. Specifically, the related content encapsulated into the first request message includes the identifier of the remote device in step 101, and may further include the NAS message of the remote device in step 101. Optionally, when the communication request in step 101 further includes the relay service code or the first random number, the related content encapsulated into the first request message further includes the relay service code or the first random number. The relay service code is used to represent a service type to be requested by the remote device, and is used for verifying the association relationship between the remote device and the relay device and paragraph 0204 i.e. When the communication request sent by the remote device to the relay device further includes the relay service code, the first request message generated by the relay device through integration also includes the relay service code, and the relay service code is used to represent a service type to be requested by the remote device).
With respect to claim 3 Ying teaches the method according to claim 1, before the sending, by a first device, first information, further comprising: generating, by the first device, the DAC based on a device key Secret; and/or generating, by the first device, the SAC based on at least one of identifier information of the first device, identifier information of each second device, service identifier information, data identifier information, a random number, or a counter parameter (see Ying paragraph 0152 i.e. the relay device may alternatively encapsulate the related content of the communication request into the first request message of the relay device, and integrate another related parameter required for verifying the association relationship between the remote device and the relay device into the first request message. For example, optionally, the first request message may further include an identifier of the relay device).
With respect to claim 12 Ying teaches a first network element, comprising a processor and a memory, wherein the memory is configured to store a computer program, and the processor is configured to invoke and run the computer program stored in the memory to cause the first network element to perform:
receiving first information, wherein the first information comprises a device authentication code (DAC) and/or a service authentication code (SAC); and the DAC is used to authenticate an association relationship between a first device and at least one second device (see Ying paragraph 0149-0151 i.e. Step 102: The relay device generates a first request message based on the communication request. The first request message includes the identifier of the remote device. Optionally, the first request message is a non-access stratum (NAS) message between the relay device (relay) and the mobility management entity (MME). In an example, after receiving the communication request from the remote device, the relay device may encapsulate related content of the communication request into the first request message of the relay device);
the SAC is used to authenticate whether the first device and/or the at least one second device support/supports a service type indicated by service identifier information, and/or whether the first device and/or the at least one second device support/supports a data type indicated by data identifier information (see Ying paragraph 0153 i.e. Specifically, the related content encapsulated into the first request message includes the identifier of the remote device in step 101, and may further include the NAS message of the remote device in step 101. Optionally, when the communication request in step 101 further includes the relay service code or the first random number, the related content encapsulated into the first request message further includes the relay service code or the first random number. The relay service code is used to represent a service type to be requested by the remote device, and is used for verifying the association relationship between the remote device and the relay device and paragraph 0204 i.e. When the communication request sent by the remote device to the relay device further includes the relay service code, the first request message generated by the relay device through integration also includes the relay service code, and the relay service code is used to represent a service type to be requested by the remote device).
With respect to claim 13 Ying teaches the first network element according to claim 12, wherein the first information further comprises at least one of the following: service identifier information, wherein the service identifier information is used to indicate a service type supported by the first device and/or the at least one second device; data identifier information, wherein the data identifier information is used to indicate a data type supported by the first device and/or the at least one second device; identifier information of the first device; identifier information of each of the at least one second device; a device key Secret; or a first message authentication code (MAC) corresponding to the first information, wherein the first MAC is used to authenticate whether a sender of the first information is a valid device (see Ying paragraph 0153 i.e. Specifically, the related content encapsulated into the first request message includes the identifier of the remote device in step 101, and may further include the NAS message of the remote device in step 101. Optionally, when the communication request in step 101 further includes the relay service code or the first random number, the related content encapsulated into the first request message further includes the relay service code or the first random number. The relay service code is used to represent a service type to be requested by the remote device, and is used for verifying the association relationship between the remote device and the relay device and paragraph 0204 i.e. When the communication request sent by the remote device to the relay device further includes the relay service code, the first request message generated by the relay device through integration also includes the relay service code, and the relay service code is used to represent a service type to be requested by the remote device).
With respect to claim 20 Ying teaches a first device, comprising a processor and a memory, wherein the memory is configured to store a computer program, and the processor is configured to invoke and run the computer program stored in the memory to cause the first device to perform:
sending first information, wherein the first device is associated with at least one second device; the first information comprises a device authentication code (DAC) and/or a service authentication code (SAC) (see Ying paragraph 0149-0151 i.e. Step 102: The relay device generates a first request message based on the communication request. The first request message includes the identifier of the remote device. Optionally, the first request message is a non-access stratum (NAS) message between the relay device (relay) and the mobility management entity (MME). In an example, after receiving the communication request from the remote device, the relay device may encapsulate related content of the communication request into the first request message of the relay device);
the DAC is used to authenticate an association relationship between the first device and the at least one second device, and the SAC is used to authenticate whether the first device and/or the at least one second device support/supports a service type indicated by service identifier information, and/or whether the first device and/or the at least one second device support/supports a data type indicated by data identifier information (see Ying paragraph 0153 i.e. Specifically, the related content encapsulated into the first request message includes the identifier of the remote device in step 101, and may further include the NAS message of the remote device in step 101. Optionally, when the communication request in step 101 further includes the relay service code or the first random number, the related content encapsulated into the first request message further includes the relay service code or the first random number. The relay service code is used to represent a service type to be requested by the remote device, and is used for verifying the association relationship between the remote device and the relay device and paragraph 0204 i.e. When the communication request sent by the remote device to the relay device further includes the relay service code, the first request message generated by the relay device through integration also includes the relay service code, and the relay service code is used to represent a service type to be requested by the remote device).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 4-11, and 14-19 are rejected under 35 U.S.C. 103 as being unpatentable over Ying et al (US 2019/0335332) in view of Nokia (WO 2020/053481).
With respect to claim 4 Ying teaches the method according to claim 3, but does not disclose before the generating, by the first device, the DAC based on a device key Secret, further comprising: generating, by the first device, the device key Secret based on a service shared key and/or an initial key of each of the at least one second device, wherein the service shared key is shared between the first network element and the first device.
Nokia teaches before the generating, by the first device, the DAC based on a device key Secret, further comprising: generating, by the first device, the device key Secret based on a service shared key and/or an initial key of each of the at least one second device, wherein the service shared key is shared between the first network element and the first device (see Nokia page 15 line 20 – page 17 line 14 i.e. Part 1: Binding NF service consumer's certified public key in the access token generated by the NRF. Part 2: NF service consumer proves that it is in possession of the corresponding private key by digitally signing the API request (e.g., HTTP message) and including the signature in the API request (i.e., NF service request) to the NF service producer).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Ying in view of Nokia to have used a separate asymmetric key pair that the NF service consumer shares the certified public key with the visited NRF, either during Access Token Request or during service discovery so that the visited NRF can validates the certificate before using NF service consumer's public key in the certificate (see Nokia page 16 lines 9-12).
With respect to claim 5 Ying in view of Nokia teaches the method according to claim 3, Nokia further teaches wherein the generating, by the first device, the device key Secret based on a service shared key and/or the identifier information of each of the at least one second device comprises: generating, by the first device, an intermediate key of each second device based on an initial key of the second device; and generating, by the first device, the device key Secret based on the service shared key and/or the intermediate key of each of the at least one second device (see Nokia page 15 lines 30-31 i.e. c) The NF service consumer digitally signs the API request using the private key (PrNFc) associated with the public key added as a claim in the access token and page 18 lines 26-31 i.e. 7. NF service consumer receives the access token (see step 414 in FIG. 4A) in the access token response transmitted to it by hNRF through vNRF. 8. Turning now to FIG. 4B, NF service consumer generates an API request (e.g., HTTP message) for the specific service in NF service producer. NF service consumer includes the access token in the API request and digitally signs the API request using the associated private key (PrNFc) of the public-key shared with the NRF in step 2 above. NF service consumer includes the resulting signature along with the API request and forwards them to the selected NF service producer instance. See step 418 in FIG. 4B).
With respect to claim 6 Ying in view of Nokia teaches the method according to claim 4, Nokia further teaches before the generating, by the first device, the device key Secret based on the identifier information of each of the at least one second device, further comprising: sending, by the first device, key request information to a second network element, wherein the key request information is used to request the initial key of the at least one second device associated with the first device (see Nokia page lines 26-31 and step 424 per figure 4c and step 11 per page 19 - from which it follows that the usage of the public key for verifying the signature signed using the NF service consumer private key, and that the private key used by the NF service consumer to digitally sign the service request comprising the access token was carried out "using the associated private key (PrNFc of the public key shared with the NRF in step 2 [referring to the stepwherein a public key is shared between the NF service consumer and the NRF per rage 18, lines 1-4). The NRF disclosed by Nokia is mapped to the role of the recited "first network element". The subject-matter of dependent claim 7 refers to standard procedure in the dertivation of public-private keys as disclosed by these parts of Nokia).
With respect to claim 7 Ying in view of Nokia teaches the method according to claim 6, Nokia further teaches further comprising: receiving, by the first device, initial key information sent by the second network element, wherein the initial key information comprises the initial key of each second device (see Nokia figure 4A and page 14 line 15 – page 18 line 25).
With respect to claim 8 Ying in view of Nokia teaches the method according to claim 6, Nokia further teaches, wherein the key request information comprises at least one of the following: the identifier information of the first device; the identifier information of each of the at least one second device; the service identifier information; the data identifier information; or a second MAC corresponding to the key request information, wherein the second MAC is used to authenticate whether a sender of the key request information is a valid device device (see Nokia figure 4A and page 14 line 15 – page 18 line 25 i.e. Accordingly, illustrative embodiments bind together the NF consumer's certified public key (with NF instance identifier or ID) and an access token, and combine such binding with a signature-based mechanism used by the NF consumer to prove that it is holding the corresponding private key for further verification by the NF producer).
With respect to claim 9 Ying in view of Nokia teaches the method according to claim 3, Nokia further teaches wherein the generating, by the first device, the SAC based on at least one of identifier information of the first device, identifier information of each second device, service identifier information, data identifier information, a random number, or a counter parameter comprises: signing, by the first device, at least one of the identifier information of the first device, the identifier information of each second device, the service identifier information, the data identifier information, the random number, or the counter parameter by using a private key of the first device, to obtain the SAC (see Nokia page 15 line 20 – page 17 line 14 i.e. Part 1: Binding NF service consumer's certified public key in the access token generated by the NRF. Part 2: NF service consumer proves that it is in possession of the corresponding private key by digitally signing the API request (e.g., HTTP message) and including the signature in the API request (i.e., NF service request) to the NF service producer).
With respect to claim 10 Ying in view of Nokia teaches the method according to claim 3, Nokia further teaches wherein the generating, by the first device, the SAC based on at least one of identifier information of the first device, identifier information of each second device, service identifier information, data identifier information, a random number, or a counter parameter comprises: performing, by the first device, a security operation on at least one of the identifier information of the first device, the identifier information of each second device, the service identifier information, the data identifier information, the random number, or the counter parameter based on a service shared key, to generate the SAC (see Nokia page 15 line 20 – page 17 line 14 i.e. Part 1: Binding NF service consumer's certified public key in the access token generated by the NRF. Part 2: NF service consumer proves that it is in possession of the corresponding private key by digitally signing the API request (e.g., HTTP message) and including the signature in the API request (i.e., NF service request) to the NF service producer).
With respect to claim 11 Ying teaches the method according to claim 1. Ying does not disclose wherein the first information is used to request an authorization certificate of the at least one second device associated with the first device.
Nokia teaches wherein the first information is used to request an authorization certificate of the at least one second device associated with the first device (see Nokia page 15 lines 30-31 i.e. c) The NF service consumer digitally signs the API request using the private key (PrNFc) associated with the public key added as a claim in the access token and page 18 lines 26-31 i.e. 7. NF service consumer receives the access token (see step 414 in FIG. 4A) in the access token response transmitted to it by hNRF through vNRF. 8. Turning now to FIG. 4B, NF service consumer generates an API request (e.g., HTTP message) for the specific service in NF service producer. NF service consumer includes the access token in the API request and digitally signs the API request using the associated private key (PrNFc) of the public-key shared with the NRF in step 2 above. NF service consumer includes the resulting signature along with the API request and forwards them to the selected NF service producer instance. See step 418 in FIG. 4B).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Ying in view of Nokia to have used a separate asymmetric key pair that the NF service consumer shares the certified public key with the visited NRF, either during Access Token Request or during service discovery so that the visited NRF can validates the certificate before using NF service consumer's public key in the certificate as a way to bind the NF service consumer’s public key in the access token (see Nokia page 16 lines 9-12).
With respect to claim 14 Ying teaches the first network element according to claim 12, but does not disclose wherein the first information is used to request issuance of an authorization certificate for the at least one second device associated with the first device; and the processor is configured to invoke and run the computer program stored in the memory to cause the first network element to further perform: in a case that the DAC and/or the SAC are/is successfully authenticated, generating the authorization certificate for the at least one second device.
Nokia teaches wherein the first information is used to request issuance of an authorization certificate for the at least one second device associated with the first device; and the processor is configured to invoke and run the computer program stored in the memory to cause the first network element to further perform: in a case that the DAC and/or the SAC are/is successfully authenticated, generating the authorization certificate for the at least one second device (see Nokia page 15 line 20 – page 17 line 14 i.e. Part 1: Binding NF service consumer's certified public key in the access token generated by the NRF. Part 2: NF service consumer proves that it is in possession of the corresponding private key by digitally signing the API request (e.g., HTTP message) and including the signature in the API request (i.e., NF service request) to the NF service producer).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Ying in view of Nokia to have used a separate asymmetric key pair that the NF service consumer shares the certified public key with the visited NRF, either during Access Token Request or during service discovery so that the visited NRF can validates the certificate before using NF service consumer's public key in the certificate as a way to bind the NF service consumer’s public key in the access token (see Nokia page 16 lines 9-12).
With respect to claim 15 Ying in view of Nokia teaches the first network element according to claim 14, Nokia further teaches wherein the processor is configured to invoke and run the computer program stored in the memory to cause the first network element to further perform: generating first verification information based on a device key Secret (see Nokia page 15 line 20 – page 17 line 14 i.e. Part 1: Binding NF service consumer's certified public key in the access token generated by the NRF. Part 2: NF service consumer proves that it is in possession of the corresponding private key by digitally signing the API request (e.g., HTTP message) and including the signature in the API request (i.e., NF service request) to the NF service producer); and if the first verification information is consistent with the DAC, determining that the DAC is successfully authenticated (see Nokia page 17 lines 14-25 i.e. Part 3: NF service producer verifies the digital signature using the public key in the validated access token In this part, the NF service producer takes the public key from the validated access token and verifies NF service consumer's signature. If the verification succeeds, the NF service producer has successfully authenticated the NF service consumer. Note that while validation of the access token is not within the scope of the illustrative descriptions herein, it is to be appreciated that in illustrative embodiments the access token is validated first before the public key is taken from the access token. Note also that validation of the access token is performed directly by the NF service producer or indirectly by invoking a token validation service on the NRF. If the token is ciphered, then the NF service producer first decrypts the access token before executing the validation procedure on the access token).
With respect to claim 16 Ying in view of Nokia teaches the first network element according to claim 15, Ying further teaches wherein before the generating first verification information based on a device key Secret, the processor is configured to invoke and run the computer program stored in the memory to cause the first network element to further perform: generating the device key Secret based on a service shared key and/or an initial key of each of the at least one second device, wherein the service shared key is shared between the first network element and the first device (see Ying paragraph 0152 i.e. the relay device may alternatively encapsulate the related content of the communication request into the first request message of the relay device, and integrate another related parameter required for verifying the association relationship between the remote device and the relay device into the first request message. For example, optionally, the first request message may further include an identifier of the relay device).
With respect to claim 17 Ying in view of Nokia teaches the first network element according to claim 14, Ying further wherein the SAC is obtained by signing at least one of identifier information of the first device, identifier information of each second device, service identifier information, data identifier information, a random number, or a counter parameter based on a private key of the first device; and the processor is configured to invoke and run the computer program stored in the memory to cause the first network element to further perform: authenticating the SAC by using a public key of the first device, to obtain second verification information; and if the second verification information is consistent with the identifier information of the first device, the identifier information of each second device, the service identifier information, the data identifier information, the random number, and the counter parameter that are carried in the first information, determining that the SAC is successfully authenticated (see Ying paragraph 0152 i.e. the relay device may alternatively encapsulate the related content of the communication request into the first request message of the relay device, and integrate another related parameter required for verifying the association relationship between the remote device and the relay device into the first request message. For example, optionally, the first request message may further include an identifier of the relay device).
With respect to claim 18 Ying in view of Nokia teaches the first network element according to claim 14, Ying further wherein the SAC is obtained by performing a security operation on at least one of identifier information of the first device, identifier information of each of the at least one second device, service identifier information, data identifier information, a random number, or a counter parameter based on a service shared key; and the processor is configured to invoke and run the computer program stored in the memory to cause the first network element to further perform: performing a security operation on at least one of the identifier information of the first device, the identifier information of each second device, the service identifier information, the data identifier information, the random number, or the counter parameter based on the service shared key, to obtain third verification information; and if the third verification information is consistent with the SAC, determining that the SAC is successfully authenticated (see Ying paragraph 0152 i.e. the relay device may alternatively encapsulate the related content of the communication request into the first request message of the relay device, and integrate another related parameter required for verifying the association relationship between the remote device and the relay device into the first request message. For example, optionally, the first request message may further include an identifier of the relay device).
With respect to claim 19 Ying in view of Nokia teaches the first network element according to claim 14, Ying further teaches wherein the authorization certificate comprises at least one of the following: identifier information of the first device; a public key of the first device; identifier information of each of the at least one second device; an RSA accumulator parameter of each of the at least one second device; identifier information of the first network element; a public key of the first network element; service identifier information; data identifier information; the device authentication code DAC; or a digital signature of the first network element, wherein the digital signature is obtained by signing other information in the authorization certificate based on a private key of the first network element (see Ying paragraph 0152 i.e. the relay device may alternatively encapsulate the related content of the communication request into the first request message of the relay device, and integrate another related parameter required for verifying the association relationship between the remote device and the relay device into the first request message. For example, optionally, the first request message may further include an identifier of the relay device).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEVIN E ALMEIDA whose telephone number is (571)270-1018. The examiner can normally be reached on Monday-Thursday from 7:30 A.M. to 5:00 P.M. The examiner can also be reached on alternate Fridays from 7:30 A.M. to 4:00 P.M.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Rupal Dharia, can be reached on 571-272-3880. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/DEVIN E ALMEIDA/Examiner, Art Unit 2492