DETAILED ACTION
Claims 1-20 are presented for examination.
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 .
Drawings
Figure 20 is objected to because it contains blurry and illegible words. A corrected replacement figure is required.
Claim objections
Claims 1, 9-10, 18 and 19 are objected to because they recite the acronym API without indicating what the acronym stands for.
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 § 2146 et seq. 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 filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of non-statutory double patenting as being unpatentable over the claims of the following U.S. Patents:
11615402, 10992679, 11736490, 11386223, 11409902, 11762535, 11935020,
11227064, 11062388, 11756114, 12050713, 12039077, 12198130, 12206674,
12182376, 12321490, 12333047, 12373884
Although the claims at issue are not identical, they are not patentably distinct
from each other because the claims of the current application are anticipated or
rendered obvious by the claims of the issued patents.
Claims 1-20 are provisionally rejected on the ground of non-statutory double
patenting as being unpatentable over the claims of the following co-pending Applications:
19/200543
19/241323
Although the claims at issue are not identical, they are not patentably distinct
from each other because the claims of the current application are anticipated or
rendered obvious by the claims of the co-pending applications.
This is a provisional nonstatutory double patenting rejection because the
patentably indistinct claims have not in fact been patented.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Hockey et al (US Pub.No.2017/0068954) based on its respective provisional applications dates of 9/8/2015 and 12/15/2015, in view of Eversoll et al (US Pub.No.2014/0143886).
Re Claim 1. Hockey teaches a method implemented by a service provider computing system comprising one or more processors, the method comprising: receiving, from a financial institution computing system of a financial institution, a security access token (i.e. In action 3, based on the user account data obtained from the external user account system 1206, the permissions management system 1204 generates an electronic record. The electronic record is generated by the permissions management system 1204 as described in further detail below, however, the electronic record may include at least a unique record name, an identifier associated with the user, an identifier associated with the external user-facing system/application 1208 (e.g., the client ID), user account information obtained from the external user account system 1206, and one or more permissions ……….. In action 4, the token is transmitted back to the external user-facing system/application 1208) [Hockey, para.0321-0324] granting access to account data of a user account (i.e. As described below, the authorization may include various limitations on access to the account ) [Hockey, para.0318] that is administered by the financial institution (i.e. Functions of the permissions management system (which are described in further detail below) include, but are not limited to: accessing and/or extracting user account data from external user account systems; initiating execution of, or executing, transactions via external user account systems;……… The external user account systems may comprise proprietary and external financial services (e.g., financial institution services, among others, as described above) [Hockey, para.192, 0203]; transmitting, to the financial institution computing system, an API request comprising the security access token and a request for the account data that is accessible to the service provider computing system based on the access granted by the security access token (i.e. in order to execute the transaction requested by the external user-facing system/application 1208, the trusted third-party processor system 1212 communicates with the permissions management system 1204 to obtain account details (e.g., account and routing numbers) of the user, and to get authorization to execute the transaction. Accordingly, the trusted third-party processor system 1212 communicates the token and transaction details to the permissions management system 1204) [Hockey, para.0326, 0046]; receiving, in response to the API request and from the financial institution computing system, the account data requested through the API request (i.e. If the permissions management system 1204 determines that the external user-facing system/application 1208 is authorized to execute the transaction, the permissions management system 1204 transmits to the trusted third-party processor system 1212 account details
(e.g., account and routing numbers) of the user necessary to execute the transaction, and an indication that the external user-facing system/application 1208 is authorized to execute the transaction) [Hockey, para.0328, 0046]; storing, in a non-volatile memory of the service provider computing system, the account data received from the financial institution computing system through the API request (i.e. the trusted third-party processor system 1212 ………….. stores the electronic record in the record vault 1302) [Hockey, para.0352];
Hockey does not explicitly disclose whereas Eversoll does: receiving, from a client application executing on a user device, a data request for the account data; transmitting, based at least in part on the data request from the client application, the account data that is stored in the non-volatile memory to the client application executing on the user device (i.e. Selecting any of these icons 134 will take the user to a view of the data visible by the particular vendor) [Eversoll, para.0100];
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Hockey with Eversoll because it provides a centralized and transparent clearinghouse for personal data through which a consumer may understand and control access to his or her personal data with respect to multiple third parties [Eversoll, para.0006] and it may be used to safeguard purchase information collected during retail transactions using electronic wallet systems that manage payment through the user's portable device such as a cell phone, or conventional credit card transactions [Eversoll, para.0110]. This motivation applies to the remainder of the claim.
Hockey further discloses: receiving, from the financial institution computing system, a scrub command (i.e. the user interface 2030 may indicate all accounts (or tokens) associated with a particular external user-facing system/application, and allow the user to de-authorize the external user-facing system/application by, for example, selection of button 2040) [Hockey, para.0399, 0357];
Hockey in view of Eversoll further discloses: a scrub command indicating the service provider computing system is to delete the account data; in response to receiving the scrub command, deleting, from the non-volatile memory of the service provider computing system, at least the account data received by the service provider computing system from the financial institution computing system through the API request (i.e. pressing of the revoke button 128 associated with these preferred elements will bring up a reminder text box 141 indicating what benefits will be lost if this sharing is revoked. After review of this reminder text box 141, the user may continue the revoking process) [Eversoll, para.0101], (i.e. personal data with revoke permission is equivalent to a state in which the personal data is in fact erased by the vendor) [Eversoll, para.0074]; and transmitting, to the financial institution computing system, an indication that the account data has been deleted from the service provider computing system (i.e. In all cases of revocation, the consumer 64 is provided with immediate feedback of the action, for example, by a change in the status displayed to the consumer or by e-mail or the like confirming the revocation) [Eversoll, para.0074].
Re Claim 2. Hockey in view of Eversoll discloses the method of claim 1, wherein the security access token comprises account data acquired from the user device (i.e. the electronic record may include at least a unique record name, an identifier associated with the user, an identifier associated with the external user-facing system/application 1208 (e.g., the client ID), user account information obtained from the external user account system 1206, and one or more permissions………………. the token (e.g., the unique record identifier) is generated based on an encrypted hash of one or more elements of the electronic record) [Hockey, para.0321-0322].
Re Claim 3. Hockey in view of Eversoll discloses the method of claim 1, wherein the security access token is linked to the client application executing on the user device (i.e. the application proxy instance management module 441 stores
the created application proxy instance in association with an account of the system 100 associated with an external user-facing systems/application, a user account of the external user-facing systems/application, and information identifying the external user account system (e.g., "Bank 1 141" of FIG. 4B) of the application proxy instance) [Hockey, para.0228, see also 0288].
Re Claim 4. Hockey in view of Eversoll discloses the method of claim 1, further comprising deactivating the security access token in response to receiving the scrub command (i.e. receiving an indication of a change to the one or more permissions, wherein the change to the one or more permission comprises a revocation of the electronic token; causing the third-party processor to further: update the electronic token to reflect the change to the one or more permissions) [Hockey, para.0091], (i.e. enabling revocation of permissions for, or de-authorization of, access to user accounts on the user account systems) [Hockey, para.0192].
Re Claim 5. Hockey in view of Eversoll discloses the method of claim 1, Eversoll teaches: further comprising providing, for presentation in a graphical interface of the client application, a second indication that the account data of the user account has been deleted from the service provider computing system (i.e. In all cases of revocation, the consumer 64 is provided with immediate feedback of the action, for example, by a change in the status displayed to the consumer) [Eversoll, para.0074].
The same motivation to modify with Eversoll, as in claim 1, applies.
Re Claim 6. Hockey in view of Eversoll discloses the method of claim 1, further comprising receiving, from the client application, following deletion of the account data, a second data request for the account data (i.e. receiving an indication of a change to the one or more permissions, wherein the change to the one or more permission comprises a revocation of the electronic token; causing the third-party processor to further: update the electronic token to reflect the change to the one or more permissions; receiving, from the external application: one or more transaction details related to a second transaction, and the unique token identifier; and causing the third-party processor to further: identify, based on the unique token identifier, the electronic token; compare the one or more transaction details associated with the second transaction with the one or more permissions; determine, based on the comparing of the transaction details associated with the second transaction with the one or more permissions, that the external application is not authorized to initiate the transaction due to the revocation of the electronic token) [Hockey, para.0091].
Re Claim 7. Hockey in view of Eversoll discloses the method of claim 6, further comprising transmitting, in response to receiving the data request from the client application, an indication that the second data request is declined (i.e. and communicate, to the external application, an indication that the external application is not authorized to initiate the transaction) [Hockey, para.0091].
Re Claim 8. Hockey in view of Eversoll discloses the method of claim 1, further comprising receiving, from the financial institution computing system, a second security access token granting limited access to a second user account that comprises second account data (i.e. In an implementation, there may be multiple electronic records associated with a single combination of a user and an external user-facing system/application. For example, the user may have multiple interactions (e.g., multiple accounts) with the external user-facing system/application, and may therefore desire multiple sets of permissions, or multiple user accounts (here referring to, e.g., financial accounts with external institutions) to be associated with the external user-facing system/application for different purposes. Examples of such multiple interactions may include a newsletter subscription (in which there may be multiple ongoing payments) and a one-off purchase of goods (in which there is a single purchase). Thus, two electronic records with varying levels of permission may be desired) [Hockey, para.0366].
Re Claim 9. Hockey in view of Eversoll discloses the method of claim 8, and as seen in the rejection of claim 7, Hockey discloses a second security access token granting access to a second user account; therefore in the same manner as in the rejection of similar features recited in claim 1 with respect to the security access token, Hockey discloses the following features with respect to the second security access token, i.e. Hockey discloses: further comprising: transmitting, to the financial institution computing system, a second API request comprising the second security access token and a second request for a portion of the second account data that is accessible according to the limited access granted by the second security access token; receiving, in response to the second API request and from the financial institution computing system, the portion of the second account data; and storing, in the non-volatile memory, the portion of the second account data received from the financial institution computing system.
Re Claims 10-18. These claims recite features similar to those in claims 1-9, respectively, therefore they are rejected in a similar manner.
Re Claims 19-20. These claims recite features similar to those in claims 1-2, respectively, therefore they are rejected in a similar manner.
Prior art made of record, however not relied upon includes:
Theurer et al (US Pub.No.2015/0026049) discloses embodiments that relate to systems (e.g., a permissions management system) and techniques for enabling a user to securely authorize a third-party system to initiate transactions related to an account, without disclosing to the third-party system the account credentials (e.g., an identity of the account). Such transactions may include, for example, initiating an electronic payment, or the like. Further, the systems and techniques of the present disclosure may enable the user to securely de-authorize the third-party system from initiating transactions related to the account [Theurer, para.0296].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NOURA ZOUBAIR whose telephone number is (571)270-7285. The examiner can normally be reached Monday - 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, ALI SHAYANFAR can be reached at 571-270-1050. 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.
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Prosecution Insights