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 .
This action is in response to the claims filed 3/12/2026. Claims 21-27, 30-36, and 38-43 are pending. Claims 21 (a machine), 30 (a method) and 39 (a non-transitory CRM) are independent.
Response to Arguments
Applicant’s arguments, see page 8, filed 3/12/2026, with respect to the double patenting rejections have been fully considered and are persuasive. The double patenting rejections have been withdrawn due to the filing of a terminal disclaimer.
Applicant’s arguments, see page 7, filed 3/12/2026, with respect to the rejection of claims 21-40 in view of Venkataramappa, US 2003/0188193, in view of Lynch, US 2005/0144452 have been fully considered and are persuasive. The rejection of claims 21-27 has been withdrawn.
Upon further consideration, a new ground(s) of rejection is made in claims 30-36 and 38-43 in further view of Peterka et al., US 2004/0128499 (published 2004).
Allowable Subject Matter
Claims 21-27 are allowed.
The following is a statement of reasons for the indication of allowable subject matter: While the combination of Venkataramappa, US 2003/0188193, in view of Lynch, US 2005/0144452 and Jensenworth et al., US 6,279,111 were stated to render the parent claims 28 and 37 obvious, they do not further disclose “(2) additional data comprising a product name of a protected resource as identified in the first access management computing system, and product options associated with the product name”. Thus, none of the references of record, alone or in combination with the other references, would anticipate or reasonably render obvious the combination of features required in claim 21. Claims 21-27 are allowed.
Note that claim 38 is allowable but objected to as dependent on a rejected base claim 30.
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) 30, 33, 34, 39, 40, and 43 is/are rejected under 35 U.S.C. 103 as being unpatentable over Venkataramappa, IS 2003/0188193 (published 2003), in view of Lynch, US 2005/0144452 (published 2005), and Peterka et al., US 2004/0128499 (published 2004).
As to claims 30, and 39, Venkataramappa discloses a method/CRM comprising:
the computer-implemented method comprising, as implemented by one or more computing devices (Venkataramappa Fig 2) within a token gateway system configured with specific executable instructions: (Venkataramappa Fig 3, Server 1, 301)
receiving, from a user computing system, a first data packet including user credentials of a user and a request for an authentication token to access one or more protected resources from a protected resource computing system; (“First, the client (300) sends (31) a user ID and password to a first server (301) to which the user or client wishes access” Venkataramappa ¶ 55)
transmitting a second data packet to a first access management computing system; (“The first server (301) performs a normal Kerberos login to the KDC on behalf of the client by contacting (32) the KDC (302) to obtain a TGT (33) for the client.” Venkataramappa ¶ 55)
receiving, from the first access management computing system, validation of the user, and private data; (“If the user ID and password are correct, the KDC (302) creates a ticket-granting ticket for the client, and sends (33) the TGT to the first server (301).” Venkataramappa ¶ 55)
generating a first token; (“the first server ( 301) then creates a first SSO Token” Venkataramappa ¶ 56)
generating a second token using the private data, (“the TGT, and stores (34) them in a SSOToken-to-Credential mapping table (311), thereby creating an association between the client's TGT and the SSOToken.” Venkataramappa ¶ 56)
transmitting the first token to the user computing system; (“Finally, the SSOToken, but not the TGT, is sent (35) to the client (300) by the first server (301) for subsequent use when communicating with the first server and accessing (313) its services.” Venkataramappa ¶ 57)
receiving, from the user computing system, a request to access the one or more protected resources from the protected resource computing system, the request comprising the first token; (“In response to receipt of this request from the client (300), the second server (303) requests (38) the client's credentials from the originator of the SSOToken (using the originator indication from the SSOToken), such as in this example the first server (301).” Venkataramappa ¶ 60. See also ¶ 63)
validating the received first token; and (“the originating server ( 301) retrieves (315) the TGT(Cred) associated with the SSOToken received from the second server (303).” Venkataramappa ¶ 61. A verification since failure to locate the associated TGT credential would cause the lookup/method to fail.)
transmitting the second token to the protected resource computing system. (“Then, the originating server (301) initiates a Generic Security Service (“GSS”) secure association with the second server (303) by using the client's (300) TGT as a forwardable TGT. When this GSS association is complete, the second server (303) will have received (39) client's credentials (TGT).” Venkataramappa ¶ 61)
Venkataramappa does not disclose: wherein the second token comprises a first portion of the first token and additional data comprising a product name of a protected resource as identified in the first access management computing system, and product options associated with the product name;
Lynch discloses:
generate a first token; (“the token is divided into portions to provide a partial token from the primary site to the secondary site at processing block 620.” Lynch ¶ 81)
generate a second token using the private data, (“If the user agrees to the consent agreement, a token is generated for the user by the primary site at processing block 618.” Lynch ¶ 80. See also Lynch ¶ 74 for exemplary token information, and Lynch ¶ 71 discussing authorization levels of secondary sites.) wherein the second token comprises a first portion of the first token and additional data; (“the token may first be divided into two or more portions and a partial token is sent to the secondary site. The remaining portion of the token is kept at the primary site.” Lynch ¶ 102. “upon receiving of the portion of the token, the primary site 506 verifies the token by matching it with the other portion of the token that it owns. If the two portions of the token are matched, the user 502 is permitted to access the primary site 506.” Lynch ¶ 77. Matched meaning the same first portion. “each secondary site 504 receives a token (or a portion of the token) that is distinct from the token at another secondary site.” Lynch ¶ 77. Different portions.).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Venkataramappa with Lynch by incorporating a token segmentation mechanism similar to that of Lynch. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combined Venkataramappa with Lynch in order to allow configurable access to a user’s personal data between various systems when practicing federated authentication systems, Lynch ¶ 82 and Venkataramappa ¶ 2, thereby allowing a user to use single-sign on convenience without unlimited permissions to semi-trusted partners.
Venkataramappa in view of Lynch does not explicitly disclose:
comprising a product name of a protected resource as identified in the first access management computing system, and product options associated with the product name;
Peterka discloses: comprising a product name of a protected resource as identified in the first access management computing system (“When the user provisions with ESPN the user receives subscription services for ESPN-administered content such as different program channels (e.g., ESPN-1, ESPN-2). The authorization data can be included in a TGT and then transferred to a service ticket issued by the TGS.” Peterka ¶ 17), and product options associated with the product name; (“The authentication service may also include inside the TGT authorization data obtained from entitlement service 124 that can indicate permissions, or restrictions, based on a specific customer's rights.” Peterka ¶ 36)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Venkataramappa in view of Lynch with Peterka by incorporating the authorization included in the TGT of Peterka into the TGT of Benkataramappa (¶¶ 56-57). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed inventio to combine Venkataramappa in view of Lynch with Peterka in order to allow the TGT permissions system to handle localization as well as different access and provisioning rules, Peterka ¶ 9.
As to claims 33 and 43, Venkataramappa in view of Lynch and Peterka discloses the machine/method/CRM of claims 30, and 39 and further discloses:
wherein the first token is a thin token and the second token is a fat token. (Lynch ¶¶ 77 and 102. Describing the tokens in terms of Applicant lexicography does not afford additional limitations to the claim scope. See MPEP 2173.01).
As to claims 34, Venkataramappa in view of Lynch and Peterka discloses the machine/method/CRM of claims 30, and 39 and further discloses:
wherein the first portion of the first token comprises a payload. (“upon receiving of the portion of the token, the primary site 506 verifies the token by matching it with the other portion of the token that it owns. If the two portions of the token are matched, the user 502 is permitted to access the primary site 506.” Lynch ¶ 77. Any portion of the token may be considered a payload.)
As to claim 40, Venkataramappa in view of Lynch and Peterka discloses the machine/method/CRM of claims 30, and 39 and further discloses:
wherein the first token includes a key pointing to the second token. (“The SSOToken contains an identifier such as a Universal Resource Locator (“URL”) of the originator of the SSOToken, such as the first server's ( 301) URL in this example, and an unique identifier, such as a number, for the client to which it was issued. For security purposes, the SSOToken which is supplied to the client does not contain the client's TGT, user ID or password; it just contains a unique number generated by the SSOToken originating server which corresponds to the client's TGT(cred) in the originating server's SSOToken-to-Credential mapping table.” Venkataramappa ¶ 58. “a determination is made as to whether the partial token received from the secondary site matches with the partial token residing at the primary site.” Lynch ¶ 79)
Claim(s) 31, 32, 36, 41, and 42 is/are rejected under 35 U.S.C. 103 as being unpatentable over Venkataramappa, IS 2003/0188193 (published 2003), in view of Lynch, US 2005/0144452 (published 2005), Peterka et al., US 2004/0128499 (published 2004), and Sakimura et al. “OpenID Connect Core 1.0” (published 2014-11).
As to claims 31 and 41, Venkataramappa in view of Lynch and Peterka discloses the machine/method/CRM of claims 30, and 39 but does not disclose:
wherein the first token and the second token are based on a JavaScript Object Notation (JSON) web token standard.
Sakimura discloses:
wherein the first token and the second token are based on a JavaScript Object Notation (JSON) web token standard. (“The ID Token is represented as a JSON Web Token (JWT) [JWT].” Sakimura § 2. “UserInfo Response is signed and/or encrypted, then the Claims are returned in a JWT and the content-type MUST be application/jwt. The response MAY be encrypted without also being signed. If both signing and encryption are requested, the response MUST be signed then encrypted, with the result being a Nested JWT, as defined in [JWT].” Sakimura § 5.3.2)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have modified Venkataramappa in view of Lynch and Peterka with Sakimura by utilizing the OpenID JSON tokens as the tokens of Venkataramappa in view of Lynch. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Venkataramappa in view of Lynch and Peterka with Sakimura in order to interface with common web authentications using OAuth and to provide the ability to verify and obtain basic profile information of end users within the authenticated tokens, Sakimura § 1.
As to claims 32 and 42, Venkataramappa in view of Lynch and Peterka discloses the machine/method/CRM of claims 30, and 39 but does not disclose:
wherein the token gateway computing system is further configured to transmit the second data packet based on a type associated with the one or more protected resources requested.
Sakimura discloses: wherein the token gateway computing system is further configured to transmit the second data packet based on a type associated with the one or more protected resources requested. (“By requesting Claims as Essential Claims, the RP indicates to the End-User that releasing these Claims will ensure a smooth authorization for the specific task requested by the End-User.” Sakimura § 5.5.1. the protected resource requesting specific “claims” for authentication the type of claims requested being a type of protected resource. See also Sakimura §§ 5.4-5.5)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have modified Venkataramappa in view of Lynch and Peterka with Sakimura by utilizing the OpenID JSON tokens as the tokens of Venkataramappa in view of Lynch. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Venkataramappa in view of Lynch and Peterka with Sakimura in order to interface with common web authentications using OAuth and to provide the ability to verify and obtain basic profile information of end users within the authenticated tokens, Sakimura § 1.
As to claim 36, Venkataramappa in view of Lynch and Peterka discloses the machine/method/CRM of claim 30, and 39 but does not disclose:
wherein the first portion of the first token includes at least a username, an email, a first name, an issuer of the first token, a last name, an expiry time, an issue time, and a unique identifier.
Sakimura discloses:
wherein the first portion of the first token includes at least a username (“preferred_username” or “name” Sakimura § 5.1), an email (“End-User's preferred e-mail address.” Sakimura § 5.1), a first name (“Given name(s) or first name(s) of the End-User.” Sakimura § 5.1), an issuer of the first token (“REQUIRED. Issuer Identifier for the Issuer of the response.” Sakimura § 2), a last name (“Surname(s) or last name(s) of the End-User.” Sakimura § 5.1), an expiry time (“REQUIRED. Expiration time on or after which the ID Token MUST NOT be accepted for processing.” Sakimura § 2), an issue time (“REQUIRED. Time at which the JWT was issued.”), and a unique identifier. (“REQUIRED. Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User,” Sakimura § 2. See also Sakimura § 5.7)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have modified Venkataramappa in view of Lynch and Peterka with Sakimura by utilizing the OpenID JSON tokens as the tokens of Venkataramappa in view of Lynch. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Venkataramappa in view of Lynch and Peterka with Sakimura in order to interface with common web authentications using OAuth and to provide the ability to verify and obtain basic profile information of end users within the authenticated tokens, Sakimura § 1.
Claim(s) 35 is/are rejected under 35 U.S.C. 103 as being unpatentable over Venkataramappa, IS 2003/0188193 (published 2003), in view of Lynch, US 2005/0144452 (published 2005), Peterka et al., US 2004/0128499 (published 2004), and Jones et al., “JSON Web Signature (JWS)” (published 2015).
As to claim 35, Venkataramappa in view of Lynch and Peterka discloses the machine/method/CRM of claims 30, and 39 but does not disclose:
wherein the first token and second token headers each include a public key and a type associated with the token.
Jones discloses:
wherein the first token and second token headers each include a public key (“The "jwk" (JSON Web Key) Header Parameter is the public key that corresponds to the key used to digitally sign the JWS.” Jones § 4.1.3) and a type associated with the token. (“The "typ" (type) Header Parameter is used by JWS applications” Jones § 4.1.9).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Venkataramappa in view of Lynch and Peterka with Jones by utilizing the parameters and structure of JWT tokens of Jones in the tokens of Venkataramappa in view of Lynch. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to use the JWT tokens and parameters of Jones in the tokens of Venkataramappa in view of Lynch in order to secure the tokens with signatures and cryptographic algorithms, thereby providing tamper proof storage of critical credential data.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892, particularly:
Brezak et al., US 2003/0018913, disclosing controlling the scope of delegation of authentication credentials.
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 MICHAEL W CHAO whose telephone number is (571)272-5165. The examiner can normally be reached M, W-F 8-5.
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, Rupal Dharia can be reached at (571) 272-3880. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/MICHAEL W CHAO/ Primary Examiner, Art Unit 2492