DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1-20 are pending.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 8, 16 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Perlmutter et al (PGPUB 2019/0124059).
Regarding Claims 1, 8, and 16:
Perlmutter teaches a computing apparatus, a method, and a non-transitory computer-readable storage medium comprising processor-executable instructions, wherein the processor-executable instructions, in part, operate a first network function (NF) within a first network such to cause one or more processors to perform a method, the computing apparatus comprising ([0091] exemplary system 600 configured to implement the gateway 130 of the present invention):
a non-transitory computer-readable storage medium ([0091] computer readable medium storing software);
processor-executable instructions stored on the non-transitory computer-readable storage medium ([0091] computer readable medium storing software); and
one or more processors coupled to the non-transitory computer-readable storage medium and configured to execute the processor-executable instructions to operate a first network function (NF) within a first network ([0091] system (processing system) 600 includes a processor 602; [0056] the cloud gateway 130 may be one or more devices including one or more processors in one or more locations, implemented physically or virtually, as is known in the current state of the art; the cloud gateway 130 implements gateway functionality), wherein the first NF function comprises an access token engine ([0072] gateway 130 generates a second token), such that the processor-executable instructions, when executed by the one or more processors, direct the computing apparatus, to at least:
receive a service request from a visitor consumer NF ([0064] refer now to FIG. 2, a simplified flowchart of a method for identification; in particular, a method for identifying a user, and identifying each of multiple users, behind a shared VPN tunnel; in step 200, the current embodiment begins with receiving a first request from a user 102, the user being on a first side of the VPN 108; [0053] on the internal network 100 a router 110 is deployed; one or more clients are deployed on the internal network 100 and connected via the router 110 and VPN 108 to the cloud gateway 130; exemplary client 104 has a user 102 running an application 106), wherein the visitor consumer NF is in a second network that is different from the first network ([0064] the second side of the VPN is normally a side of the VPN other than the first side of the VPN; the first side is typically the internal network 100, and the second side is typically the Internet 120);
determine that the service request lacks an access token for receiving services from the first network ([0066] in step 202, the first request is processed and evaluated by the gateway 130, to determine if the first request includes a second token authenticating the user to the resource);
determine an access token for the visitor consumer NF based on the service request ([0071] In step 204, the first request does not include a second token authenticating the user to the resource; the first request is then processed and evaluated by the gateway 130, to determine if the first request includes a userid; in a case where the first request is a URL, the URL, can be checked to see if the URL includes a userid; if the first request includes the userid, then the user has previously been authenticated (see below steps 206 to 216) and from step 204 the method continues at step 230, else the method continues at step 206; [0072] in step 230, the user 102 has been authenticated, but the user has not yet been authenticated to the resource in the first request (that is, not authenticated to the domain of the reference to the resource 128); a second token (domain ID cookie) authenticating the user to the resource is generated);
generate an updated service request comprising the service request and the access token ([0073] in step 232, a second request is generated; the second request is based on the first request, includes the reference to the resource 128, and includes the second token); and
transmit the updated service request to a producer NF within the first network for servicing the service request on behalf of the visitor consumer NF, wherein the producer NF furnishes the service request for the visitor consumer NF based on the access token ([0057] the resources 128 can be a variety of nodes providing a variety of services and information, providing (serving) one or more websites, hosting one or more virtual servers, and in general providing resource(s) to client(s) 104; in particular, for simplicity in this description the resource is a web server providing one or more websites and web pages; references to the (plural) resources 128 may also be in the singular “resource” as appropriate for clarity and simplicity; [0074] in step 234, the second request is issued; issuing a request typically is re-directing the request, for example re-directing the user's web browser; for example, in the case of the current resource being a website (the resource 128), issuing the second request can be implemented by redirecting the user's browser from the gateway 130 to the originally requested resource (the website 128); [0075] in this case, the re-direction is to the same resource, but with a different request, specifically with the request now including the second token; in other words, the second request is issued and then is handled like the first request, repeating the steps of the current figure; [0070] if the first request includes the second token, then the user is allowed access to the resource 128).
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) 2, 7, 9, 17, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Perlmutter, and further in view of Wang et al (PGPUB 2026/0039650).
Regarding Claim 2:
Perlmutter teaches the computing apparatus of claim 1.
Perlmutter does not explicitly teach wherein the processor-executable instructions to determine the access token for the visitor consumer NF based on the service request, when executed by the one or more processors, further direct the computing apparatus to:
generate an access token request based on the service request, wherein the access token request comprises one or more attributes associated with the visitor consumer NF and the service request; and
transmit the access token request to a second NF within the first network, wherein the second NF generates the access token responsive to receiving the access token request.
However, Wang teaches the concept of directing a computing apparatus to generate an access token request based on a service request, wherein the access token request comprises one or more attributes associated with a visitor consumer NF and the service request ([0066]-[0067] the NFc 110 may transmit to the SCPc 130 a request for a service from the NFp 120; for example, the request may comprise scope information associate with the NFp 120; the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120); and
transmit the access token request to a second NF within a first network, wherein the second NF generates an access token responsive to receiving the access token request ([0067] the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120; the NRF 150 generates the token based on the request and the registration information from the NFp 120; then, the NRF 150 transmits (215) the token to the SCPc 130).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the network repository function (NRF) teachings of Wang with the authentication of a service request teachings of Perlmutter, with the benefit of using an established, central token repository to distribute tokens to supplicant parties, thereby improving efficiency by eliminating redundant systems and improving security by allowing administrators to focus on a single point of failure for hardening against exploits and attacks.
Regarding Claim 7:
Perlmutter teaches the computing apparatus of claim 1. In addition, Perlmutter teaches wherein the processor-executable instructions to determine the access token for the visitor consumer NF based on the service request, when executed by the one or more processors, further direct the computing apparatus to:
determine one or more access token attributes based on the service request ([0071] the first request is then processed and evaluated by the gateway 130, to determine if the first request includes a userid; processing may include decrypting the first request and parsing the resulting data to determine a userid; in a case where the first request is a URL, the URL, can be checked to see if the URL includes a userid; if the first request includes the userid, then the user has previously been authenticated).
Perlmutter does not explicitly teach generating an access token request comprising the one or more access token attributes; and
retrieving the access token from a second NF within the first network using the access token request, wherein the second NF generates the access token responsive to receiving the access token request.
However, Wang teaches the concept of generating an access token request comprising the one or more access token attributes ([0066]-[0067] the NFc 110 may transmit to the SCPc 130 a request for a service from the NFp 120; for example, the request may comprise scope information associate with the NFp 120; the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120); and
retrieving the access token from a second NF within a first network using the access token request, wherein the second NF generates an access token responsive to receiving the access token request ([0067] the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120; the NRF 150 generates the token based on the request and the registration information from the NFp 120; then, the NRF 150 transmits (215) the token to the SCPc 130).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the network repository function (NRF) teachings of Wang with the authentication of a service request teachings of Perlmutter, with the benefit of using an established, central token repository to distribute tokens to supplicant parties, thereby improving efficiency by eliminating redundant systems and improving security by allowing administrators to focus on a single point of failure for hardening against exploits and attacks.
Regarding Claim 9:
Perlmutter teaches the method of claim 8.
Perlmutter does not explicitly teach wherein determining, by the access token engine, the access token for the service request comprises:
generating, by the access token engine, an access token request based on the service request;
transmitting, by the access token engine, the access token request to a second NF within the first network, wherein the second NF generates the access token responsive to receiving the access token request; and
receiving, by the access token engine, the access token from the second NF.
However, Wang teaches the concept wherein determining, by an access token engine, an access token for a service request comprises:
generating, by the access token engine, an access token request based on the service request ([0066]-[0067] the NFc 110 may transmit to the SCPc 130 a request for a service from the NFp 120; for example, the request may comprise scope information associate with the NFp 120; the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120);
transmitting, by the access token engine, the access token request to a second NF within a first network, wherein the second NF generates the access token responsive to receiving the access token request ([0067] the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120; the NRF 150 generates the token based on the request and the registration information from the NFp 120; then, the NRF 150 transmits (215) the token to the SCPc 130); and
receiving, by the access token engine, the access token from the second NF ([0067] the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120; the NRF 150 generates the token based on the request and the registration information from the NFp 120; then, the NRF 150 transmits (215) the token to the SCPc 130).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the network repository function (NRF) teachings of Wang with the authentication of a service request teachings of Perlmutter, with the benefit of using an established, central token repository to distribute tokens to supplicant parties, thereby improving efficiency by eliminating redundant systems and improving security by allowing administrators to focus on a single point of failure for hardening against exploits and attacks.
Regarding Claim 17:
Perlmutter teaches the non-transitory computer-readable storage medium of claim 16.
Perlmutter does not explicitly teach wherein the processor-executable instructions to determine, by the access token engine, the access token for the visitor consumer NF cause the one or more processors to further execute processor-executable instructions stored in the non-transitory computer-readable storage medium to:
generate, by the access token engine, an access token request based on the service request, wherein the access token request comprises one or more of:
nfinstanceID;
nftype;
targetnftype;
scope of service; or
requestorPLMN; and
retrieve, by the access token engine, the access token from a second NF within the first network using the access token request, wherein the second NF generates the access token responsive to receiving the access token request.
However, Wang teaches the concept of generating, by an access token engine, an access token request based on a service request ([0066]-[0067] the NFc 110 may transmit to the SCPc 130 a request for a service from the NFp 120; for example, the request may comprise scope information associate with the NFp 120; the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120), wherein the access token request comprises one or more of:
nfinstanceID;
nftype;
targetnftype ([0092] the SCPc 130 transmits to the NRF 150 a request for the access token; in some example embodiments, if the SCPc 130 uses “targetNfType” in the request for the access token, the audience in the access token claims may be set accordingly and with multiple matching NF producer instances, “token ValidationDelegationAllowed” and/or “token ValidationDelegationSCPDomainList” may be configured differently);
scope of service; or
requestorPLMN; and
retrieve, by the access token engine, the access token from a second NF within the first network using the access token request, wherein the second NF generates the access token responsive to receiving the access token request ([0067] the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120; the NRF 150 generates the token based on the request and the registration information from the NFp 120; then, the NRF 150 transmits (215) the token to the SCPc 130).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the network repository function (NRF) teachings of Wang with the authentication of a service request teachings of Perlmutter, with the benefit of using an established, central token repository to distribute tokens to supplicant parties, thereby improving efficiency by eliminating redundant systems and improving security by allowing administrators to focus on a single point of failure for hardening against exploits and attacks.
Regarding Claim 20:
Perlmutter teaches the non-transitory computer-readable storage medium of claim 16.
Perlmutter does not explicitly teach wherein the processor-executable instructions to determine, by the access token engine, the access token for the visitor consumer NF cause the one or more processors to further execute processor-executable instructions stored in the non-transitory computer-readable storage medium to:
retrieve, by the access token engine, the access token from a second NF within the first network using an access token request, wherein the second NF:
comprises a network function repository function (NRF) within the first network; and
generates the access token responsive to receiving the access token request.
However, Wang teaches the concept of retrieving, by an access token engine, an access token from a second NF within a first network using an access token request, wherein the second NF ([0066]-[0067] the NFc 110 may transmit to the SCPc 130 a request for a service from the NFp 120; for example, the request may comprise scope information associate with the NFp 120; the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120):
comprises a network function repository function (NRF) within the first network ([0066]-[0067] NRF); and
generates the access token responsive to receiving the access token request ([0067] the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120; the NRF 150 generates the token based on the request and the registration information from the NFp 120; then, the NRF 150 transmits (215) the token to the SCPc 130).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the network repository function (NRF) teachings of Wang with the authentication of a service request teachings of Perlmutter, with the benefit of using an established, central token repository to distribute tokens to supplicant parties, thereby improving efficiency by eliminating redundant systems and improving security by allowing administrators to focus on a single point of failure for hardening against exploits and attacks.
Claim(s) 3, 5-6, 11, 13-15, 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Perlmutter, and further in view of S Bykampadi et al (PGPUB 2021/0297942), hereinafter Bykampadi.
Regarding Claim 3:
Perlmutter teaches the computing apparatus of claim 1. In addition, Perlmutter teaches wherein the processor-executable instructions to determine the access token for the visitor consumer NF based on the service request, when executed by the one or more processors, further direct the computing apparatus to:
determine a unique identifier for the visitor consumer NF based on the service request ([0071] the first request is then processed and evaluated by the gateway 130, to determine if the first request includes a userid; processing may include decrypting the first request and parsing the resulting data to determine a userid; in a case where the first request is a URL, the URL, can be checked to see if the URL includes a userid; if the first request includes the userid, then the user has previously been authenticated).
Perlmutter does not explicitly teach performing a look-up on a visitor access token table based on the unique identifier; and
determining the access token for the visitor consumer NF within the visitor access token table, wherein the access token was previously generated by a second NF function within the first network for the visitor consumer NF.
However, Bykampadi teaches the concept of performing a look-up on a visitor access token table based on a unique identifier ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed); and
determining an access token for the visitor consumer NF within a visitor access token table, wherein the access token was previously generated by a second NF function within a first network for the visitor consumer NF ([0059]-[0060] if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token caching teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve system efficiency and security by reusing valid tokens for a limited amount of time, thereby providing a balance between the number of required token issuance requests and the duration of a token, limiting an attacker’s ability to intercept and replay a stolen token.
Regarding Claim 5:
Perlmutter teaches the computing apparatus of claim 1. In addition, Perlmutter teaches wherein the processor-executable instructions, when executed by the one or more processors, further direct the computing apparatus to:
determine a unique identifier for the visitor consumer NF based on the service request ([0071] the first request is then processed and evaluated by the gateway 130, to determine if the first request includes a userid; processing may include decrypting the first request and parsing the resulting data to determine a userid; in a case where the first request is a URL, the URL, can be checked to see if the URL includes a userid; if the first request includes the userid, then the user has previously been authenticated).
Perlmutter does not explicitly teach determining an expiry time associated with the access token; and
updating a visitor access token table with the access token, the expiry time, and the unique identifier, wherein the access token is associated with the unique identifier of the visitor consumer NF and the expiry time within the visitor access token table.
However, Bykampadi teaches the concept of determining an expiry time associated with the access token ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed; [0092] the claims in the token include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service consumer (subject), NF type of the NF Service producer (audience), expected service name(s) (scope) and expiration time (expiration)); and
updating a visitor access token table with the access token, the expiry time, and the unique identifier, wherein the access token is associated with the unique identifier of the visitor consumer NF and the expiry time within the visitor access token table ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed; [0092] the claims in the token include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service consumer (subject), NF type of the NF Service producer (audience), expected service name(s) (scope) and expiration time (expiration)).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token caching teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve system efficiency and security by reusing valid tokens for a limited amount of time, thereby providing a balance between the number of required token issuance requests and the duration of a token, limiting an attacker’s ability to intercept and replay a stolen token.
Regarding Claim 6:
Perlmutter teaches the computing apparatus of claim 1.
Perlmutter does not explicitly teach wherein the first NF comprises a Security Edge Protection Proxy (SEPP) within the first network.
However, Bykampadi teaches the concept wherein a first NF comprises a Security Edge Protection Proxy (SEPP) within a first network ([0096] SCP to SCP connection may be based on TLS or, in alternative embodiments, could also be Network Domain Security/Internet Protocol or NDS/IP (IPSec) or also implicit if going through a SEPP (for inter-roaming scenarios); SCPc and SCPp trust each other based on a mutually authenticated secure connection between them either directly or indirectly via SEPP).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the SEPP teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve the security environment by incorporating a specialized security device which implements proven security transport techniques such as Transport Layer Security (TLS) and application layer security (ALS).
Regarding Claim 11:
Perlmutter teaches the method of claim 8.
Perlmutter does not explicitly teach wherein determining, by the access token engine, the access token for the visitor consumer NF based on the service request comprises:
performing, by the access token engine, a look-up on a visitor access token table based on the service request; and
identifying, by the access token engine, the access token for the visitor consumer NF within the visitor access token table, wherein the access token was previously generated by a second NF function within the first network for the visitor consumer NF.
However, Bykampadi teaches the concept of performing, by an access token engine, a look-up on a visitor access token table based on a service request ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed); and
identifying, by the access token engine, an access token for a visitor consumer NF within the visitor access token table, wherein the access token was previously generated by a second NF function within a first network for the visitor consumer NF ([0059]-[0060] if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token caching teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve system efficiency and security by reusing valid tokens for a limited amount of time, thereby providing a balance between the number of required token issuance requests and the duration of a token, limiting an attacker’s ability to intercept and replay a stolen token.
Regarding Claim 13:
Perlmutter teaches the method of claim 8.
Perlmutter does not explicitly teach wherein the method further comprises:
determining, by the access token engine, a unique identifier for the visitor consumer NF based on the service request; and
updating, by the access token engine, a visitor access token table with the access token and the unique identifier, wherein the access token is associated with the unique identifier of the visitor consumer NF.
However, Bykampadi teaches the concept of determining, by an access token engine, a unique identifier for a visitor consumer NF based on a service request ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed; [0092] the claims in the token include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service consumer (subject), NF type of the NF Service producer (audience), expected service name(s) (scope) and expiration time (expiration)); and
updating, by the access token engine, a visitor access token table with an access token and the unique identifier, wherein the access token is associated with the unique identifier of the visitor consumer NF ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token caching teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve system efficiency and security by reusing valid tokens for a limited amount of time, thereby providing a balance between the number of required token issuance requests and the duration of a token, limiting an attacker’s ability to intercept and replay a stolen token.
Regarding Claim 14:
Perlmutter teaches the method of claim 8.
Perlmutter does not explicitly teach wherein the access token comprises an open authorization token.
However, Bykampadi teaches the concept wherein an access token comprises an open authorization token ([0058] methodology is provided to implement OAuth-based service access authorization).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the OAuth teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve the security environment by incorporating authentication methods which are well-known standards in the art, such as OAuth, which has a proven record of safe and secure authentication functionality.
Regarding Claim 15:
Perlmutter teaches the method of claim 8.
Perlmutter does not explicitly teach wherein the first NF comprises a Security Edge Protection Proxy (SEPP) within the first network.
However, Bykampadi teaches the concept wherein a first NF comprises a Security Edge Protection Proxy (SEPP) within a first network ([0096] SCP to SCP connection may be based on TLS or, in alternative embodiments, could also be Network Domain Security/Internet Protocol or NDS/IP (IPSec) or also implicit if going through a SEPP (for inter-roaming scenarios); SCPc and SCPp trust each other based on a mutually authenticated secure connection between them either directly or indirectly via SEPP).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the SEPP teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve the security environment by incorporating a specialized security device which implements proven security transport techniques such as Transport Layer Security (TLS) and application layer security (ALS).
Regarding Claim 18:
Perlmutter teaches the non-transitory computer-readable storage medium of claim 16.
Perlmutter does not explicitly teach wherein the processor-executable instructions to determine, by the access token engine, the access token for the visitor consumer NF cause the one or more processors to further execute processor-executable instructions stored in the non-transitory computer-readable storage medium to:
perform, by the access token engine, a look-up on a visitor access token table based on the service request;
identify, by the access token engine, the access token for the visitor consumer NF within the visitor access token table, wherein the access token was previously generated by a second NF function within the first network for the visitor consumer NF; and
determine, by the access token engine, that the access token is valid based on a respective expiry time of the access token.
However, Bykampadi teaches the concept of performing, by an access token engine, a look-up on a visitor access token table based on a service request ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed);
identifying, by the access token engine, an access token for a visitor consumer NF within the visitor access token table, wherein the access token was previously generated by a second NF function within a first network for the visitor consumer NF ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed); and
determining, by the access token engine, that the access token is valid based on a respective expiry time of the access token ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token caching teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve system efficiency and security by reusing valid tokens for a limited amount of time, thereby providing a balance between the number of required token issuance requests and the duration of a token, limiting an attacker’s ability to intercept and replay a stolen token.
Regarding Claim 19:
Perlmutter teaches the non-transitory computer-readable storage medium of claim 16.
Perlmutter does not explicitly teach wherein the processor-executable instructions cause the one or more processors to further execute processor-executable instructions stored in the non-transitory computer-readable storage medium to:
determine, by the access token engine, an expiry time for the access token;
associate, by the access token engine, the access token with a unique identifier for the visitor consumer NF; and
store, by the access token engine, the access token, the expiry time, and the unique identifier in a visitor access token table.
However, Bykampadi teaches the concept of determining, by an access token engine, an expiry time for an access token ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed; [0092] the claims in the token include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service consumer (subject), NF type of the NF Service producer (audience), expected service name(s) (scope) and expiration time (expiration));
associate, by the access token engine, the access token with a unique identifier for the visitor consumer NF ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed; [0092] the claims in the token include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service consumer (subject), NF type of the NF Service producer (audience), expected service name(s) (scope) and expiration time (expiration)); and
store, by the access token engine, the access token, the expiry time, and the unique identifier in a visitor access token table ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed; [0092] the claims in the token include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service consumer (subject), NF type of the NF Service producer (audience), expected service name(s) (scope) and expiration time (expiration)).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token caching teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve system efficiency and security by reusing valid tokens for a limited amount of time, thereby providing a balance between the number of required token issuance requests and the duration of a token, limiting an attacker’s ability to intercept and replay a stolen token.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Perlmutter, and further in view of Lee et al (PGPUB 2023/0020855).
Regarding Claim 4:
Perlmutter teaches the computing apparatus of claim 1.
Perlmutter does not explicitly teach wherein the processor-executable instructions to determine that the service request lacks the access token for receiving services from the first network, when executed by the one or more processors, further direct the computing apparatus to:
identify a current access token for the visitor consumer NF within a visitor access token table; and
determine that an expiry time associated with the current access token is exceeded.
However, Lee teaches the concept of identifying a current access token for a visitor consumer NF within a visitor access token table ([0021] an access device may be configured to maintain access data including the network access tokens within a container stored in local memory (e.g., in a mapping between an accessory device identifier and a network access token, in a list of network access tokens with which access is to be granted, in an object for each accessory device and related data, or the like)); and
determining that an expiry time associated with a current access token is exceeded ([0029] the access device may be configured to detect when the time limit of a network access token has been reached (referred to as “expiration time”); upon determining that the time limit has been reached, the access device can revoke network access for the accessory device corresponding to the expired network access token).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token expiration teachings of Lee with the authentication of a service request teachings of Perlmutter; it is well-known in the art to time-limit authentication and encryption credentials, such as keys and tokens, in order to improve the security environment by limiting the amount of time an eavesdropper has to attempt reuse of security materials.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Perlmutter, and further in view of Lee and Wang.
Regarding Claim 10:
Perlmutter teaches the method of claim 8.
Perlmutter does not explicitly teach wherein:
determining, by the access token engine, that the service request lacks the access token for receiving services from the first network comprises:
identifying, by the access token engine, a current access token for the visitor consumer NF within a visitor access token table; and
determining, by the access token engine, that the current access token is invalid based on an expiry time associated with the current access token.
However, Lee teaches the concept of identifying, by an access token engine, a current access token for a visitor consumer NF within a visitor access token table ([0021] an access device may be configured to maintain access data including the network access tokens within a container stored in local memory (e.g., in a mapping between an accessory device identifier and a network access token, in a list of network access tokens with which access is to be granted, in an object for each accessory device and related data, or the like)); and
determining, by the access token engine, that the current access token is invalid based on an expiry time associated with the current access token ([0029] the access device may be configured to detect when the time limit of a network access token has been reached (referred to as “expiration time”); upon determining that the time limit has been reached, the access device can revoke network access for the accessory device corresponding to the expired network access token).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token expiration teachings of Lee with the authentication of a service request teachings of Perlmutter; it is well-known in the art to time-limit authentication and encryption credentials, such as keys and tokens, in order to improve the security environment by limiting the amount of time an eavesdropper has to attempt reuse of security materials.
Neither Perlmutter nor Lee explicitly teaches determining, by the access token engine, the access token for the visitor consumer NF based on the service request comprises:
retrieving, by the access token engine, the access token for the visitor consumer NF from a second NF within the first network.
However, Wang teaches the concept wherein determining, by an access token engine, an access token for a visitor consumer NF based on a service request comprises:
retrieving, by the access token engine, the access token for the visitor consumer NF from a second NF within the first network ([0067] the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120; the NRF 150 generates the token based on the request and the registration information from the NFp 120; then, the NRF 150 transmits (215) the token to the SCPc 130).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the network repository function (NRF) teachings of Wang with the authentication of a service request teachings of Perlmutter in view of Lee, with the benefit of using an established, central token repository to distribute tokens to supplicant parties, thereby improving efficiency by eliminating redundant systems and improving security by allowing administrators to focus on a single point of failure for hardening against exploits and attacks.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Perlmutter, and further in view of Bykampadi and Baskaran et al (PGPUB 2026/0039641).
Regarding Claim 12:
Perlmutter teaches the method of claim 8.
Perlmutter does not explicitly teach wherein determining, by the access token engine, the access token for the visitor consumer NF based on the service request comprises:
identifying, by the access token engine, a current access token for the visitor consumer NF within a visitor access token table;
generating, by the access token engine, a first updated service request comprising the current access token and the service request;
retrieving, by the access token engine, the access token from a second NF within the first network based on the service request.
However, Bykampadi teaches the concept of identifying, by an access token engine, a current access token for a visitor consumer NF within a visitor access token table ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed);
generating, by the access token engine, a first updated service request comprising the current access token and the service request (abstract, first service communication proxy element determines at least one target service producer based on the service request; the first service communication proxy element sends an access token request to an authorization entity, wherein the access token request is generated based on the determining step; the first service communication proxy element receives an access token response from the authorization entity, wherein the access token response comprises an access token; the first service communication proxy element may then send a service request with the access token to a second service communication proxy element, wherein the second service communication proxy element is associated with the target service producer);
retrieving, by the access token engine, the access token from a second NF within the first network based on the service request ([0059] the SCP connected to the NFc (referred to herein as SCPc) obtains all the required information related to the target NF producer (NFp) from the NRF; once it selects the target NFp, it issues another request to the NRF to obtain an access token specific to the NFc and the selected target NFp).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token caching teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve system efficiency and security by reusing valid tokens for a limited amount of time, thereby providing a balance between the number of required token issuance requests and the duration of a token, limiting an attacker’s ability to intercept and replay a stolen token.
Neither Perlmutter nor Bykampadi explicitly teaches receiving, by the access token engine, an error response from the producer NF responsive to transmitting the first updated service request to the producer NF.
However, Baskaran teaches the concept of receiving, by an access token engine, an error response from a producer NF responsive to transmitting a first updated service request to the producer NF ([0059] the NF service producer checks that the token has not expired by verifying the expiration time in the token against the current data and/or time; if a client credentials assertion (CCA) is present in the service request, then the NF service producer may verify that the CCA as defined and that the subject claim (e.g., the NF instance ID of the NF service consumer) in the token matches the subject claim in the CCA; if the verification is successful, then the NF service producer executes the requested service and responds back to the NF service consumer; otherwise, the NF service producer replies with an error response (e.g., an Oauth 2.0 error response)).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the error notification teachings of Baskaran with the authentication of a service request teachings of Perlmutter in view of Bykampadi; it is well-known in the art to provide error notifications in the event of failure, in order to improve system efficiency and security by informing a client/user/admin that there is an issue with a validation process that must be fixed before making use of a service.
Response to Arguments
Applicant's arguments filed 6/9/2026 have been fully considered but they are not persuasive.
Regarding the rejection of claims under 35 USC 101:
Applicant’s amendments have overcome the previous 35 USC 101 rejections, which are therefore withdrawn.
Regarding the rejection of claims under 35 USC 102/103:
Examiner’s response to applicant’s arguments, page 11 paragraph 4-5: Applicant appears to be asserting, without evidence, a special definition of “visitor consumer network function”, “first network function”, and “producer network function”. Applicant cites no special limiting definition in the specification and claims as originally filed, nor presents any reference which shows that these terms are exclusive to the art. Therefore, it is the examiner’s opinion that the BRI of the argued terminology includes functions on a network, such as a user application of a client device, or a “visitor consumer”, connecting to a first gateway, functioning on a network, and providing access to a web server, functioning to produce a website for the client device, on the network. Applicant argues that examiner’s interpretation would provide little meaningful distinction over ordinary client/server architectures, but this is exactly examiner’s point: the claimed terms are so generic as to apply to nearly any conceivable application functioning over a network.
Examiner’s response to applicant’s arguments, page 11 paragraph 6-page 12 paragraph 3: Applicant argues that examiner’s interpretation is too abstract, and merely equates generic network client/server components to specific terminology. However, it is not the terminology of “Network Function” which matters here; it is the functions performed by the elements in the claim. Applicant argues that the generic terminology of Perlmutter is not equivalent to the claimed network functions, but does not point out which functions the NF elements perform which the client, gateway, and website/server of Perlmutter do not. The gateway (first network function) of Perlmutter receives a service request from a client device (visitor consumer network function) (e.g. [0053], [0064]), which is in a second network, different from the gateway’s network (e.g. [0064]). The gateway determines that the request lacks an access token for receiving services from the first network (e.g. [0066]). The gateway determines an access token for the client based on the request (e.g. [0071]-[0072]). The gateway generates an updated service request including the token (e.g. [0073]), and transmits the updated request to the web server hosting the website (producer network function) (e.g. [0057], [0074]-[0075]), giving the client access to the website (furnishes the request). It is clear that the three “generic” network functions of Perlmutter are performing each and every function also performed by the claimed NFs.
Applicant goes on to argue that they are not asserting that the claims are limited to any formal definition of a network function, but that the claims must still be interpreted in a manner which gives effect to the recited limitations. This is exactly what examiner has done. The terms have been considered in terms of the functions they execute. Perlmutter teaches a network system which performs each and every one of these functions. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “communications between network functions through service-based interfaces within the disclosed network architecture”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
While the specification describes certain network functions, the specification fails to provide a specific, limiting definition of “network function” which excludes the client, gateway, and web server of Perlmutter. Therefore, these elements fall within the BRI of the claimed terms.
Examiner’s response to applicant’s arguments, page 12 paragraph 5-page 13 paragraph 3: Applicant argues that a “website responding to a request for access to the website’s resources” is not furnishing a requested service for a client (i.e. “visitor consumer NF”) based on an access token. Examiner disagrees. “Furnishing a service request” covers an immeasurable breadth of activities; certainly, a web server providing a website or web page is among them. Perlmutter is clearer about the provided service in [0057], which has been added to the above rejection for clarity:
“the resources 128 can be a variety of nodes providing a variety of services and information, providing (serving) one or more websites, hosting one or more virtual servers, and in general providing resource(s) to client(s) 104; in particular, for simplicity in this description the resource is a web server providing one or more websites and web pages”
Perlmutter is also clear that the request includes the second token authenticating the user to the resource (e.g. [0075]), and that the second token is required to access the resource (e.g. [0070]). Therefore, furnishing the service request is “based on” the access token.
Therefore, Perlmutter teaches the argued limitations of the claim.
Examiner’s response to applicant’s arguments, page 13 paragraph 2: Examiner disagrees. Once again, applicant is ignoring the BRI of the recited terms. The second token “authenticating the user to the resource” in Perlmutter clearly is used to allow access to the resource (e.g. [0070]). It is therefore an access token for all intents and purposes. Examiner notes that access tokens frequently provide access to secure resources through the use of authentication; applicant’s claim contains no element which would exclude this function. Further, applicant recites passages from Perlmutter which clearly show that the request is processed to determine if a userid is present, which is the impetus for generating the second “access” token. It is therefore clear that Perlmutter generates the second access token “based on” the service request.
Applicant makes no further arguments.
Applicant’s arguments with regard to independent claims 8 and 16 are similar to those regarding claim 1 and are therefore responded to in a similar way.
Applicant further argues that the dependent claims are allowable due to depending on an allowable independent claim. However, as shown above, the independent claims are not allowable.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FORREST L CAREY whose telephone number is (571)270-7814. The examiner can normally be reached 9:00AM-5:30PM M-F.
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, William Korzuch can be reached at (571) 272-7589. 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.
/FORREST L CAREY/Examiner, Art Unit 2491
/WILLIAM R KORZUCH/Supervisory Patent Examiner, Art Unit 2491
Prosecution Insights