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 .
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 §§ 706.02(l)(1) - 706.02(l)(3) 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.
Claims 1,7,12-13,18 and 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1,3,12-13,17 and 21 of U.S. Patent No. 12,407,511. Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1,3,12-13,17 and 21 of U.S. Patent No. 12,407,511 include all the limitations of claims 1,7,12-13,18 and 20 of the instant application.
Claims 1,3,12-13,17 and 21 of U.S. Patent No. 12,407,511
as shown in the table below contains every element of claim(s) Claims 1,7,12-13,18 and 20 of the instant application and as such anticipates claim(s) Claims 1,7,12-13,18 and 20 of the instant application.
Instant application 19/267,597
Patent US: 12,407,511
An apparatus, comprising:
a communications interface;
a memory storing instructions; and
at least one processor coupled to the communications interface and the memory, the at least one processor being configured to execute the instructions to:
receive, from a device via the communications interface, consent data associated with a data element accessible to an application program executed by the device, the consent document comprising an application identifier of the application program;
generate or modify at least a portion of a consent document for the application program based on the consent data, and
generate a consent hash value representative of the consent document;
obtain an access token associated with the application program from the memory based on at least the application identifier; and
transmit, to the device via the communications interface, the access token and permissioning data that includes at least the consent hash value, the permissioning data comprising information that instructs the application program to store the access token and the consent hash value within a local memory of the device and to associate the consent hash value and the access token within the local memory.
7. The apparatus of claim 6, wherein:the access token comprises an OAuth token;the at least one processor is further configured to execute the instructions to store the OAuth token, the consent document, the consent hash value, and the application identifier within the portion of the memory.
12. A computer-implemented method, comprising:receiving, from a device using at least one processor, consent data associated with a data element accessible to an application program executed by the device, the consent data comprising an application identifier of the application program;using the at least one processor, generating or modifying at least a portion of a consent document for the application program based on the consent data, and generating a consent hash value representative of the consent document using the at least one processor; obtaining, using the at least one processor, an access token associated with the application program based on at least the application identifier; and transmitting, to the device using the at least one processor, the access token and permissioning data that includes at least the consent hash value, the permissioning data comprising information that instructs the application program to store the access token and the consent hash value within a local memory of the device and to associate the consent hash value and the access token within the local memory.
13. An apparatus, comprising:a communications interface;a memory storing instructions; andat least one processor coupled to the communications interface and to the memory, the at least one processor being configured to execute the instructions to:receive, via the communications interface, a request for an element of data from a device, the request comprising a first consent hash value, a first access token, and an application identifier of an application program executed at the device;based on the application identifier, obtain, from a portion of the memory, a consent document associated with the application program, a second consent hash value representative of the consent document, and a second access token associated with the application program; based on a determination that the first consent hash value corresponds to the second consent hash value, and based on a determination that the first access token is consistent with the second access token, establish that element of data element is accessible to the application program based on the consent document;and obtain and encrypt the data element, transmit the encrypted data element to the device via the communications interface.
18. The apparatus of claim 13, wherein the at least one processor is further configured to execute the instructions to:load the data element from the memory based on the determination that the that the first consent hash value corresponds to the second consent hash value, based on the determined consistency between the first access token and the second access token, and based on the determination that the data element is accessible to the application program;encrypt the data element using a public cryptographic key associated with the application program; andtransmit, via the communications interface, the encrypted data element to the device through a programmatic interface associated with the application program.
19. The apparatus of claim 13, wherein the at least one processor is further configured to execute the instructions to:determine an inconsistency between the first consent hash value and the second consent hash value; and based on the determined inconsistency, perform operations that at least one of invalidate the second access token or transmit, via the communications interface, a message indicating the determined inconsistency to the device via a programmatic interface associated with the application program.
20. The apparatus of claim 13, wherein the at least one processor is further configured to execute the instructions to:receive consent data from the device via the communications interface, the consent data identifying one or more additional data elements accessible to a third-party application program executed by the device, the consent data comprising an additional identifier associated with the third-party application program;generate a third-party consent document for the third-party application program based on at least a portion of the consent data and compute a third-party consent hash value representative of the third-party consent document; and obtain a third-party access token associated with the third-party application program based on at least the additional identifier, and transmit, via the communications interface, the third-party access token and permissioning data that includes the third-party consent hash value to the device, the permissioning data comprising information that instructs the third-party application program to store the third-party access token and the third-party consent hash value within a local memory of the device and to associate the third-party consent hash value and the third-party access token within the local memory.
1. An apparatus, comprising: a communications interface;
a memory storing instructions; and
at least one processor coupled to the communications interface and the memory, the at least one processor being configured to execute the instructions to: receive, via the communications interface, consent data from a device, the consent data comprising an identifier of at least one of a data class or data type, information indicating an accessibility of one or more elements of data associated with the at least one of the data class or data type to an application program that is executed by the device and indicating a permission of the application program to perform one or more operations on the one or more elements of data, data identifiers of the one or more elements of data associated with at least one of the data class or data type, and an application identifier of the application program;
generate a consent document for the application program based on at least a portion of the consent data;
generate a consent hash value representative of the consent document,
the consent document comprising status data that confirms an accessibility of corresponding ones of the one or more elements of data associated with the at least one data class or data type to the application program, and that confirms the permission of the of the application program to perform the one or more operations on the one or more elements of data;
obtain an access token of the application program and the consent document from a portion of the memory based on at least the application identifier; and
transmit, to the device via the communications interface, the access token and permissioning data that includes at least the consent hash value, the permissioning data comprising information that instructs the application program to store the access token and the consent hash value within a local memory of the device and to associate the consent hash value and the access token within the local memory.
3. The apparatus of claim 1, wherein: the access token comprises an OAuth token; the at least one processor is further configured to execute the instructions to store the OAuth token, the consent document, the consent hash value, and the application identifier of the application program within the portion of the memory.
12. A computer-implemented method, comprising: receiving, using at least one processor, consent data from a device, the consent data comprising an identifier of at least one of a data class or data type, information indicating an accessibility of one or more elements of data associated with the at least one of the data class or data type to an application program that is executed by the device and indicating a permission of the application program to perform one or more operations on the one or more elements of data, data identifiers of the one or more elements of data associated with at least one of the data class or data type, and an application identifier of the application program; generating, using the at least one processor, a consent document for the application program based on at least a portion of the consent data; generating, using the at least one processor, a consent hash value representative of the consent document, the consent document comprising status data that confirms an accessibility of corresponding ones of the one or more elements of data associated with the at least one data class or data type to the application program and that confirms the permission of the of the application program to perform the one or more operations on the one or more elements of data; obtaining, using the at least one processor, an access token of the application program and the consent document from a portion of a memory based on at least the application identifier; and transmitting, using the at least one processor, the access token and permissioning data that includes at least the consent hash value to the device, the permissioning data comprising information that instructs the application program to store the access token and the consent hash value within a local memory of the device and to associate the consent hash value and the access token within the local memory.
13. An apparatus, comprising: a communications interface; a memory storing instructions; and at least one processor coupled to the communications interface and to the memory, the at least one processor being configured to execute the instructions to: receive, via the communications interface, a request for an element of data, the request being generated by an application program that is executed at a device, the data element is associated with the at least one of a data type or data class, and the request comprising a first consent hash value, a first access token, data identifiers of the data element associated with at least one of the data class or data type, and an application identifier of the application program; based on the application identifier, obtain a consent document, a second consent hash value representative of the consent document, and a second access token associated with the application program from a portion of the memory, the consent document comprising status data that confirms an accessibility of a plurality of data elements associated with the at least one of the data class or data type to the application program and that confirms a permission of the application program to perform one or more operations on the plurality of data elements; based on a determination that the first consent hash value corresponds to the second consent hash value, and based on an established consistency between the first access token and the second access token, determine that data element is accessible to the application program and that the application program is permitted to perform the one or more operations on the data element based on the consent document; and obtain the data element, encrypt the data element, and transmit the encrypted data element to the device via the communications interface.
17. The apparatus of claim 13, wherein the at least one processor is further configured to execute the instructions to load the data element from the memory the based on the established consistency between the first and second access tokens, based on the determination that the first consent hash value corresponds to the second consent hash value, and based on the determination that data element is accessible to the application program.
21. The apparatus of claim 13, wherein the at least one processor is further configured to execute the instructions to: receive consent data from the device via the communications interface, the consent data identifying one or more additional elements of data accessible to a third-party application program executed by the device, the consent data comprising an additional application identifier associated with the third-party application program; generate a third consent document for the third-party application program based on at least a portion of the consent data and compute a third consent hash value representative of the third consent document; and obtain a third access token associated with the third-party application program based on at least the additional application identifier, and transmit, via the communications interface, the third access token and permissioning data that includes the third consent hash value to the device, the permissioning data comprising information that instructs the third-party application program to store the third access token and the third consent hash value within a local memory of the device and to associate the third consent hash value and the third access token within the local memory.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 13-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
As per claim 13, Based on specification, par 0006 discloses that “ a second access token associated with the application program, based on a determination that the first access token is consistent with the second access token. The claim(s) contains subject matter which was not described in the specification how the second access token obtained and how it is generated by OAuth protocol. Therefore, this claim is not supported by the current disclosure.
Thus, all dependent claims are rejected based on the rational set forth in the claim 13.
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 13-20 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claim 13, this claim recites the limitations “ a first access token for a device , and “a second access token associated with the application program, Later on it recites the determination that the first access token is consistent with the second access token. The phrase “consistent” can be seen as the first access token can be acting, or made in the same way over time. That could be mean that the first access token is the same as the second access token. Is this a new access token? So, the boundary of the limitation is not clear. Thus, this claim is indefinite.
Thus, all dependent claims are rejected based on the rational set forth in the claim 13.
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) 1,4,5-6,8-9,11-15, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Jha et al US 10,425,465 in view of Constantine et al US 10,163,153.
As per claim 1, Jha an apparatus, comprising:
a communications interface ( col 2, lines 52-55 he local API proxy is a gateway/interface/application deployed in a service provider's environment that forwards API requests made by a client application (“client app”) )
a memory storing instructions (col 2, lines 17-19 processor configured to execute instructions stored on and/or provided by a memory coupled to the processor ); and
at least one processor coupled to the communications interface and the memory, the at least one processor being configured to execute the instructions to (col 2, lines 17-19 processor configured to execute instructions stored on and/or provided by a memory coupled to the processor ):
receive, from a device via the communications interface ( col 3, lines 24-26 The mobile application may make API, i..e communications interface, requests that are serviced by deployed API 104. col 18,lines 67-68 When an API request is At 902, a request for a token is received and ), data associated to an application program executed by the device (col 19, 7-11 The request for the token may include identification information, i.e. a data element, about the requestor such as a name, i.e. a data element/identifier of a client app , an API request or group of API requests, an organization name, an environment name, etc. and col 2, lines 54-55 API requests made by a client application (“client app”) to a deployed API, i..e data associated with a data element ), the document comprising an application identifier of the application program (col 19, lines 7-11 The request for the token may include identification information about the requestor such as a name , , of a client app , i.e. i.e. an application identifier , an API request or group of API requests, an organization name, an environment name);
generate or modify at least a portion of a token for the application program based on the data ( col 19, lines 20-23 At 904, the request is sent to a remote API management server. The remote API management server responds to the request by generating a token, , and signing the token with a secret and col 9, lines 66-67 API execution data (e.g., metadata), i.e. portion, includes what token was used to obtain access, latency, and characteristics of the API call. Wherein the metadata of the token can be seen as the portion of the document that is based on the API deployment data); and
obtain an access token associated with the application program from the memory based on at least the application identifier(col 19, lines 26-30, At 906, the signed token is received, i.e. obtain, from the remote API management server. The signed token may be transmitted by the remote API management server over a network and received by the local API proxy. An example process for generating the signed token is shown in FIG. 10.);
transmit, to the device via the communications interface, the access token and per missioning data that includes at least the consent hash value, the per missioning data comprising information that instructs the application program to store the access token ( col 19, lines 26-30 (108) At 908, the signed token is transmitted, i.e. transmit,. The signed token is transmitted to a client app and is usable by the client app in subsequent API requests. And col 19, lines 57-60 (111) At 1004, privileges, i.e. per missioning data, are determined and assigned to the token based on the request. Privileges define access permissions and parameters associated with the token. And col 20, lines 25-30 the token can be signed according to public key cryptography in which the token is hashed to produce a digest, i.e. the consent hash value and the digest is encrypted with the private key to produce a digital signature.) and
the consent hash value within a local memory of the device and to associate the consent hash value and the access token within the local memory (col 20, lines 35-40 At 1012, the signed token is provided. The signed token is transmitted to the local API proxy. In some embodiments, the local API proxy transmits the signed token to a client app that originally requested the token. The token is usable by the client app in subsequent API requests, that means the signed token , i.e. consent hash value, is stored in the client app, i.e. local memory, and col 21, lines 9-15 the local API proxy computes a hash of the token, decrypts the signature with the signer's public key, and compares the computed digest with the decrypted digest. If the digests match, then the token was unmodified since the time it was signed. It seems token consent hash value is stored in the local API proxy).
Jha does not disclose receive from a device consent data for the documents accessing to an application program (emphasis added);
Constantine discloses receive from a device consent data to an application program( referring now to FIG. 4, a consent form user interface 400 that may be used to provide consent for electronic disclosure delivery and col 3, lines 55-60 the application may provide the mobile device with a consent form regarding the disclosure documents, including a statement of his or her rights and obligations with respect to electronic delivery. The consent obtained via the form may be a one-time consent for a particular account rather than a global consent. col 10, lines 5-25 The electronic message may contain a network address for the application in the form of, for example, a hyperlink that may be selected by the customer using the mobile device in order to create and send a request for access to the application. The request may serve as an indication from the customer via the mobile device acknowledging that the customer has been given access to the disclosure documents. The request may contain, for example, a customer identifier associated with the account. The application may determine whether the mobile device has accessed the application by receiving the request for access to the application from the mobile device and verifying that it contains the customer identifier associated with the account. ).
Jha and Constantine are both considered to be analogous to the claimed invention because they are in the same field of API call for token.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jha to incorporate the teachings of Constantine and provide verification for the user to access the document.
Doing so would authentication for the application user device, thereby prevent unknown device to access the document.
As per claim 4. Jha and Constantine discloses the apparatus of claim 1, wherein:the consent data further comprises information that indicates a permission of the application program to perform one or more operations on the data element; and the consent document further comprises status data that confirms the permission of the application program to perform the one or more operations on the data element (Jha discloses col 19, lines 26-30 (108) At 908, the signed token is transmitted, i.e. transmit,. The signed token is transmitted to a client app and is usable by the client app in subsequent API requests. And col 19, lines 57-60 (111) At 1004, privileges, i.e. per missioning data, are determined and assigned to the token based on the request. Privileges define access permissions and parameters associated with the token. And col 20, lines 25-30 the token can be signed according to public key cryptography in which the token is hashed to produce a digest, i.e. the consent hash value and the digest is encrypted with the private key to produce a digital signature and Constantine discloses col 3, lines 60-67 The application may also provide a confirmation to the banker at the financial institution indicating that the mobile device has accessed the application, and that the customer has provided consent to receive delivery of disclosure documents in an electronic format. The application may also provide the mobile device with access to the electronic disclosure documents related to the account by further providing, for example, hyperlinks to network storage locations containing the disclosure documents that may be selected and viewed by the customer via the mobile device. The particular disclosure documents related to the account may be identified based on the customer identifier. The application may also establish the account for the customer based on the confirmation that the mobile device has accessed the application. The application may further store the confirmation that the mobile device has accessed the application, the confirmation that the mobile device has provided consent regarding electronic delivery of the disclosure documents, and the customer's unique messaging address in a memory location associated with the account based on the customer identifier. ).
As per claim 5. Jha and Constantine discloses The apparatus of claim 1, wherein the at least one processor is further configured to execute the instructions to transmit the access token and the permissioning data to the device through a programmatic interface associated with the application program (Jha discloses (Jha discloses col 19, lines 26-30 (108) At 908, the signed token is transmitted, i.e. transmit,. The signed token is transmitted to a client app and is usable by the client app in subsequent API requests. And col 19, lines 57-60 (111) At 1004, privileges, i.e. per missioning data, are determined and assigned to the token based on the request. Privileges define access permissions and parameters associated with the token.).
As per claim 6. Jha and Constantine discloses The apparatus of claim 1, Jha discloses wherein the at least one processor is further configured to execute the instructions to store the consent document, the consent hash value, and the application identifier within a portion of the memory (Jha discloses col 19, lines 26-30 (108) At 908, the signed token is transmitted, i.e. transmit,. The signed token is transmitted to a client app and is usable by the client app in subsequent API requests. And col 19, lines 57-60 (111) At 1004, privileges, i.e. per missioning data, are determined and assigned to the token based on the request. Privileges define access permissions and parameters associated with the token. And col 20, lines 25-30 the token can be signed according to public key cryptography in which the token is hashed to produce a digest, i.e. the consent hash value and the digest is encrypted with the private key to produce a digital signature ).
As per claim 8. Jha and Constantine discloses The apparatus of claim 1, wherein:the consent data identifies a requested modification to the accessibility of the data element to the application program; and the at least one processor is further configured to execute the instructions to modify at least the portion of the consent document in accordance with the consent data, the modified portion of the consent document reflecting the requested modification to the accessibility of the data element ( Constantine discloses col 7, lines 45-64 computer system 103 may receive a response 123 from mobile device 101 indicating that consent has been granted to receive disclosure materials in electronic format. Computer system 103 may also provide a confirmation message 124 to banker 104 indicating that mobile device 101 has provided consent to receive delivery of disclosure documents 108 in an electronic format. The consent confirmation may be based on, for example, a prior global consent to receive disclosure documents 108 in electronic format, or based on consent provided from mobile device 101 via consent form 122. Confirmation message 124 may include, for example, a date and time stamp corresponding to when consent was received and the manner in which consent was received, as well as the corresponding customer identifier and related account information. Computer system 103 may further store confirmation message 124 in a memory location associated with the particular financial product 106 based on the customer identifier such that the confirmation message is included with other account information for financial product 106).
As per claim 9. Jha and Constantine discloses The apparatus of claim 8, Jha discloses wherein the requested modification comprises at least one of (i) a modification to a level of access to the data element or (ii) a revocation of the access to the data element ( Jha discloses col 3, lines 50-67 By acting as an intermediary between client app 106 and deployed API 104, platform 102 is able to provide API management services including proxying and analytics. Platform 102 includes one or more proxies to forward API requests to deployed API 104. Platform 102 accommodates mechanisms for consuming services, analyzes API usage, implements security measures, and maintains these services such that they continue to function over time as services are added, modified, or deleted. For example, instead of accessing backend data/service 108 directly, client 106 makes an API request to platform 102, and the platform proxies the request to deployed API 104, which may access backend data/service 108 to respond to the API request. An API service platform deployed in a network cloud as shown in FIG. 1A is vulnerable to attacks that might occur in a transmission link between the network cloud and the service provider data center (e.g., deployed API 104 and/or backend data/service 108). Also, some service providers are not permitted to send data outside their data center or have third parties receive API requests due to security and/or compliance. ).
As per claim 11. Jha and Constantine discloses The apparatus of claim 1, wherein:the at least one processor is further configured to execute the instructions to generate the permissioning data based on at least a portion of the consent document, the permissioning data further comprises at least the portion of the consent document; and the information further instructs the application program to store the portion of the consent document and the consent hash value within the local memory of the device and to associate the portion of the consent document and the consent hash value with the access token of the application program (Jha discloses col 19, lines 26-30 (108) At 908, the signed token is transmitted, i.e. transmit,. The signed token is transmitted to a client app and is usable by the client app in subsequent API requests. And col 19, lines 57-60 (111) At 1004, privileges, i.e. per missioning data, are determined and assigned to the token based on the request. Privileges define access permissions and parameters associated with the token. And col 20, lines 25-30 the token can be signed according to public key cryptography in which the token is hashed to produce a digest, i.e. the consent hash value and the digest is encrypted with the private key to produce a digital signature and Constantine col 4, lines 30-50 the electronic disclosure delivery systems and methods described in the various exemplary embodiments may also allow the financial institution to easily obtain the customer's affirmative consent prior to providing any disclosure materials in electronic format. For example, the disclosed systems and methods may quickly check for prior global consent from a customer. If no prior global consent has been given, the customer may be instantly presented with an electronic consent form when accessing the disclosure documents, including a statement of his or her rights and obligations with respect to electronic delivery. Additionally, the electronic disclosure delivery systems and methods described in the various exemplary embodiments may allow the financial institution to easily establish an audit trail for the account such that delivery and consent regarding the disclosure documents may be demonstrated to a regulatory agency. For example, the disclosed systems and methods provide for storage of the confirmation that the mobile device has accessed the application and the confirmation that the mobile device has provided consent regarding electronic delivery of the disclosure documents in a memory location associated with the account based on the customer identifier. ).
As per claim 12. Jha discloses A computer-implemented method, comprising: receiving, from a device using at least one processor, data associated with a data element accessible to an application program executed by the device, the data comprising an application identifier of the application program (col 3, lines 24-26 The mobile application may make API, i..e communications interface, requests that are serviced by deployed API 104. col 18,lines 67-68 When an API request is At 902, a request for a token is received and col 19, 7-11 The request for the token may include identification information, i.e. a data element, about the requestor such as a name, i.e. a data element/identifier of a client app , an API request or group of API requests, an organization name, an environment name, etc. and col 2, lines 54-55 API requests made by a client application (“client app”) to a deployed API, i..e data associated with a data element and col 19, lines 7-11 The request for the token may include identification information about the requestor such as a name , , of a client app , i.e. i.e. an application identifier , an API request or group of API requests, an organization name, an environment name );
using the at least one processor, generating or modifying at least a portion of a consent document for the application program based on the consent data, and generating a consent hash value representative of the consent document using the at least one processor (col 19, lines 20-23 At 904, the request is sent to a remote API management server. The remote API management server responds to the request by generating a token, , and signing the token with a secret and col 9, lines 66-67 API execution data (e.g., metadata), i.e. portion, includes what token was used to obtain access, latency, and characteristics of the API call. Wherein the metadata of the token can be seen as the portion of the document that is based on the API deployment data);
obtaining, using the at least one processor, an access token associated with the application program based on at least the application identifier ( col 19, lines 26-30, At 906, the signed token is received, i.e. obtain, from the remote API management server. The signed token may be transmitted by the remote API management server over a network and received by the local API proxy. An example process for generating the signed token is shown in FIG. 10.); and
transmitting, to the device using the at least one processor, the access token and permissioning data that includes at least the consent hash value, the permissioning data comprising information that instructs the application program to store the access token and the consent hash value within a local memory of the device and to associate the consent hash value and the access token within the local memory (col 19, lines 26-30 (108) At 908, the signed token is transmitted, i.e. transmit,. The signed token is transmitted to a client app and is usable by the client app in subsequent API requests. And col 19, lines 57-60 (111) At 1004, privileges, i.e. per missioning data, are determined and assigned to the token based on the request. Privileges define access permissions and parameters associated with the token. And col 20, lines 25-30 the token can be signed according to public key cryptography in which the token is hashed to produce a digest, i.e. the consent hash value and the digest is encrypted with the private key to produce a digital signature and col 20, lines 35-40 At 1012, the signed token is provided. The signed token is transmitted to the local API proxy. In some embodiments, the local API proxy transmits the signed token to a client app that originally requested the token. The token is usable by the client app in subsequent API requests, that means the signed token , i.e. consent hash value, is stored in the client app, i.e. local memory, and col 21, lines 9-15 the local API proxy computes a hash of the token, decrypts the signature with the signer's public key, and compares the computed digest with the decrypted digest. If the digests match, then the token was unmodified since the time it was signed. It seems token consent hash value is stored in the local API proxy ).
Jha does not disclose receive from a device consent data for the documents accessing to an application program (emphasis added);
Constantine discloses receive from a device consent data to an application program( referring now to FIG. 4, a consent form user interface 400 that may be used to provide consent for electronic disclosure delivery and col 3, lines 55-60 the application may provide the mobile device with a consent form regarding the disclosure documents, including a statement of his or her rights and obligations with respect to electronic delivery. The consent obtained via the form may be a one-time consent for a particular account rather than a global consent. col 10, lines 5-25 The electronic message may contain a network address for the application in the form of, for example, a hyperlink that may be selected by the customer using the mobile device in order to create and send a request for access to the application. The request may serve as an indication from the customer via the mobile device acknowledging that the customer has been given access to the disclosure documents. The request may contain, for example, a customer identifier associated with the account. The application may determine whether the mobile device has accessed the application by receiving the request for access to the application from the mobile device and verifying that it contains the customer identifier associated with the account. ).
Jha and Constantine are both considered to be analogous to the claimed invention because they are in the same field of API call for token.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jha to incorporate the teachings of Constantine and provide verification for the user to access the document.
Doing so would authentication for the application user device, thereby prevent unknown device to access the document.
As per claim 13. Jha discloses An apparatus, comprising: a communications interface (col 2, lines 52-55 he local API proxy is a gateway/interface/application deployed in a service provider's environment that forwards API requests made by a client application (“client app”) );a memory storing instructions; and at least one processor coupled to the communications interface and to the memory (col 2, lines 17-19 processor configured to execute instructions stored on and/or provided by a memory coupled to the processor ); and
at least one processor coupled to the communications interface and the memory, the at least one processor being configured to execute the instructions to (col 2, lines 17-19 processor configured to execute instructions stored on and/or provided by a memory coupled to the processor ), the at least one processor being configured to execute the instructions to:
receive, via the communications interface, a request for an element of data from a device, the request comprising a first hash value, a first access token, and an application identifier of an application program executed at the device; based on the application identifier (col 3, lines 24-26 The mobile application may make API, i..e communications interface, requests that are serviced by deployed API 104. col 18,lines 67-68 When an API request is At 902, a request for a token is received and col 19, 7-11 The request for the token may include identification information, i.e. a data element, about the requestor such as a name, i.e. a data element/identifier of a client app , an API request or group of API requests, an organization name, an environment name, etc. and col 2, lines 54-55 API requests made by a client application (“client app”) to a deployed API, i..e data associated with a data element and col 19, lines 7-11 The request for the token may include identification information about the requestor such as a name , , of a client app , i.e. i.e. an application identifier , an API request or group of API requests, an organization name, an environment name and col 19, lines 20-23 At 904, the request is sent to a remote API management server. The remote API management server responds to the request by generating a token, , and signing the token with a secret and col 9, lines 66-67 API execution data (e.g., metadata), i.e. portion, includes what token was used to obtain access, latency, and characteristics of the API call. Wherein the metadata of the token can be seen as the portion of the document that is based on the API deployment data ),
obtain, from a portion of the memory, a consent document associated with the application program, a second hash value representative of the data, and a second access token associated with the application program (col 19, lines 26-30, At 906, the signed token is received, i.e. obtain, from the remote API management server. The signed token may be transmitted by the remote API management server over a network and received by the local API proxy. An example process for generating the signed token is shown in FIG. 10 ); based on a determination that the first data hash value corresponds to the second data hash value, and based on a determination that the first access token is consistent with the second access token ( interpreting same token ), establish that element of data element is accessible to the application program based on the data (col 19, lines 26-30 (108) At 908, the signed token is transmitted, i.e. transmit,. The signed token is transmitted to a client app and is usable by the client app in subsequent API requests. And col 19, lines 57-60 (111) At 1004, privileges, i.e. per missioning data, are determined and assigned to the token based on the request. Privileges define access permissions and parameters associated with the token. And col 20, lines 25-30 the token can be signed according to public key cryptography in which the token is hashed to produce a digest, i.e. the consent hash value and the digest is encrypted with the private key to produce a digital signature ); and obtain and encrypt the data element,
transmit the encrypted data element to the device via the communications interface (col 19, lines 26-30 (108) At 908, the signed token is transmitted, i.e. transmit,. The signed token is transmitted to a client app and is usable by the client app in subsequent API requests. And col 19, lines 57-60 (111) At 1004, privileges, i.e. per missioning data, are determined and assigned to the token based on the request. Privileges define access permissions and parameters associated with the token. And col 20, lines 25-30 the token can be signed according to public key cryptography in which the token is hashed to produce a digest, i.e. the consent hash value and the digest is encrypted with the private key to produce a digital signature and the consent hash value within a local memory of the device and to associate the consent hash value and the access token within the local memory (col 20, lines 35-40 At 1012, the signed token is provided. The signed token is transmitted to the local API proxy. In some embodiments, the local API proxy transmits the signed token to a client app that originally requested the token. The token is usable by the client app in subsequent API requests, that means the signed token , i.e. consent hash value, is stored in the client app, i.e. local memory, and col 21, lines 9-15 the local API proxy computes a hash of the token, decrypts the signature with the signer's public key, and compares the computed digest with the decrypted digest. If the digests match, then the token was unmodified since the time it was signed. It seems token consent hash value is stored in the local API proxy ).
Jha does not disclose receive from a device consent data for the documents accessing to an application program (emphasis added);
Constantine discloses receive from a device consent data to an application program( referring now to FIG. 4, a consent form user interface 400 that may be used to provide consent for electronic disclosure delivery and col 3, lines 55-60 the application may provide the mobile device with a consent form regarding the disclosure documents, including a statement of his or her rights and obligations with respect to electronic delivery. The consent obtained via the form may be a one-time consent for a particular account rather than a global consent. col 10, lines 5-25 The electronic message may contain a network address for the application in the form of, for example, a hyperlink that may be selected by the customer using the mobile device in order to create and send a request for access to the application. The request may serve as an indication from the customer via the mobile device acknowledging that the customer has been given access to the disclosure documents. The request may contain, for example, a customer identifier associated with the account. The application may determine whether the mobile device has accessed the application by receiving the request for access to the application from the mobile device and verifying that it contains the customer identifier associated with the account. ).
Jha and Constantine are both considered to be analogous to the claimed invention because they are in the same field of API call for token.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jha to incorporate the teachings of Constantine and provide verification for the user to access the document.
Doing so would authentication for the application user device, thereby prevent unknown device to access the document.
As per claim 14. Jha and Constantine discloses The apparatus of claim 13, wherein the request is generated by the application program executed at a device ( Jha discloses col 3, lines 24-26 the mobile device of the mobile application may make API, i..e communications interface, requests that are serviced by deployed API 104. col 18,lines 67-68 When an API request is At 902, a request for a token is received by the mobile ) .
As per claim 15. Jha and Constantine discloses the apparatus of claim 13, Constantine discloses wherein:the request comprises an identifier of the data element; the consent document comprises status data that confirms the accessibility of the data element to the application program; and the at least one processor is further configured to execute the instructions to establish that the data element is accessible to the application program based on the status data (Constantine discloses col 3, lines 60-67 The application may also provide a confirmation to the banker at the financial institution indicating that the mobile device has accessed the application, and that the customer has provided consent to receive delivery of disclosure documents in an electronic format. The application may also provide the mobile device with access to the electronic disclosure documents related to the account by further providing, for example, hyperlinks to network storage locations containing the disclosure documents that may be selected and viewed by the customer via the mobile device. The particular disclosure documents related to the account may be identified based on the customer identifier. The application may also establish the account for the customer based on the confirmation that the mobile device has accessed the application. The application may further store the confirmation that the mobile device has accessed the application, the confirmation that the mobile device has provided consent regarding electronic delivery of the disclosure documents, and the customer's unique messaging address in a memory location associated with the account based on the customer identifier. ).
As per claim 17. Jha and Constantine discloses The apparatus of claim 13, wherein: the request further comprises information that requests a performance of one or more operations on the data element by the application program; the consent document further comprises status data that confirms a permission of the application program to perform the one or more operations on the data element; and the at least one processor is further configured to execute the instructions to establish that the data element is accessible to the application program and that the application program is permitted to perform the one or more operations on the data element based on the status data (Constantine discloses col 7, lines 45-64 computer system 103 may receive a response 123 from mobile device 101 indicating that consent has been granted to receive disclosure materials in electronic format. Computer system 103 may also provide a confirmation message 124 to banker 104 indicating that mobile device 101 has provided consent to receive delivery of disclosure documents 108 in an electronic format. The consent confirmation may be based on, for example, a prior global consent to receive disclosure documents 108 in electronic format, or based on consent provided from mobile device 101 via consent form 122. Confirmation message 124 may include, for example, a date and time stamp corresponding to when consent was received and the manner in which consent was received, as well as the corresponding customer identifier and related account information. Computer system 103 may further store confirmation message 124 in a memory location associated with the particular financial product 106 based on the customer identifier such that the confirmation message is included with other account information for financial product 106 ).
Claim(s) 2-3 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Jha et al US 10,425,465 in view of Constantine et al US 10,163,153 in view of Cairns et al US 2015/0200948.
As per claim 2, Jha in view of Constantine discloses The apparatus of claim 1, Constantine discloses the consent document comprising status data that confirms the accessibility of the element of data to the application program (col 2, lines 19-23 providing a confirmation to a user at the financial institution indicating that the mobile device has accessed the application, and establishing the account for the customer based on the confirmation).
The combination does not explicitly disclose wherein: the consent data comprises an identifier of the data element;
However, Cairns discloses the consent data comprises an identifier of the data element(fig.2, 0029 The third-party application can then send the access token along with a document ID to the application programming interface (API) 240 for the web-based system 200 to gain access to the file data for the user resource.).
Jha and Constantine and Cairns are both considered to be analogous to the claimed invention because they are in the same field of API call for token. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jha to incorporate the teachings of Constantine, including the teaching of Cairns and provide document ID for the user to access the document. Doing so would authentication for the application user device, thereby prevent unknown device to access the document.
As per claim 3. Jha and Constantine and Cairns The apparatus of claim 2, Constantine discloses wherein: the consent data comprises an additional identifier of at least one of data type or a data class associated with the data element and information indicating the accessibility of the data element of data associated with the at least one of the data class or data type to the application program; and the status data further confirms the accessibility of the data element associated with the at least one of the data class or data type to the application program(col 2, lines 25-45 receiving input indicating whether a customer seeking to open an account at a financial institution has a mobile device, and sending an electronic message accessible by the mobile device. The electronic message contains a network address for an application. The application is configured to provide access to disclosure documents related to the account upon being accessed by the mobile device. The method further includes receiving a request from the mobile device to access the application. The request contains a customer identifier associated with the account. The method further includes determining whether the customer has provided consent regarding the documents, providing a confirmation to a user at the financial institution indicating that the customer has provided consent regarding the documents, providing a confirmation to the user indicating that the mobile device has accessed the application, providing access to the documents based on the customer identifier, and establishing the account for the customer based on the confirmation that the mobile device has accessed the application ).
As per claim 7. Jha in view of Constantine discloses The apparatus of claim 6, the combination does not explicitly disclose wherein:the access token comprises an OAuth token;the at least one processor is further configured to execute the instructions to store the OAuth token, the consent document, the consent hash value, and the application identifier within the portion of the memory.
However, Cairns discloses wherein:the access token comprises an OAuth token;the at least one processor is further configured to execute the instructions to store the OAuth token, the consent document, the consent hash value, and the application identifier within the portion of the memory ([0039] The security model in accordance with various implementations of this disclosure therefore provides four layers of protection. One layer of protection requires that a user-based access control list (ACL) 304, shown in FIG. 3, is checked to confirm that the user has access to the resource. Another layer of protection requires that an application installation record 320 is checked to see whether the user has installed the third-party application. Yet another layer of protection requires that the user must have authorized a token-grant server to provide an authorization access token, e.g., using OAuth 2.0 protocol, to the third-party application. The authorization access token 360 includes the user ID (from cookies on the user's device), the third-party application ID (retrieved from the application configuration database maintained on the web-based storage system), and the resource scope that is being granted. Still another layer of protection requires that application-specific lists are checked. The third-party application must be on a user-specific list (per-user metadata 330), indicating that a particular user has used that application to access a particular resource or file, and on an item-specific list (item metadata 340), indicating that the application has been used by any user to access that particular resource or file.).
Jha and Constantine and Cairns are both considered to be analogous to the claimed invention because they are in the same field of API call for token. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jha to incorporate the teachings of Constantine, including the teaching of Cairns and provide document ID for the user to access the document. Doing so would authentication for the application user device, thereby prevent unknown device to access the document.
Allowable Subject Matter
Claims 10, 16,18-20 are would be allowable if rewritten or amended to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, and Double patenting set forth in this Office action.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm.
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, JORGE ORTIZ CRIADO can be reached at 571-272-7624. 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.
/ABU S SHOLEMAN/Primary Examiner, Art Unit 2496
Prosecution Insights