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 includes words that are blurry. Corrected figures are required.
Specification
The abstract is objected to because it contains legal phraseology such as the word “comprising” on line 3.
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 nonstatutory 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 nonstatutory double patenting as being unpatentable over the claims of the following copending Applications
19/207036
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 § 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.
Claims 2-4, 12-14 and 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. Claims 2, 12 and 20 recite that a received token grants access to a user account, however the specification only describes a token that provides access to data of a user account, there is no support in the specification for a token that provides access to the user account itself.
Claims 3-4 and 13-14 depend on claims 2 and 12 respectively, therefore they inherit these rejections.
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 discloses a method implemented by a service provider computing system of a service provider, the service provider computing system comprising one or more hardware processors, the method comprising: transmitting, to a financial institution computing system, an application programming interface (API) call that comprises a request for account data associated with a user account administered by the financial institution computing system (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 call, from the financial institution computing system, the account data according to security access granted to the service provider (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, the account data received from the financial institution computing system (i.e. the trusted third-party processor system 1212 ………….. stores the electronic record in the record vault 1302) [Hockey, para.0352]; transmitting, to a user device executing a client application that is associated with the service provider, based at least in part on a data request from the client application, a data response including the account data that is stored in the non-volatile memory (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]; 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 does not explicitly disclose whereas Hockey in view of Eversoll does: instructing the service provider computing system to delete account data corresponding to the user account ;in response to receiving the scrub command, deleting, from the non-volatile memory, the account data received from the financial institution computing system (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); and transmitting, to the financial institution computing system, an indication that the account data corresponding to 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 or by e-mail or the like confirming the revocation) [Eversoll, para.0074].
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].
Re Claim 2. Hockey in view of Eversoll discloses the method of claim 1, further comprising receiving, from the financial institution computing system, 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.0324] that grants the service provider computing system access to a user account that is administered by the financial institution computing system (i.e. As described below, the authorization may include various limitations on access to the account ) [Hockey, para.0318] (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; generating secure electronic records and tokens (e.g., unique identifiers associated with the electronic records) based on user account data; enabling permissioning of access to, and execution of transactions on, user accounts on the user account systems; enabling revocation of permissions for, or de-authorization of, access to user accounts on the user account systems) [Hockey, para.0192].
Re Claim 3. Hockey in view of Eversoll discloses the method of claim 2, wherein the security access token is linked to the client application associated with the service provider (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 2, wherein the API call further comprises 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].
Re Claim 5. Hockey in view of Eversoll discloses the method of claim 1, wherein the account data comprises financial and non-financial data associated with a user (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; generating secure electronic records and tokens (e.g., unique identifiers associated with the electronic records) based on user account data; enabling permissioning of access to, and execution of transactions on, user accounts on the user account systems; enabling revocation of permissions for, or de-authorization of, access to user accounts on the user account systems) [Hockey, para.0192], (i.e. The external user account systems may comprise proprietary and external financial services (e.g., financial institution services, among others, as described above) [Hockey, para.0203].
Re Claim 6. Hockey in view of Eversoll discloses the method of claim 1, further comprising receiving the receiving the scrub command in response to a user selection via a graphical user interface (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].
Re Claim 7. Hockey in view of Eversoll discloses the method of claim 6, wherein the user selection is made via a second client application associated with the financial institution computing system (i.e. the external user account system 1206 may receive, from the user, a selection of one or more of these accounts that are to be associated with the external user-facing system/application 1208. Such a selection may be obtained from the user via an interactive user interface that may be presented to the user (via, e.g., any combination of the external user account system 1206, the permissions plug-in 1210 and 1211, the external user-facing system/application 1208, and/or the user computing device 1214). An example of such a user interface is shown in FIG. 20A) [Hockey, para.0366-0370]
Re Claim 8. Hockey in view of Eversoll discloses the method of claim 1, further comprising authenticating the request for account data in response to the API call (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].
Re Claim 9. Hockey in view of Eversoll discloses the method of claim 1, further comprising receiving, after receiving the scrub command, a second data request from the client application executing on the user device (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) [Hockey, para.0091].
Re Claim 10. Hockey in view of Eversoll discloses the method of claim 9, further comprising transmitting, in response to receiving the second data request from the client application, an indication that the data request is declined (i.e. 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 one or more 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 ….and communicate, to the external application, an indication that the external application is not authorized to initiate the transaction) [Hockey, para.0091].
Re Claims 11-18. These claims recite features similar to those in claims 1-8, therefore they are rejected in a similar manner.
Re Claims 19-20. These claims recite features similar to those in claims 1-2, therefore they are rejected in a similar manner.
Prior art made of record however not relied upon includes:
Best et al (US 2016/0189121) describes a method for providing a user interface to a user device associated with a user via an account management application running on the user device. The user interface might receive, from the user, a first set of inputs comprising instructions to push payment information and a second set of inputs comprising instructions indicating two or more user accounts for at least two vendor websites with which the payment information is to be updated. The account management application or a server computer subsequently automatically concurrently pushes the payment information to the two or more user accounts, in response to receiving the first and second sets of inputs from the user
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