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 .
DETAILED ACTION
1. 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 2 February 2026 has been entered.
2. Claims 2, 3, 6, 7, 9, 10, 12, 13, and 16-19 have been amended.
3. Claims 1-20 remain pending and rejected.
Claim Rejections - 35 USC § 103
4. 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.
Claims 1-20 are rejected under 35 U.S.C §103 as being unpatentable over Hockey et al. (US Publication No. 20190318122), hereinafter Hockey and in view of William et al. (US Publication No. 20210081947), hereinafter William.
Regarding claim 1:
generating a token for a data recipient (Hockey, ¶58, abstract), But Hockey does not explicitly suggest, wherein the token comprises a payload portion; however, in a same field of endeavor William discloses this limitation (William, ¶68, ¶69), wherein generated token inherently embedded in API request/payload.
embedding within the payload portion of the token a data directive associated with a data provider (William, ¶100, ¶70).
wherein the data directive comprises an indication of one or more accounts of the data provider the data recipient is granted access to or an indication of one or more fields of data the data recipient is granted access to (William, ¶124):
transmitting the token to the data recipient (Hockey, ¶447, 648).
receiving the token, and a request for user information, from the data recipient (Hockey, ¶158-159).
Hockey does not explicitly suggest, performing, based on the data directive embedded in the payload portion of the token, filtering of user information data received from the data provider; however, in a same field of endeavor William discloses this limitation (William, ¶215).
transmitting the filtered user information data to the data recipient (Hockey, ¶297, 338).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of data specific token generation of Hockey with the embedded payload token disclosed in William to enhance the security of granting access to the account, stated by William at ¶45.
Regarding claim 2:
wherein the data directive comprises each of the indication of which accounts of the data provider the data recipient is granted access to or an indication of which fields of data the data recipient is granted access to (Hockey, ¶149-150).
Regarding claim 3:
wherein the token authorizes the data recipient to receive data, and wherein the data directive comprises an indication of which of the one or more fields of data, of the user information of the data provider, that the data recipient is permitted to access (Hockey, ¶595, 217), and Hockey does not explicitly suggest, comprises a payload portion in which the data directive is embedded; however, in a same field of endeavor William discloses this limitation (William, ¶100, ¶70).
Same motivation for combining the respective features of Hockey and William applies herein, as discussed in the rejection of claim 1.
Regarding claim 4:
wherein: the token is generated by an intermediary entity (Hockey, ¶148).
the data directive is not maintained in a database associated with the intermediary entity (Hockey, ¶81).
and the filtering performed by the intermediary entity based on the data directive embedded in the token is performed without referencing another data source (Hockey, ¶64).
Regarding claim 5:
wherein the transmitting the filtered user information data to the data recipient comprises embedding the filtered user information data in the token and transmitting the token to the data recipient (Hockey, ¶376).
Regarding claim 6:
wherein embedding within the token the data directive associated with the data provider comprises: encrypting the data directive (Hockey, ¶81) and embedding the encrypted data directive within the token, the method further comprising, after receiving the token and the request for user information data, decrypting the data directive (Hockey, ¶194).
Regarding claim 7:
wherein the token is a data recipient token, the method further comprising: receiving, from the data provider, a data provider token which enables access to user information data associated with the data provider (Hockey, ¶68-69).
embedding the data provider token within the data recipient token (Hockey, ¶127, 176) and after receiving the data recipient token, and the request for user information, from the data recipient, extracting the data provider token and using the data provider token to obtain the user information data (Hockey, ¶69).
Regarding claim 8:
wherein: embedding the data provider token within the data recipient token comprises: encrypting the data provider token (Hockey, ¶341) and embedding the encrypted data provider token within the data recipient token; and (Hockey, ¶521, 127), extracting the data provider token comprises decrypting the data provider token embedded within the data recipient token (Hockey, ¶194, 469).
Regarding claim 9:
further comprising: after receiving the token, and the request for user information, from the data recipient, validating the token using a cryptographic operation (Hockey, ¶58, 177).
Regarding claim 10:
further comprising: receiving input to modify which of the one or more accounts of the data provider the data recipient is granted access to; generating a new token in which an indication of the modification is embedded; and transmitting the new token to the data recipient (Hockey, ¶310).
Regarding claim 11:
communication circuitry (Hockey, ¶426); and processing circuitry coupled to the communication circuitry and configured to: (Hockey, ¶578).
generate a token for a data recipient (Hockey, ¶58, abstract), But Hockey does not explicitly suggest, wherein the token comprises a payload portion; however, in a same field of endeavor William discloses this limitation (William, ¶68, ¶69), wherein generated token inherently embedded in API request/payload embed within the payload portion of the token a data directive associated with a data provider (Wang, ¶41-42).
wherein the data directive comprises an indication of one or more accounts of the data provider the data recipient is granted access to or an indication of one or more fields of data the data recipient is granted access to:
transmit, using the communication circuitry, the token to the data recipient (Hockey, ¶447, 648).
receive, using the communication circuitry, the token, and a request for user information, from the data recipient (Hockey, ¶158-159).
Hockey does not explicitly suggest, perform, based on the data directive embedded in the payload portion of the token, filtering of user information data received from the data provider; however, in a same field of endeavor William discloses this limitation (William, ¶215).
transmit, using the communication circuitry, the filtered user information data to the data recipient (Hockey, ¶297, 338).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of data specific token generation of Hockey with the embedded payload token disclosed in William to enhance the security of granting access to the account, stated by William at ¶45.
Regarding claim 12:
wherein the data directive comprises each of the indication of the one or more accounts of the data provider the data recipient is granted access to and the indication of the one or more fields of data the data recipient is granted access to (Hockey, ¶149-150).
Regarding claim 13:
wherein the token authorizes the data recipient to receive data, and wherein the data directive comprises an indication of which of the one or more fields of data, of the user information of the data provider, that the data recipient is permitted to access (Hockey, ¶595, 217), and comprises a payload portion in which the data directive is embedded (Wang, ¶60).
Same motivation for combining the respective features of Hockey and William applies herein, as discussed in the rejection of claim 1.
Regarding claim 14:
wherein: the processing circuitry configured to generate the token is associated with an intermediary entity (Hockey, ¶148).
the data directive is not maintained in a database associated with the intermediary entity (Hockey, ¶81).
and the processing circuitry is configured to perform the filtering based on the data directive embedded in the token without referencing another data source (Hockey, ¶64).
Regarding claim 15:
wherein the processing circuitry is configured to transmit the filtered user information data to the data recipient by embedding the filtered user information data in the token and transmitting the token to the data recipient (Hockey, ¶376).
Regarding claim 16:
wherein the processing circuitry is configured to: embed within the token the data directive associated with the data provider by: encrypting the data directive; and embedding the encrypted data directive within the token; and after receiving the token and the request for user information, decrypt the data directive (Hockey, ¶194, abstract).
Regarding claim 17:
wherein the token is a data recipient token, and the processing circuitry is further configured to: receive, from the data provider, a data provider token which enables access to user information data associated with the data provider (Hockey, ¶68-69).
embed the data provider token within the data recipient token; and (Hockey, ¶341).
after receiving the data recipient token, and the request for user information, from the data recipient, extract the data provider token and use the data provider token to obtain the user information data (Hockey, ¶69).
Regarding claim 18:
wherein the processing circuitry is configured to embed the data provider token within the data recipient token by: encrypting the data provider token; and (Hockey, ¶81).
embedding the encrypted data provider token within the data recipient token; and
processor circuitry configured to extract the data provider token by decrypting the data provider token embedded within the data recipient token (Hockey, ¶194).
Regarding claim 19:
wherein the processing circuitry is further configured to: receive input to modify which of the one or more accounts of the data provider the data recipient is granted access to; generate a new token in which an indication of the modification is embedded; and transmit the new token to the data recipient (Hockey, ¶310, abstract).
Regarding claim 20:
receiving, at a data recipient and from an intermediary entity, a token comprising an embedded data directive associated with a data provider (Hockey, ¶58, 66), But Hockey does not explicitly suggest, wherein the data directive is embedded within a payload portion of the token, however, in a same field of endeavor Wang discloses this limitation (William, ¶68, ¶69), wherein generated token inherently embedded in API request/payload.
wherein the data directive comprises an indication of one or more accounts of the data provider the data recipient is granted access to or an indication of one or more fields of data the data recipient is granted access to (William, ¶124):
storing, by the data recipient, the received token (Hockey, ¶163).
transmitting the token comprising the embedded data directive, and a request for user information, to the intermediary entity; and (Hockey, ¶447, 468).
receiving, at the data recipient and from the intermediary entity, user information data, wherein the user information data is received by the intermediary entity from the data provider (Hockey, ¶158-159).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of data specific token generation of Hockey with the embedded payload token disclosed in William to enhance the security of granting access to the account, stated by William at ¶45.
Conclusion
5. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Monjour Rahim whose telephone number is (571)270-3890.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shewaye Gelagay can be reached on 571-272-4219. 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 CANANDA) or 571-272-1000.
/Monjur Rahim/
Patent Examiner
United States Patent and Trademark Office
Art Unit: 2436; Phone: 571.270.3890
E-mail: monjur.rahim@uspto.gov
Fax: 571.270.4890