DETAILED ACTION
Claims 1-20 are presented for examination on the merits.
Notice of Pre-AIA or AIA Status
The present application is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 08/26/2025 has been considered. The submission is in compliance with the provisions of 37 CFR 1.97. Form PTO-1449 is signed and attached hereto.
Drawings
The drawings filed on 10/17/2024 are accepted by the examiner.
Priority
The application is filed on 03/28/2024 and has priority of provisional
application 63/544,668 filed on 10/18/2023.
Claim Rejections - 35 USC § 112
1. 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 rationale which the applicant regards as his invention.
2. Independent claims 1, 9, and 13 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 applicant regards as the invention suggests.
Independent claims 1, 9, and 13 recite “ a request to generate an access token, wherein: the request includes a demonstration of proof of possession (DPoP) token, the DPoP token includes a public key, a payload and a signature, and the payload includes at least one selected from the group of fingerprint data of the user device and a unique identifier of a contactless card associated with a user of the user device; extracting, by the server, the DPoP token from the request to generate an access token; verifying, by the server, the signature using the public key included in the DPoP token; authenticating, by the server, the payload; generating, by the server, an access token; binding, by the server, the public key to the access token; and transmitting, by the server, the access token to the user device...(Claim 1)” where the limitations “.. the DPoP token from the request to generate an access token” and “generating, by the server, an access token” lack antecedent basis in the claim and thus, renders the claim vague and indefinite. It is not clear to which token the limitation “the access token” refers in the following claim language. The claims are examined as best understood at this time.
Appropriate corrections are required to claims 1, 9, and 13, which recite same limitations.
Claim Objections
3. Independent claims 1, 9, and 13 recite “the payload includes at least one selected from the group of fingerprint data of the user device” where the limitations “the group of fingerprint data” lacks antecedent basis in the claim. The Examiner suggests
replacing the limitation with “selected from a group consisting of…”. The claims are examined as best understood at this time.
Appropriate corrections are required to claims 1, 9, and 13, which recite same limitations.
Claim Rejections - 35 USC § 103
4. 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.
5. 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.
6. 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.
7. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
8. Claims 1-17 are rejected under 35 U.S.C. 103 as being unpatentable over Zilbershtein et al. (US 20220417241 A1, hereinafter, Zilbershtein) in view of Mossler et al. (US 10541995 B1, hereinafter, Mossler).
Regarding claim 1, Zilbershtein discloses an authorization and authentication method (Para 0017: system with enhanced authentication and authorization process), comprising:
receiving, by a server from a user device, a request to generate an access token (Para 0039, 0042: client device 250 includes a media player 203, wherein media player 203 requests token creation on the CDN 206; Para 0052: the client device requests access to resource servers ….authorization proof token header that includes a thumbprint and/or hash of the client public key and attaches the authorization token to a request to resource servers such as CDNs),
wherein: the request includes a demonstration of proof of possession (DPoP) token (Para 0029, 0032: request includes proof of possession token when requesting the resources and/or services),
the DPoP token includes a public key, a payload and a signature (Para 0097: the proof token includes a header section, a payload section, and a signature ..with secret key…and a conformation of the client public key; Para 0052, 0091: proof token header includes a payload, a thumbprint and/or hash of the client public key), and
[the payload includes at least one selected from the group of fingerprint data of the user device and a unique identifier of a contactless card associated with a user of the user device];
extracting, by the server, the DPoP token from the request to generate an access token (Para 0025: upon validating the authorization proof token, the server sends access token to the client device 250 for access resources wherein CDN 206 provides media content to the media player 203, e.g., after validating access tokens and/or signatures attached to the proof of possession tokens);
verifying, by the server, the signature using the public key included in the DPoP token (Para 0069-0070: validating the signature of the tokens using public key; Para 0100; the security headend 205 uses the server public key of the security headend 205 to validate the signature of the client assertion object) and ;
authenticating, by the server, the payload (Para 0091-0092, 0052, 0097: CDN 206 server validates access token and the authorization proof token header wherein proof token header includes a payload, a signature , a thumbprint and/or hash of the client public key);
generating, by the server, an access token (Para 0034, 0087: server produces application access tokens (e.g., application authorization tokens) for accessing the particular resource and binds the authorization access token(s) to the client public key in the authorization proof token received);
binding, by the server, the public key to the access token (Para 0087, 0093-0094: resource server binds the authorization access token(s) to the client public key in the authorization proof token received); and
transmitting, by the server, the access token to the user device (Para 0025, 0035: upon validating the authorization proof token, sends access token and/or other information to the client device 250 for resource access).
Zilbershtein does not explicitly state but Mossler from the same or similar fields of endeavor teaches the payload includes at least one selected from the group of fingerprint data of the user device and a unique identifier of a contactless card associated with a user of the user device (Mossler, Col 1. Lines 23-30: ownership factors inherence factors relate to something the user is or does (e.g., fingerprint, retinal pattern, DNA sequence, signature, face, voice, unique bio-electric signals, or another biometric identifier); Col. 17, lines 16-21: authorization using fingerprint scan utilizes an authorizing device having fingerprint scan capability) and
a unique identifier of a contactless card associated with a user of the user device (Mossler, Col. 11, lines 27-33: customer information 450 comprises a unique alphanumeric identifier assigned to a user of the contactless card 400 and/or one or more keys that together may be used to distinguish the user of the contactless card from other contactless card users).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention wherein the payload includes at least one selected from the group of fingerprint data of the user device and a unique identifier of a contactless card associated with a user of the user device as taught by Mossler in the teachings of Zilbershtein for the advantage of registering a contactless card of a client with an application service and binding the contactless card to one or more client devices using username and dynamic password pair for security improvement (Mossler, Abstract).
Regarding claim 2, the combination of Zilbershtein and Mossler discloses the method according to claim 1, wherein the public key is associated with a private key generated by the user device (Zilbershtein, Abstract, Para 0035: the authorization proof token is signed with a client private key provisioned by the security headend 205 and verifiable by a client public key inside the authorization proof token wherein a client device obtains an authorization proof token generated based on a client public key, a client private key).
Regarding claim 3, the combination of Zilbershtein and Mossler discloses the method according to claim 2, wherein the signature is generated using the private key by the user device (Zilbershtein Para 0099-0100, Claim 14: generating a provisioning response includes signature corresponding to the client private key wherein the security headend 205 uses the client public key attached to the client assertion object to validate the signature).
Regarding claim 4, the combination of Zilbershtein and Mossler discloses the method according to claim 1, wherein the fingerprint data of the user device (Zilbershtein Para 0052, 0057: proof token header includes a payload, a thumbprint..)
include at least one selected from a group consisting of a web browser setting of the user device, a processor type of the user device, an internet protocol (IP) address of the user device, and existing cookies stored on the user device (Zilbershtein Para 0023, 0058, 0090: observing tokens in open platforms such as a browser used for running a web application on client device … corresponds to other information including identifiers, the unique code ID, and/or the expiration time in cookies wherein accessing media from the CDN 2 includes changing manifest URL to point to a local host IP address).
Regarding claim 5, the combination of Zilbershtein and Mossler discloses the method according to claim 1, wherein the payload further includes an identifier of the user of the user device (Zilbershtein Para 0052, 0057: proof token header includes a payload, a thumbprint and/or hash of the client public key wherein the one or more identifiers can include a user identifier (ID or UID), which is an ID that uniquely identifies the subscriber, user, and/or account in the subscriber, user, and/or account management system on the secure control plane 204.; Para 0107, 0056-0057, 0062: client device associate with a security configuration wherein credentials possessed by the user includes biometric information corresponds to a unique identifier used in the identification of a client device, e.g., an endpoint unique identifier (EUID));
Regarding claim 6, the combination of Zilbershtein and Mossler discloses the method according to claim 5, wherein the identifier of the user includes an email address of the user (Zilbershtein Para 0055: secure control plane validates the login and identify the user in step 2. A client is authenticated to the secure control plane 204 using any identity verification techniques, such as using credentials possessed by the user (e.g., a user name and a password and/or biometric information), sending a text code to a phone the user operating the client device, and/or using a third-party identity provider, an email address for example)
Regarding claim 7, the combination of Zilbershtein and Mossler discloses the method according to claim 1, wherein the server comprises an authentication server and an authorization server (Zilbershtein, Para 0026, 0020: different authentication and/or authorization servers e.g., server 1 215-1, server 2 215-2, and/or server 3 215-3 are distinct, separate).
Regarding claim 8, the combination of Zilbershtein and Mossler discloses the method according to claim 7, wherein authenticating the payload is performed by the authentication server (Zilbershtein Para 0042, 0052, 0097: security engine 202 adds an authorization proof token header including a payload for validation performed by resource servers such as CDNs; Para 0047: authentication server authenticates credentials provided by a client).
Regarding claim 9; Claim 9 is similar in scope to claim 1, and is therefore rejected under similar rationale (Further, Para 0018: a provisioning method for server controlled client authorization proof of possession is performed at a first server (e.g., a security headend) that includes one or more processors and a non-transitory memory).
Regarding claim 10, the combination of Zilbershtein and Mossler discloses the system according to claim 9, wherein the server is configured to bind the fingerprint data of the user device to the access token (Zilbershtein Para 0045, 0052: the CDN 206 provides media content to the media player 203, e.g., after validating access tokens and/or signatures attached to the proof of possession tokens, etc. wherein a thumbprint of the client public key is presented and validated by CDN 206 to facilitate the session token production e.g. binding data with the client device).
Regarding claim 11, the combination of Zilbershtein and Mossler discloses the system according to claim 9, wherein the server is configured to bind the unique identifier of the contactless card to the access token (Zilbershtein Para 0052, 0097: proof token header includes a payload, a thumbprint and/or hash of the client public key; Para 0107, 0056-0057, 0062: client device associate with a security configuration wherein credentials possessed by the user includes biometric information corresponds to a unique identifier used in the identification of a client device, e.g., an endpoint unique identifier (EUID)).
Regarding claim 12, the combination of Zilbershtein and Mossler discloses the system according to claim 9, wherein the server is configured to bind both the fingerprint data of the user device and the unique identifier of the contactless card to the access token (Zilbershtein Para 0045, 0052: a thumbprint of the client public key is presented and validated by CDN 206 to facilitate the session token production e.g. binding a thumbprint corresponds to the client device with access token; Para 0107, 0056-0057, 0062: client device associate with a security configuration wherein credentials possessed by the user includes biometric information corresponds to a unique identifier used in the identification of a client device, e.g., an endpoint unique identifier (EUID)).
Regarding claim 13; Claim 13 is similar in scope to claim 1, and is therefore rejected under similar rationale (Further, Para 0112, 0018: a provisioning method for server controlled client authorization proof of possession is performed at a first server (e.g., a security headend) that includes one or more processors and a non-transitory memory).
Regarding claim 14, the combination of Zilbershtein and Mossler discloses the non-transitory, computer-readable medium according to claim 13, wherein the actions further comprises receiving a request of accessing a resource data store (Zilbershtein Para 0052: the client device requests access to resource servers ….authorization proof token header that includes a thumbprint and/or hash of the client public key and attaches the authorization token to a request to resource servers such as CDNs),
the request of accessing the resource data store including a second DPoP token and the access token (Zilbershtein Para 0025: upon validating the authorization proof token, the server sends token to the client device 250 for access resources wherein CDN 206 provides media content to the media player 203, e.g., after validating access tokens and/or signatures attached to the proof of possession tokens).
Regarding claim 15, the combination of Zilbershtein and Mossler discloses the non-transitory, computer-readable medium according to claim 14, wherein the second DPoP token includes a second public key, a second payload and a second signature (Zilbershtein Para 0097: the proof token includes a header section, a payload section, and a signature ..with secret key…and a conformation of the client public key; Para 0052, 0091: proof token header includes a payload, a thumbprint and/or hash of the client public key); and
the actions further comprise: extracting the access token and the second DPoP token from the request of accessing a resource data store (Zilbershtein Para 0025: upon validating the authorization proof token, the server sends token to the client device 250 for access resources wherein CDN 206 provides media content to the media player 203, e.g., after validating access tokens and/or signatures attached to the proof of possession tokens),
verifying the second signature using the second public key (Zilbershtein Para 0069-0070: validating the signature of the tokens using public key; Para 0100; the security headend 205 uses the server public key of the security headend 205 to validate the inner signature of the client assertion object),
checking whether the second public key matches the public key bounded to the access token (Zilbershtein Para 0082: secure control plane 204 validates that the client public key (or a client public key thumbprint or hash) in the assertion object matches the client public key provided by the security engine 202; Para 0071: the hash value of a standard public key associated with the client and presents in the SDPoP token as well as in the CDN access and/or session token); and
in response that the second public key matches the public key bounded to the access token, authorizing an access to the resource data store (Zilbershtein Para 0071: value is the hash of a standard public key associated with the client and presents in the SDPoP token as well as in the CDN access and/or session token. This allows the control plane to generate a CDN access token).
Regarding claim 16, the combination of Zilbershtein and Mossler discloses the non-transitory, computer-readable medium according to claim 15, wherein the actions further comprises authenticating the second payload (Zilbershtein Para 0091-0092, 0052, 0097: CDN 206 server validates access token and the authorization proof token header wherein proof token header includes a payload, a signature , a thumbprint and/or hash of the client public key)
Regarding claim 17, the combination of Zilbershtein and Mossler discloses the non-transitory, computer-readable medium according to claim 16, wherein the second payload include fingerprint data of a second user device and/or a unique identifier of a second contactless card (Zilbershtein Para 0052, 0097: proof token header includes a payload, a thumbprint and/or hash of the client public key; Para 0107, 0056-0057, 0062: client device associate with a security configuration wherein credentials possessed by the user includes biometric information corresponds to a unique identifier used in the identification of a client device, e.g., an endpoint unique identifier (EUID)).
Allowable Subject Matter
9. Claims 18-20 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.
Reasons for Allowance
10. The following is an examiner’s statement of reasons for placing claims 18-20 under allowable subject matters:
The limitation of dependent claims 18-20 are allowed and the corresponding dependent claims including respective and any intervening claims are not disclosed by the any of the prior art of record. For example, the limitations in claim 18 including the intervening claims recites “..authenticating the second payload comprises comparing the fingerprint data of the second user device with the fingerprint data of the user device” which are not are not taught or fairly suggested by the prior art of record.
The allowable subject matters in above dependent claims are novel and non-obvious in scope over the prior art of record as the prior-art references fail to teach each and every features of the aforesaid dependent claim(s) including the limitations set forth above.
In view of the foregoing, the scope of claimed subject matters renders the invention patentably distinct as none of the prior art of record, either taken by itself or in any combination, would have anticipated or made obvious the invention of the present application at or before the time it was filed.
Furthermore, the Examiner performed updated search which does not yield other specific references that reasonably, either alone or in combination, would result a proper rejection of all the claimed features presented in each of the dependent claims 18-20 under 35 U.S.C 102 or 35 U.S.C.103 with proper motivation.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled "Comments on Statement of Reasons for Allowance."
Conclusion
11. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Han et al. (US 10366378 B1) discloses method for detecting at least one transaction activity associated with a payment system, establishing a communication channel between the POS terminal an RF communication device in proximity to the POS terminal to obtain at least one device characteristic of the communication device, related to the operational or physical features of the communication device; generating a digital fingerprint based in part on the obtained device characteristic and the information related to received payment object.
Dua et al. (US 20140297438 A1) discloses methodology for conducting financial and other transactions using a wireless device. Credentials may be selectively issued by issuers such as credit card companies, banks, and merchants to consumers permitting the specific consumer to conduct a transaction according to the authorization given as reflected by the credential or set of credentials.
12. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAHFUZUR RAHMAN whose telephone number is (571)270-7638. The examiner can normally be reached on Monday thru Friday.
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, Yin-Chen Shaw can be reached on 571-272-8878. 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.
/MAHFUZUR RAHMAN/Primary Examiner, Art Unit 2498
Prosecution Insights