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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office Action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on 05/02/2026 has been entered.
Response to Amendments
This communication is in response to the amendments filed on 2 May 2026:
Claims 1 and 3-5 are amended.
Claims 1-20 are pending.
Response to Arguments
In response to Applicant’s remarks filed on 2 May 2026:
a. Applicant’s arguments that Kobayashi and Engan et al. cannot be combined together because Engan et al. teaches away from obtaining from a server a redirected request for service as it teaches that the server communicates directly with the client has been fully considered but is deemed not-persuasive. Applicant’s attention is directed to the fact that Kobayashi was used to teach the limitation being argued by the Applicant above. Engan was merely introduced to teach the missing limitation not taught by Kobayashi, which recites “obtaining a second token, wherein the second token has been provided by the server and requests access to one or more services of one or more other servers, wherein the one or more other servers are different than the server.”
b. Applicant’s arguments that the Examiner has NOT established a prima facie case of obviousness because the Examiner has NOT provided factual evidence needed to establish a prima facia case of obviousness has been fully considered but is deemed not-persuasive. Applicant’s attention is directed to the fact that the Examiner has provided factual evidence needs to establish a prima facie case of obviousness and indicated that the combination of Kobayashi and Engan would provide for better security management and a more user-friendly environment by allowing a client to access a second server--a process which may not be transparent to the client--without the second server having to go through an authentication process or make a call to an identity provider.
c. Applicant’s arguments that Kobayashi and Engan et al. fail to teach the limitation of “obtaining (or obtaining) a second token, wherein the second token has been provided by the first server and requests access to one or more services of one or more other servers” has been fully considered but is deemed not-persuasive. Applicant’s attention is directed to Engan, Paragraph [0016], see “The service provider validates the authorization token with an identity provider public key to obtain the client public key, which the service provider then uses to validate the POP token to confirm that the entity making the request is the entity identified in the request…”, which is analogous to the client sending a first token to the server (authorization token, POP1) to indicate that the identity of the client has been verified, before the second token is provided by the server and requests access to one or more services of one or more other servers (AUTH, POP2). Applicant’s attention is further directed to Engan, Paragraph [0061], see “…The client-server-server system 700 depicts how an authentication token may be re-used by a first server in creation of a modified POP token that can be presented to a second server with the authentication token. Such an arrangement is useful when a server that has been accessed by a client needs to access a second server on behalf on the client or its own behalf…”. Applicant’s attention is further directed to Engan, Paragraph [0071], see “FIG. 8 is a representation of a structure of an HTTP request 800 from a first server, Server1, to access a secure service provided by a second server, Server2…The header 802 includes an authentication token 806 and a POP token 808”, where “Server1” provides a second token and requests access to one or more services of one or more other servers (Server2), where Server1 and Server2 are different servers.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the application regards as the invention.
Regarding claim 1, it is unclear due to the lack of antecedent basis for “the client” in line 4, as to what client the claim is referring to. The claim is therefore rendered indefinite.
Regarding claim 7, it is unclear due to the lack of antecedent basis for “the server” in line 1, as to which server the claim is referring to. The claim is therefore rendered indefinite.
Regarding claims 2-6, the claims are rejected because they are dependent to a previous rejected claim.
Appropriate correction(s) is/are required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 8-9, 13-16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kobayashi (U.S. PGPub. 2015/0350179), in view of Engan et al. (U.S. PGPub. 2019/0124070), hereinafter Engan.
Regarding claim 8, Kobayashi teaches A computer-implemented method for providing security in a computing environment that includes at least one client and at least one server configured to provide one or more services (Kobayashi, FIG. 4, see “1000” which is being read as at least one client and see “RESOURCE SERVER 400” which is being read as at least one server configured to provide one or more services), wherein the computer-implemented method is implemented at least partially by one or more physical processors configured to process executable computer code, and wherein the computer-implemented method comprises (Kobayashi, Paragraph [0177], see “The computer may comprise one or more of a central processing unit (CPU)…or separate computer processors. The computer executable instructions may be provided to the computer, for example, from a network or the storage medium”):
obtaining from a server a redirected request for service, wherein the redirected request for service is an initial request for service made by the client to the server for one or more services of the server (Kobayashi, Paragraph [0054], see “the user issues a request to start an authorization cooperation service that requires access to a protected resource”) (Kobayashi, Paragraph [0056], see “the resource server 400 issues a redirection request expressed as the HTTP/1.1 status code 302 to the browser on the client PC 200 so that the browser on the client PC 200 requests an OAuth authorization”, where “resource server 400” is being read as a server, which issues a redirected request for service from the server, wherein the redirected request for service is an initial request for service made by a client),
obtaining at least authentication credentials of the client, wherein the authentication credentials of the client are needed to verify the identity of the client (Kobayashi, Paragraph [0060], see “upon receiving the redirection request, the client PC 200 requests the authorization server 500 to authenticate the user and grant an authorization according to the redirection request…upon receiving the authorization request, the authorization server 500 returns a login screen 2000 illustrated in FIG. 6A to the browser on the client PC 200 to authenticate the user…the user as the resource owner 1000 inputs a user ID and a password onto the login screen 2000 displayed on the browser on the client PC 200”, where “user ID and a password” is being read as authentication credentials of the client);
generating a first token based at least on the authentication credentials of the client, wherein the first token includes authentication information associated with the client and indicates that the identity of the client has been verified (Kobayashi, Paragraph [0066], see “If the authorization confirmation has succeeded, in step S5.6, the authorization server module 510 performs access token issue processing for generating the access token that allows access to the resource server 400”, where a first token is generated based at least on the authentication credentials (i.e., If the authorization confirmation has succeeded using the authentication credentials of the user)) (Kobayashi, Paragraph [0067], see “The authorization server module 510 registers the generated access token into the Table 3…the authorization server module 510 stores scope information and the user ID contained in a record of an authentication token already registered in the token table into the scope and the user ID”, where the token includes authentication information associated with the client that indicates that the identity of the client has been verified);
providing the first token to the client, thereby allowing the client to send the first token to the server to indicate that the identity of the client has been verified (Kobayashi, Paragraph [0068], see “The access token response transmitted from the authorization server module 510 to the client PC 200 at this time (step S4.11) is configured according to the specification of OAuth 2.0…”, where the access token is provided to the client) (Kobayashi, Paragraph [0073], see “the web-hosted client module 310 of the web-hosted client 300 returns a response containing the script that allows the web browser 230 on the client PC 200 to acquire the access token…the client script 220 running on the web server 201, which has received the script for acquiring the access token, acquires the access token by executing the script. As a result, in step S4.15, the client script 220 can access the resource server 400”, where the client sends the token to the server to indicate that the identity of the client has been verified (e.g., thereby allowing access to the resource server 400);
Kobayashi does not teach the following limitation(s) as taught by Engan: obtaining a second token, wherein the second token has been provided by the server and requests access to one or more services of one or more other servers, wherein the one or more other servers are different than the server (Engan, Paragraph [0061], see “…The client-server-server system 700 depicts how an authentication token may be re-used by a first server in creation of a modified POP token that can be presented to a second server with the authentication token. Such an arrangement is useful when a server that has been accessed by a client needs to access a second server on behalf on the client or its own behalf…”) (Engan, Paragraph [0071], see “FIG. 8 is a representation of a structure of an HTTP request 800 from a first server, Server1, to access a secure service provided by a second server, Server2…The header 802 includes an authentication token 806 and a POP token 808”, where “Server1” provides a second token and requests access to one or more services of one or more other servers (Server2), where Server1 and Server2 are different servers).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the techniques for an authority transfer system, disclosed of Kobayashi, by implementing techniques of obtaining a second token, wherein the second token has been provided by the server and requests access to one or more services of one or more other servers, wherein the one or more other servers are different than the server, disclosed of Engan.
One of ordinary skill in the art would have been motivated to make this modification in order to implement techniques for security for diverse computing systems, comprising of obtaining a second token, wherein the second token has been provided by the server and requests access to one or more services of one or more other servers, wherein the one or more other servers are different than the server. This allows for a more user-friendly environment by allowing a client to access a second server—a process which may not be transparent to the client—without the second server having to go through an authentication process or make a call to an identity provider. Engan is deemed as analogous art due to the art disclosing techniques of obtaining a second token, wherein the second token has been provided by the server and requests access to one or more services of one or more other servers, wherein the one or more other servers are different than the server (Engan, Paragraph [0061]).
Regarding claim 9, Kobayashi as modified by Engan teaches The computer-implemented method of claim 8, wherein the computer-implemented method further comprises:
verifying the identity of the client based on the obtained authentication credentials of the client (Kobayashi, Paragraph [0050], see “The authorization server 500 has a function of verifying a pair of user ID information and password information, i.e., authentication information, and generating information indicating that a user or a client is authenticated if the combination is a valid combination, thereby authenticating each user or each client”).
Regarding claim 13, Kobayashi as modified by Engan teaches The computer-implemented method of claim 8, wherein the computer-implemented method further comprises:
requesting the authentication credentials from the client (Kobayashi, Paragraph [0060], see upon receiving the authorization request, the authorization server 500 returns a login screen 2000 illustrated in FIG. 6A to the browser on the client PC 200 to authenticate the user…the user as the resource owner 1000 inputs a user ID and a password onto the login screen 2000 displayed on the browser on the client PC 200”, where “the authorization server 500 returns a login screen 2000 to the browser on the client PC 200 to authenticate the user” is being read as requesting the authentication credentials from the client), and
sending the first token to the client (Kobayashi, Paragraph [0068], see “The access token response transmitted from the authorization server module 510 to the client PC 200 at this time (step S4.11) is configured according to the specification of OAuth 2.0…”, where the access token is provided to the client).
Regarding claim 14, Kobayashi as modified by Engan teaches The computer-implemented method of claim 8, wherein the server is a database server configured to provide access to one or more database services of a database (Kobayashi, Paragraph [0047], see “The resource server 400 includes a resource server module 410. The resource server module 410 includes a token authority confirmation unit 420, and a resource request processing unit 430”, where “resource server 400” is being read as a database server) (Kobayashi, Paragraph [0102], see “Upon receiving the access token information…the resource server 400 determines whether to permit or reject the access to the resource for which the request is received based on the acquired information”, where the database server (resource server 400) is configured to provide access to one database services of a database).
Regarding claim 15, Kobayashi teaches A non-transitory computer readable storage medium storing at least executable code that when executed provides security in a computing environment that includes at least one client and at least one server configured to provide one or more services, and wherein the executable code when executed further (Kobayashi, FIG. 4, see “1000” which is being read as at least one client and see “RESOURCE SERVER 400” which is being read as at least one server configured to provide one or more services) (Kobayashi, Paragraph [0177], see “The computer may comprise one or more of a central processing unit (CPU)…or separate computer processors. The computer executable instructions may be provided to the computer, for example, from a network or the storage medium”):
obtains from the server a redirected request for service, wherein the redirected request for service is an initial request for service made by the client to the server for one or more services of the server (Kobayashi, Paragraph [0054], see “the user issues a request to start an authorization cooperation service that requires access to a protected resource”) (Kobayashi, Paragraph [0056], see “the resource server 400 issues a redirection request expressed as the HTTP/1.1 status code 302 to the browser on the client PC 200 so that the browser on the client PC 200 requests an OAuth authorization”, where “resource server 400” is being read as a server, which issues a redirected request for service from the server, wherein the redirected request for service is an initial request for service made by a client);
obtains at least authentication credentials of the client, wherein the authentication credentials of the client are needed to verify the identity of the client (Kobayashi, Paragraph [0060], see “upon receiving the redirection request, the client PC 200 requests the authorization server 500 to authenticate the user and grant an authorization according to the redirection request…upon receiving the authorization request, the authorization server 500 returns a login screen 2000 illustrated in FIG. 6A to the browser on the client PC 200 to authenticate the user…the user as the resource owner 1000 inputs a user ID and a password onto the login screen 2000 displayed on the browser on the client PC 200”, where “user ID and a password” is being read as authentication credentials of the client);
generates a first token based at least on the authentication credentials of the client, wherein the first token includes authentication information associated with the client and indicates that the identity of the client has been verified (Kobayashi, Paragraph [0066], see “If the authorization confirmation has succeeded, in step S5.6, the authorization server module 510 performs access token issue processing for generating the access token that allows access to the resource server 400”, where a first token is generated based at least on the authentication credentials (i.e., If the authorization confirmation has succeeded using the authentication credentials of the user)) (Kobayashi, Paragraph [0067], see “The authorization server module 510 registers the generated access token into the Table 3…the authorization server module 510 stores scope information and the user ID contained in a record of an authentication token already registered in the token table into the scope and the user ID”, where the token includes authentication information associated with the client that indicates that the identity of the client has been verified);
provides the first token to the client, thereby allowing the client to send the first token to the server to indicate that the identity of the client has been verified (Kobayashi, Paragraph [0068], see “The access token response transmitted from the authorization server module 510 to the client PC 200 at this time (step S4.11) is configured according to the specification of OAuth 2.0…”, where the access token is provided to the client) (Kobayashi, Paragraph [0073], see “the web-hosted client module 310 of the web-hosted client 300 returns a response containing the script that allows the web browser 230 on the client PC 200 to acquire the access token…the client script 220 running on the web server 201, which has received the script for acquiring the access token, acquires the access token by executing the script. As a result, in step S4.15, the client script 220 can access the resource server 400”, where the client sends the token to the server to indicate that the identity of the client has been verified (e.g., thereby allowing access to the resource server 400);
Kobayashi does not teach the following limitation(s) as taught by Engan: obtains a second token, wherein the second token has been provided by the server and requests access to one or more services of one or more other servers, wherein the one or more other servers are different than the server (Engan, Paragraph [0061], see “…The client-server-server system 700 depicts how an authentication token may be re-used by a first server in creation of a modified POP token that can be presented to a second server with the authentication token. Such an arrangement is useful when a server that has been accessed by a client needs to access a second server on behalf on the client or its own behalf…”) (Engan, Paragraph [0071], see “FIG. 8 is a representation of a structure of an HTTP request 800 from a first server, Server1, to access a secure service provided by a second server, Server2…The header 802 includes an authentication token 806 and a POP token 808”, where “Server1” provides a second token and requests access to one or more services of one or more other servers (Server2), where Server1 and Server2 are different servers).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the techniques for an authority transfer system, disclosed of Kobayashi, by implementing techniques of obtaining a second token, wherein the second token has been provided by the server and requests access to one or more services of one or more other servers, wherein the one or more other servers are different than the server, disclosed of Engan.
One of ordinary skill in the art would have been motivated to make this modification in order to implement techniques for security for diverse computing systems, comprising of obtaining a second token, wherein the second token has been provided by the server and requests access to one or more services of one or more other servers, wherein the one or more other servers are different than the server. This allows for a more user-friendly environment by allowing a client to access a second server—a process which may not be transparent to the client—without the second server having to go through an authentication process or make a call to an identity provider. Engan is deemed as analogous art due to the art disclosing techniques of obtaining a second token, wherein the second token has been provided by the server and requests access to one or more services of one or more other servers, wherein the one or more other servers are different than the server (Engan, Paragraph [0061]).
Regarding claim 16, Kobayashi as modified by Engan teaches The non-transitory computer readable storage medium of claim 15, wherein the executable code when executed further:
verifies the identity of the client based on the obtained authentication credentials of the client (Kobayashi, Paragraph [0050], see “The authorization server 500 has a function of verifying a pair of user ID information and password information, i.e., authentication information, and generating information indicating that a user or a client is authenticated if the combination is a valid combination, thereby authenticating each user or each client”).
Regarding claim 20, Kobayashi as modified by Engan teaches The non-transitory computer readable storage medium of claim 17, wherein the executable code when executed further:
requests the authentication credentials from the client (Kobayashi, Paragraph [0060], see upon receiving the authorization request, the authorization server 500 returns a login screen 2000 illustrated in FIG. 6A to the browser on the client PC 200 to authenticate the user…the user as the resource owner 1000 inputs a user ID and a password onto the login screen 2000 displayed on the browser on the client PC 200”, where “the authorization server 500 returns a login screen 2000 to the browser on the client PC 200 to authenticate the user” is being read as requesting the authentication credentials from the client), and
sends the first token to the client (Kobayashi, Paragraph [0068], see “The access token response transmitted from the authorization server module 510 to the client PC 200 at this time (step S4.11) is configured according to the specification of OAuth 2.0…”, where the access token is provided to the client).
Claims 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Kobayashi, in view of Engan, in further view of Roth et al. (U.S. PGPub. 2017/0324782), hereinafter Roth.
Regarding claim 10, Kobayashi does not teach the following limitation(s) as taught by Engan: The computer-implemented method of claim 8, wherein the computer-implemented method further comprises:
generating a third token, wherein the third token includes authorization information allowing the server to access one or more other services of the one or more other servers, thereby allowing the server to send the third token to the one or more other servers to indicate that the server has been authorized to access the one or more other services of the one or more other servers (Engan, Claim 14, see “…creating a third token signed by a server private key; requesting access to a second server by transmitting the first token and the third token to the second server; and wherein the first token is used to validate a client device, and the third token is used to validate a requesting entity…”).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the techniques for an authority transfer system, disclosed of Kobayashi, by implementing techniques of generating a third access token, wherein the third access token includes authorization information allowing the server to access one or more other services of one or more other servers, disclosed of Engan.
One of ordinary skill in the art would have been motivated to make this modification in order to implement techniques for security for diverse computing systems, comprising of generating a third access token, wherein the third access token includes authorization information allowing the server to access one or more other services of one or more other servers. This allows for better security management, as well as a more user-friendly environment by allowing the user or server to access one or more other servers that are required for the request. Instead of having the user communicate with a plurality of different servers and undergo authentication, the user can initiate a request with a first server, and the first server can transparently gain access to one or more other servers that are required to fulfill the users request. Engan is deemed as analogous art due to the art disclosing techniques of generating a third access token, wherein the third access token includes authorization information allowing the server to access one or more other services of one or more other servers (Engan, Claim 14).
In addition, Roth teaches in Paragraph [0086], see “…The authentication service 710 may provide, in response to the request from the first service 706, an authentication response comprising an authentication determination and additional authentication information. The additional authentication information may include a signing key usable to sign requests to one or more other services so as to be verifiable by the one or more services…”) (Roth, Paragraph [0087], see “The additional authentication information may also include one or more tokens, where the one or more tokens may be specific to one or more services. A token may comprise a service-specific authentication response…The service-specific authentication response may include information specific to the corresponding service 708…the service-specific authentication response may include policy associated with the customer 702 and applicable to the corresponding service 708, an attestation to the identity of the customer 702, and an electronic signature generated based at least in part on a secret key shared between the corresponding service 708 and the authentication service 710”, where “The additional authentication information may also include one or more tokens, where the one or more tokens may be specific to one or more services” is analogous to generating a third access token, where “A token may comprise a service-specific authentication response…the service-specific authentication response may include…an attestation to the identity of the customer 702, and an electronic signature generated based at least in part on a secret key shared between the corresponding service 708 and the authentication service 710” is analogous to the third access token (i.e., one or more tokens specific to one or more services) provided to the first service including authorization information allowing the first service to access one or more other services of one or more other servers (i.e., corresponding service 708), which enables the first service to send the corresponding token to the one or more other services to indicate that it has been authorized to access the one or more other services).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the techniques for an authority transfer system, disclosed of Kobayashi, and techniques disclosed of Engan, by implementing techniques for access control using impersonation, comprising of generating a third token, wherein the third token includes authorization information allowing the server to access one or more other services of one or more other servers, disclosed of Roth.
One of ordinary skill in the art would have been motivated to make this modification in order to implement techniques for security for diverse computing systems, comprising of generating a third token, wherein the third token includes authorization information allowing the server to access one or more other services of one or more other servers. This allows for better security management, as well as a more user friendly environment by allowing the user to request access to a specific service to a first server, wherein the first server redirects the user to the requested service after appropriate authentication. Instead of having the user communicate with a plurality of different services, the user can initiate a request with a first service, and the first service can acquire any resources needed to fulfill the users’ request. Roth is deemed as analogous art due to the art disclosing techniques of generating a third token, wherein the third token includes authorization information allowing the server to access one or more other services of one or more other servers (Roth, Paragraphs [0086 – 0087]).
Regarding claim 17, Kobayashi does not teach the following limitation(s) as taught by Engan: The non-transitory computer readable storage medium of claim 15, wherein the executable code when executed further:
generates a third token, wherein the third token includes authorization information allowing the server to access one or more other services of the one or more other servers, thereby allowing the server to send the third token to the one or more other servers to indicate that the server has been authorized to access the one or more other services of the one or more other servers (Engan, Claim 14, see “…creating a third token signed by a server private key; requesting access to a second server by transmitting the first token and the third token to the second server; and wherein the first token is used to validate a client device, and the third token is used to validate a requesting entity…”).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the techniques for an authority transfer system, disclosed of Kobayashi, by implementing techniques of generating a third access token, wherein the third access token includes authorization information allowing the server to access one or more other services of one or more other servers, disclosed of Engan.
One of ordinary skill in the art would have been motivated to make this modification in order to implement techniques for security for diverse computing systems, comprising of generating a third access token, wherein the third access token includes authorization information allowing the server to access one or more other services of one or more other servers. This allows for better security management, as well as a more user-friendly environment by allowing the user or server to access one or more other servers that are required for the request. Instead of having the user communicate with a plurality of different servers and undergo authentication, the user can initiate a request with a first server, and the first server can transparently gain access to one or more other servers that are required to fulfill the users request. Engan is deemed as analogous art due to the art disclosing techniques of generating a third access token, wherein the third access token includes authorization information allowing the server to access one or more other services of one or more other servers (Engan, Claim 14).
In addition, Roth teaches in Paragraph [0086], see “…The authentication service 710 may provide, in response to the request from the first service 706, an authentication response comprising an authentication determination and additional authentication information. The additional authentication information may include a signing key usable to sign requests to one or more other services so as to be verifiable by the one or more services…”) (Roth, Paragraph [0087], see “The additional authentication information may also include one or more tokens, where the one or more tokens may be specific to one or more services. A token may comprise a service-specific authentication response…The service-specific authentication response may include information specific to the corresponding service 708…the service-specific authentication response may include policy associated with the customer 702 and applicable to the corresponding service 708, an attestation to the identity of the customer 702, and an electronic signature generated based at least in part on a secret key shared between the corresponding service 708 and the authentication service 710”, where “The additional authentication information may also include one or more tokens, where the one or more tokens may be specific to one or more services” is analogous to generating a third access token, where “A token may comprise a service-specific authentication response…the service-specific authentication response may include…an attestation to the identity of the customer 702, and an electronic signature generated based at least in part on a secret key shared between the corresponding service 708 and the authentication service 710” is analogous to the third access token (i.e., one or more tokens specific to one or more services) provided to the first service including authorization information allowing the first service to access one or more other services of one or more other servers (i.e., corresponding service 708), which enables the first service to send the corresponding token to the one or more other services to indicate that it has been authorized to access the one or more other services).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the techniques for an authority transfer system, disclosed of Kobayashi, and techniques disclosed of Engan, by implementing techniques for access control using impersonation, comprising of generating a third token, wherein the third token includes authorization information allowing the server to access one or more other services of one or more other servers, disclosed of Roth.
One of ordinary skill in the art would have been motivated to make this modification in order to implement techniques for security for diverse computing systems, comprising of generating a third token, wherein the third token includes authorization information allowing the server to access one or more other services of one or more other servers. This allows for better security management, as well as a more user friendly environment by allowing the user to request access to a specific service to a first server, wherein the first server redirects the user to the requested service after appropriate authentication. Instead of having the user communicate with a plurality of different services, the user can initiate a request with a first service, and the first service can acquire any resources needed to fulfill the users’ request. Roth is deemed as analogous art due to the art disclosing techniques of generating a third token, wherein the third token includes authorization information allowing the server to access one or more other services of one or more other servers (Roth, Paragraphs [0086 – 0087]).
Claims 11-12 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Kobayashi, in view of Engan, in further view of Roth, in further view of FAN (U.S. PGPub. 2018/0375863), hereinafter Fan.
Regarding claim 11, Kobayashi as modified by Engan and further modified by Roth do not teach the following limitation(s) as taught by Fan: The computer-implemented method of claim 10, wherein the second token includes the first token and identifies the server (Fan, Paragraph [0008], see “where the password-free login request includes a third token, the third token includes a second token, and the second token is an access token indicating that the second website grants password-free login permission after user login succeeds”, where “third token” is analogous to the second token, where “second token” is analogous to the first token and where the third token (being read as the second token) includes the second token (being read as the first token) (Fan, Paragraph [0046], see “Token can include three types of information: a website identifier signed by payment website A by using a private key of the website, a current time signed by using the private key of the website, and the user name in the login information”, where “website” is analogous to a server and wherein the tokens contain a website identifier).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the techniques for an authority transfer system, disclosed of Kobayashi, techniques disclosed of Engan and techniques disclosed of Roth, by implementing techniques for a website login method that involves redirecting a user, comprising of a second token including a first token and wherein the second token identifies the server, disclosed of Fan.
One of ordinary skill in the art would have been motivated to make this modification in order to implement techniques for security for diverse computing systems, comprising of a second token including a first token and wherein the second token identifies the server. This allows for maintaining a secure computing environment, whilst avoiding the need to re-authenticate the user’s credentials, which ultimately saves time and reduces processing power. By including the first token (already authenticated credentials) within the second token, the computing system can avoid re-authenticating the user’s credentials. Fan is deemed as analogous art due to the art disclosing techniques for a second token including a first token and wherein the second token identifies the server (Fan, Paragraph [0008]).
Regarding claim 12, Kobayashi as modified by Engan and further modified by Roth do not teach the following limitation(s) as taught by Fan: The computer-implemented method of claim 10, wherein the second token is the first token that is signed by the server (Fan, Paragraph [0148], see “the third token may include a signed version of the second token, such as where the second token is signed by the first website…”, where “third token” is analogous to the second token, where “second token” is analogous to the first token and where the third token (being read as the second token) is a signed version of the second token (being read as the first token)).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the techniques for an authority transfer system, disclosed of Kobayashi, techniques disclosed of Engan and techniques disclosed of Roth, by implementing techniques for a website login method that involves redirecting a user, comprising of the second token being the first token that is signed by the server, disclosed of Fan.
One of ordinary skill in the art would have been motivated to make this modification in order to implement techniques for security for diverse computing systems, comprising of a second token being the first token that is signed by the server. This allows for maintaining a secure computing environment, whilst avoiding the need to re-authenticate the user’s credentials, which ultimately saves time and reduces processing power. Having the second token be the first token that is signed by the server allows for the computing system to grant access to the user based on the signature of the server whilst avoiding the need to re-authenticate the user’s credentials. Fan is deemed as analogous art due to the art disclosing techniques for a second token being the first token that is signed by the server (Fan, Paragraph [0148]).
Regarding claim 18, Kobayashi as modified by Engan and further modified by Roth do not teach the following limitation(s) as taught by Fan: The non-transitory computer readable storage medium of claim 17, wherein the second token includes the first token and identifies the server (Fan, Paragraph [0008], see “where the password-free login request includes a third token, the third token includes a second token, and the second token is an access token indicating that the second website grants password-free login permission after user login succeeds”, where “third token” is analogous to the second token, where “second token” is analogous to the first token and where the third token (being read as the second token) includes the second token (being read as the first token) (Fan, Paragraph [0046], see “Token can include three types of information: a website identifier signed by payment website A by using a private key of the website, a current time signed by using the private key of the website, and the user name in the login information”, where “website” is analogous to a server and wherein the tokens contain a website identifier).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the techniques for an authority transfer system, disclosed of Kobayashi, techniques disclosed of Engan and techniques disclosed of Roth, by implementing techniques for a website login method that involves redirecting a user, comprising of a second token including a first token and wherein the second token identifies the server, disclosed of Fan.
One of ordinary skill in the art would have been motivated to make this modification in order to implement techniques for security for diverse computing systems, comprising of a second token including a first token and wherein the second token identifies the server. This allows for maintaining a secure computing environment, whilst avoiding the need to re-authenticate the user’s credentials, which ultimately saves time and reduces processing power. By including the first token (already authenticated credentials) within the second token, the computing system can avoid re-authenticating the user’s credentials. Fan is deemed as analogous art due to the art disclosing techniques for a second token including a first token and wherein the second token identifies the server (Fan, Paragraph [0008]).
Regarding claim 19, Kobayashi as modified by Engan and further modified by Roth do not teach the following limitation(s) as taught by Fan: The non-transitory computer readable storage medium of claim 17, wherein the second token is the first token that is signed by the server (Fan, Paragraph [0148], see “the third token may include a signed version of the second token, such as where the second token is signed by the first website…”, where “third token” is analogous to the second token, where “second token” is analogous to the first token and where the third token (being read as the second token) is a signed version of the second token (being read as the first token)).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the techniques for an authority transfer system, disclosed of Kobayashi, techniques disclosed of Engan and techniques disclosed of Roth, by implementing techniques for a website login method that involves redirecting a user, comprising of the second token being the first token that is signed by the server, disclosed of Fan.
One of ordinary skill in the art would have been motivated to make this modification in order to implement techniques for security for diverse computing systems, comprising of a second token being the first token that is signed by the server. This allows for maintaining a secure computing environment, whilst avoiding the need to re-authenticate the user’s credentials, which ultimately saves time and reduces processing power. Having the second token be the first token that is signed by the server allows for the computing system to grant access to the user based on the signature of the server whilst avoiding the need to re-authenticate the user’s credentials. Fan is deemed as analogous art due to the art disclosing techniques for a second token being the first token that is signed by the server (Fan, Paragraph [0148]).
Allowable Subject Matter
Claims 1-7 are allowed, assuming Applicant overcomes the outstanding 35 U.S.C. 112(b) rejections and Double Patenting rejection.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim 15 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 14 of issued Patent 11,409,893, Application No. 16/199,485. Although the claims at issue are not identical, they are not patentably distinct from each other. Claim 14 of the reference patent covers all the limitations of claim 15 of the instant application and, as such, anticipates claim 15 of the instant application.
Instant Application No. 17/864,387
Reference Patent No. 11,409,893
Claim 15: A non-transitory computer readable storage medium storing at least executable code that when executed provides security in a computing environment that includes at least one client and at least one server configured to provide one or more services, and wherein the executable code when executed further:
obtains from the server a redirected request for service, wherein the redirected request for service is an initial request for service made by the client to the server for one or more services of the server;
obtains at least authentication credentials of the client, wherein the authentication credentials of the client are needed to verify the identity of the client;
generates a first token based at least on the authentication credentials of the client, wherein the first token includes authentication information associated with the client and indicates that the identity of the client has been verified;
provides the first token to the client, thereby allowing the client to send the first token to the server to indicate that the identity of the client has been verified; and
obtains a second token, wherein the second token has been provided by the server and requests access to one or more services of one or more other servers, wherein the one or more other servers are different than the server.
Claim 14: A non-transitory computer readable storage medium storing at least executable code that when executed provides security in a computing environment that includes at least one client and at least one server configured to provide one or more services, and wherein the executable code when executed further:
obtains, from the server, a redirected request, wherein the redirected request for service is an initial request for service made by the client to the server for one or more services of the server;
obtains at least authentication credentials of the client, wherein the authentication credentials of the client are needed to verify the identity of the client;
generates a first token based at least on the authentication credentials of the client, wherein the first token includes authentication information associated with the client and indicates that the identity of the client has been verified;
provides the first token to the client, thereby allowing the client to send the first token to the server to indicate that the identity of the client has been verified; and
obtain a second token, wherein the second token has been provided by the server and requests access to one or more services of one or more other servers.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RODMAN ALEXANDER MAHMOUDI whose telephone number is (571)272-8747. The examiner can normally be reached on M-F 11:00am – 7:00pm.
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, Philip Chea can be reached on (571) 272-3951. 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). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/RODMAN ALEXANDER MAHMOUDI/Examiner, Art Unit 2499
Prosecution Insights