DETAILED ACTION
Claims 1-38 are currently pending in the application. Claims 1-38 are original claims to patent US 11,411,746 B2 to Godfrey (herein Godfrey ‘746).
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 .
Reissue Applications
For reissue applications filed before September 16, 2012, all references to 35 U.S.C. 251 and 37 CFR 1.172, 1.175, and 3.73 are to the law and rules in effect on September 15, 2012. Where specifically designated, these are “pre-AIA ” provisions.
For reissue applications filed on or after September 16, 2012, all references to 35 U.S.C. 251 and 37 CFR 1.172, 1.175, and 3.73 are to the current provisions.
Applicant is reminded of the continuing obligation under 37 CFR 1.178(b), to timely apprise the Office of any prior or concurrent proceeding in which Patent No. 11,411,746 is or was involved. These proceedings would include any trial before the Patent Trial and Appeal Board, interferences, reissues, reexaminations, supplemental examinations, and litigation.
Applicant is further reminded of the continuing obligation under 37 CFR 1.56, to timely apprise the Office of any information which is material to patentability of the claims under consideration in this reissue application.
These obligations rest with each individual associated with the filing and prosecution of this application for reissue. See also MPEP §§ 1404, 1442.01 and 1442.04.
Consent of Assignee
This application is objected to under 37 CFR 1.172(a) as lacking the written consent of all assignees owning an undivided interest in the patent. The consent of the assignee must be in compliance with 37 CFR 1.172. See MPEP § 1410.01.
The Consent of Assignee filed 10/21/2024 does not apply to the current assignee as shown by the 3.73 Assignee Ownership Statement of 05/22/2026.
A proper assent of the assignee in compliance with 37 CFR 1.172 and 3.73 is required in reply to this Office action.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 7, 9, 11, 14-16, 19, 25, 27, 29, 32-34, 37, and 38 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Proof-of-Possession Tokens in Microservice Architectures” by Ruaridh Watt (herein Watt).
Claim 1
Watt
A certificate issuer computing system for enforcing permissions delegation in a computing environment, the certificate issuer computing system having permissions to execute at least one transaction on behalf of a user the system comprising:
Watt shows a certificate issuer with permissions to execute (Watt: page 9, figure 1 and table 2, Authorization Server issuing Access Tokens) enabling limited access/permissions to execute at least one transaction on behalf of a user (Watt: page 8, second to last paragraph, “… This enables users to grant third-party applications limited access to services on their behalf without disclosing their authentication credentials to the third-party …”).
one or more hardware processors configured by machine-readable instructions to:
Watt shows executing the described protocols using applications running on hardware processors (Watt: page 33, fourth paragraph; page 44, table 12).
receive an initial permissions request, from a requesting computing system, for a permissions certificate, the permissions request specifying permissions to
execute at least a subset of the at least one transaction on behalf of the user;
Watt shows an Authorization Server receiving a permissions request (Watt: page 9, figure 1, Authorization Request) from a requesting computing system (Watt: page 9, figure 1, Client; page 9, table 2) through the Web-browser.
PNG
media_image1.png
398
684
media_image1.png
Greyscale
Watt shows the permissions request specifying permissions to execute at least a subset of one transaction on behalf of the user (Watt: page 8, second to last paragraph, “… This enables users to grant third-party applications limited access to services on their behalf without disclosing their authentication credentials to the third-party …”).
in response to receiving the initial permissions request, transmit a login request to a user computing system associated with a user;
Watt shows transmitting a login request to a user computer in response to receiving the authorization request (Watt: page 9, figure 1, Authorization Server sending “Authentication & Authorization” to the Web-browser; page 9, “… The end-user authenticates, authorizes the Client’s request and is then redirected back to the Client with an Authorization Grant, as shown in Figure 1”).
To the extent Watt does not explicitly state the “Authentication & Authorization” includes transmitting a login request, Watt demonstrates that it was known before the effective filing date of the claimed invention to use login for authentication (Watt: page 23, Listing 5, “GET /login?” request). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the “Authentication & Authorization” of Watt with a login request as suggested by the further teachings of Watt. This implementation would have been obvious because one of ordinary skill in the art would have found: the implementation of is an application of a known element and technique yielding a predictable result for authentication, which was known and disclosed by the authors of Watt.
receive an acceptance from the user in response to the login request;
Watt shows receiving acceptance from the user (Watt: figure 1, Authorization Server receiving “Authentication & Authorization” from Web-browser; page 9, “… The end-user authenticates, authorizes the Client’s request and is then redirected back to the Client with an Authorization Grant, as shown in Figure 1”).
generate a permissions certificate data structure in response to the acceptance, the permissions certificate data structure including an identity associated with the requesting computing device, an identity associated with the issuer computing system, a permissions indication indicating the permissions to execute the at least a subset of the at least one transaction on behalf of the user, and a certificate signature of the certificate issuer computer system private key against the certificate;
Watt shows making a permissions certificate/token (Watt: pages 17-19, at least Access Token) including a requesting device identity (Watt: page 18, table 4, “aud” ; page 19, listing 3), an issuer identity (Watt: page 18, table 4, “iss”; page 19, listing 3), a permissions indication of the subset of the transaction (Watt: page 19, first paragraph, “Additional claims may be included in the Access Token, for example, roles and/or groups may be used to grant additional privileges to specific users …”), and an issuer private key signature (Watt: page 10, section 2.4, first paragraph; page 11, second paragraph; the message/certificate/token is protected by a digital signature which can be by using a private key from the issuer).
To the extent Watt does not explicitly define the access tokens of the figure 1 embodiment, Watt demonstrates that it was known before the effective filing date of the claimed invention to use access tokens as described in the preceding paragraph (Watt: pages 17-19, at least Access Token). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the access tokens of Watt’s figure 1 as found in the Watt’s later description of access tokens. This implementation would have been obvious because one of ordinary skill in the art would have found: the implementation of is an application of a known element and technique yielding a predictable result for authentication, which was known and disclosed by the authors of Watt.
return the permissions certificate data structure to the requesting computing system whereby the requesting computing system will be permitted to accomplish the at least a subset of the at least one transaction on behalf of the user with a transacting party, by attaching the permissions certificate data structure to a request for the transaction, in place of the certificate issuer computing system.
Watt shows the requesting computer (Watt: page 9, Client) receiving (server having returned) a certificate/token from an Authorization Server via a Web-browser (Watt: page 9, figure 1) and as such being able to accomplish at least a subset of a transaction on behalf of the user (Watt: page 9, second to last paragraph, “OAuth 2.0, billed as ‘the industry-standard protocol for authorization’ … effectively decouples authentication and authorization. This enables users to grant third-party applications limited access to services on their behalf without disclosing their authentication credentials to the third-party”), by attaching the permissions certificate data structure to a request for the transaction (Watt: page 9, Table 2 showing transaction requests by Client making resource requests, and Resource Server “responding to resource requests with respect to Access Token included in the request”). Watt shows the requesting computing system permitted to accomplish the subset of the transaction based on possession of the permissions certificate/token (Watt: page 12, third paragraph; page 12, section 2.4.2; and as above) paired with a cryptographic signature based on a private key of the requesting computer (page 12, section 2.4.2, first paragraph, “… This effectively binds a JWT to a specific Client by making it unusable without the Client’s secret key”).
Note, the language “whereby the requesting computing system will be permitted to accomplish the at least a subset of the at least one transaction on behalf of the user with a transacting party, by attaching the permissions certificate data structure to a request for the transaction, in place of the certificate issuer computing system” is an intended use statement that does not add significantly to the claim requirements.
Claim 7
Watt
The system of claim 1, wherein the transaction is access to at least one of
computing resources and/or a physical property.
Watt shows transactions being at least printing and/or hosting services (Watt: page 8, section 2.2, first paragraph).
Claim 9
Watt
The system of claim 1, wherein the permissions include at least one
permissions domain.
Watt shows at least the permission domain of users, roles, and groups (Watt: page 19, first paragraph, “Additional claims may be included in the Access Token, for example, roles and/or groups may be used to grant additional privileges to specific users …”).
Claim 14
Watt
The system of claim 1, wherein the permissions indication is a data structure indicating a subset of permissions held by the certificate issuer computer system.
Watt shows the broadest reasonable interpretation of an access token indicating a subset of permissions by showing any of the permissions (Watt: page 19, first paragraph, “Additional claims may be included in the Access Token, for example, roles and/or groups may be used to grant additional privileges to specific users …”).
Claim 15
Watt
The system of claim 1, wherein the permission indication indicates a delegation of full rights held by the issuer computer system.
Watt shows simply having the access token gives a party access (Watt: page 1, Abstract, “The popular OAuth 2.0 Framework specifies the use of Bearer Tokens for the transmission of authorization credentials. A Bearer Token has the property that any party in possession of it can use the it”) and not specifying rights specifically, therefore by default full rights (Watt: page 19, Listing 3).
Claim 16
Watt
The system of claim 15, wherein the permissions indication is the absence
of a permissions data structure.
Watt shows the absence of a permissions data structure (Watt: page 19, Listing 3).
Claims 11, 19, 25, 27, 29, 32-34, 37, 38
Watt
The limitations of claims 11, 19, 25, 27, 29, 32-34, 37, and 38 correspond to the limitations of claims 1, 7, 9, and 14-16.
The limitations of claims 11, 19, 25, 27, 29, 32-34, 37, and 38 are rejected in a corresponding manner to the limitations of claims 1, 7, 9, and 14-16.
Allowable Subject Matter
Claims 2-6, 8, 10-13, 17-18, 20-24, 26, 28, 30-31, and 35-36 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Patent Owner's arguments filed 05/11/2026 (herein Remarks) have been fully considered but they are not persuasive. The Remarks argue: (1) the claimed “permissions certificate data structure” is not shown by Watt (Remarks: page 12); (2) the claimed “initial permission request” is not shown by the cited prior art (Remarks: pages 12-13); and (3) Watt’s teachings do not show the claimed transmitting “a login request to a user computing system” (Remarks: page 13).
With regard to the first issue, the Remarks argue the recited “access token” of Watt is not a “permissions certificate data structure” of the claims. However, the arguments merely offer a description of differences between Watt and the invention, but do not address how the broadest reasonable interpretation of the actual claim language reads on Watt. As the rejections stated, Watt shows making a permissions certificate/token (Watt: pages 17-19, at least Access Token) including a requesting device identity (Watt: page 18, table 4, “aud” ; page 19, listing 3), an issuer identity (Watt: page 18, table 4, “iss”; page 19, listing 3), a permissions indication of the subset of the transaction (Watt: page 19, first paragraph, “Additional claims may be included in the Access Token, for example, roles and/or groups may be used to grant additional privileges to specific users …”), and an issuer private key signature (Watt: page 10, section 2.4, first paragraph; page 11, second paragraph; the message/certificate/token is protected by a digital signature which can be by using a private key from the issuer). The arguments don’t seem to point out what specific claim language is actually missing from the cited prior art. The Remark’s discussion of the PoP Token is not relevant to how the actual claim language reads upon the access token. As such, the argument is not persuasive.
With regard to the second issue, claim language does not require the “permission request” to include “a cryptographic public key associated with the requesting computing system” (that language has been amended out of the claims). Further, the addition of the word “initial” to the claimed “permissions request” does not significantly change the broadest reasonable interpretation of the claim language. First, for the purposes of the claim language, “initial” can be considered nothing more than a label. It does not significantly impart limit or provide description. Second, the claim language only requires one “permission request”, thus “initial” is relative to nothing. Third, based on the arguments, adding the word “initial” to the claims seems to be in terms relative to the cited prior art instead of the claim language. Based on the actual claim language of one permission request, the term reads upon an Authorization Request of Watt (see above rejections), regardless of what other permission requests may or may not be shown in the prior art. As such, this argument is not persuasive.
With regard to the third issue, the broadest reasonable interpretation of the claim language “transmit a login request to a user computing system” includes transmission of any sort in any manner, including redirect situations. The Remarks’ argument of “active” and “passive” are not found in the claim language and would not likely add distinction if they were. Both a device transmitting a payload via a second device and the second device are both actively transmitting the payload. Further, the Remarks state the Authorization Server “receives the redirected browser and presents a login page” (this is an indication of transmission from the server). As such, this argument is not persuasive.
The broadest reasonable interpretation of the actual claim language reads upon the cited prior art. The arguments presented offer no evidence of teaching away. For all the preceding reasons, the arguments presented by the Remarks are not persuasive.
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.
Correspondence Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM H WOOD whose telephone number is (571)272-3736. The examiner can normally be reached Monday-Friday 7am-3pm.
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, Alexander Kosowski can be reached at (571)272-3744. 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.
/William H. Wood/Reexamination Specialist, Art Unit 3992
Conferees:
/RACHNA S DESAI/Reexamination Specialist, Art Unit 3992
/ALEXANDER J KOSOWSKI/Supervisory Patent Examiner, Art Unit 3992
Prosecution Insights