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 .
Claims 1-20 have been examined.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 7/26/24 is being considered by the examiner.
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 claims 1-19 of U.S. Patent No. 12,074,880 and claims 1-19 of U.S. Patent No. 11,316,862. Although the claims at issue are not identical, they are not patentably distinct from each other because present application and related patents all disclose system/device for generating token usable to access user account and initiate second fallback authorization in response to determining the institution does not support first fallback authorization mechanism or the first fallback authorization mechanism fails. See comparison of exemplary claims.
Instant Application
U.S. 11,316,862
1. A device, comprising:
one or more memories;
one or more processors, coupled to the one or more memories, configured to:
receive a first account identifier and account credentials associated with an account;
access, via an application programming interface (API) associated with an institution and based on using the account credentials, a second account identifier associated with the account;
generate, based on determining that the first account identifier and the second account identifier match, a token usable to authorize access to account data associated with the account or initiate transactions related to the account;
perform, based on determining that at least one of the institution does not support a first fallback authorization mechanism or the first fallback authorization mechanism failed, actions, wherein the actions comprise:
initiating a second fallback authorization mechanism;
initiating one or more authorization transactions to the account using the first account identifier and an institution identifier associated with the institution; and
verifying the one or more authorization transactions; and
generate, based on verifying the one or more authorization transactions, another token.
1. A computer system comprising:
a computer readable storage medium having program instructions embodied therewith;
and one or more hardware processors configured to execute the program instructions to cause the computer system to: provide a permissions plug-in to a computing device operated by a user, wherein the permissions plug-in is configured to:
generate one or more user interfaces configured to receive a selection of an institution from the user;
generate one or more user interfaces configured to receive account credentials associated with a user account from the user; and
generate one or more user interfaces configured to receive a first account identifier associated with the user account from the user;
receive, from the computing device operated by the user, the selection of the institution, and the account credentials associated with the user account associated with the institution;
determine whether the institution supports a primary authorization mechanism; in response to determining that the institution does not support the primary authorization mechanism, initiate a first fallback authorization mechanism;
request and receive the first account identifier associated with the user account from the computing device operated by the user;
access a second account identifier associated with the user account through at least an application programming interface (“API”) associated with the institution and using the account credentials;
compare the first account identifier with the second account identifier to determine that the first account identifier and the second account identifier match; and
in response to determining that the first account identifier and the second account identifier match, generate a token usable to authorize access to user account data associated with the user account or initiation of transactions related to the user account, wherein the permissions plug-in is configured to securely communicate, to the computer system, the selection of the institution, the account credentials, and the first account identifier, wherein the selection of the institution, the account credentials, and the first account identifier are not stored by the computing device operated by the user or accessible to an external user-facing system/application executing on the computing device operated by the user.
7. The computer system of claim 1, wherein the one or more processors are configured to execute the program instructions to further cause the computer system to:
in response to determining that at least one of: the institution does not support either the primary authorization mechanism or the first fallback authorization mechanism, or the first fallback authorization mechanism failed:
initiate a second fallback authorization mechanism;
initiate one or more authorization transactions to the user account using an account identifier associated with the user account and an institution identifier associated with the institution;
verify the one or more authorization transactions; and
in response to verifying the one or more authorization transactions, generate a token usable to authorize access to user account data associated with the user account or initiation of transactions related to the user account.
Instant Application
U.S. 12,074,880
1. A device, comprising:
one or more memories;
one or more processors, coupled to the one or more memories, configured to:
receive a first account identifier and account credentials associated with an account;
access, via an application programming interface (API) associated with an institution and based on using the account credentials, a second account identifier associated with the account;
generate, based on determining that the first account identifier and the second account identifier match, a token usable to authorize access to account data associated with the account or initiate transactions related to the account;
perform, based on determining that at least one of the institution does not support a first fallback authorization mechanism or the first fallback authorization mechanism failed, actions, wherein the actions comprise:
initiating a second fallback authorization mechanism;
initiating one or more authorization transactions to the account using the first account identifier and an institution identifier associated with the institution; and
verifying the one or more authorization transactions; and
generate, based on verifying the one or more authorization transactions, another token.
1. A computer system comprising:
a computer readable storage medium having program instructions embodied therewith; and
one or more hardware processors configured to execute the program instructions to cause the computer system to:
provide permissions code to a computing device operated by a user, wherein the permissions code is configured to generate one or more user interfaces configured to receive, from the user, at least a first account identifier associated with a user account;
receive, from the computing device operated by the user, at least the first account identifier and account credentials associated with the user account;
access a second account identifier associated with the user account through at least an application programming interface (“API”) associated with an institution and using the account credentials;
in response to determining that the first account identifier and the second account identifier match, generate a token usable to authorize access to user account data associated with the user account or initiate transactions related to the user account, wherein the permissions code is configured provide secure communications, to the computer system, of the first account identifier and the account credentials, and wherein the first account identifier and the account credentials are not stored by the computing device operated by the user;
in response to determining that at least one of: the institution does not support a first fallback authorization mechanism, or the first fallback authorization mechanism failed:
initiate a second fallback authorization mechanism;
initiate one or more authorization transactions to the user account using the first account identifier and an institution identifier associated with the institution; and
verify the one or more authorization transactions; and
in response to verifying the one or more authorization transactions, generate a token usable to authorize access to the user account data associated with the user account or initiate transactions related to the user account.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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. U.S. 2017/0070500 (hereinafter Hockey) in view of Kadaster et al. U.S. 2016/0148201 (hereinafter Kadaster).
As per claim 1, 8 and 15, Hockey discloses a device/CRM, comprising: one or more memories; one or more processors, coupled to the one or more memories, configured to:
receive a first account identifier and account credentials associated with an account (Hockey: Hockey: Figs. 1-2 and [0203]-[0209]: system communicates through APIs associated with different financial institutions and serve as proxy to receive and process user credentials; Fig. 16A and [0363]-[0364]);
access, via an application programming interface (API) associated with an institution and based on using the account credentials, a second account identifier associated with the account (Hockey: Figs. 1-2 and [0203]-[0209]: system communicates through APIs associated with different financial institutions);
generate, based on determining that the first account identifier and the second account identifier match, a token usable to authorize access to account data associated with the account or initiate transactions related to the account (Hockey: Fig. 16A and [0362]-[0366] and [0369]: generate token when user account identifier corresponds to/matches account associated with external institution systems);
Hockey further discloses when the normalized financial service request cannot be processed by using the primary application proxy instance, the secondary application proxy instance is used to process the normalized financial service request (Hockey: [0027]), and the system may also request additional authentication data when the primary authentication credentials are not sufficient (Hockey: [0234]-[0235]).
Hockey does not explicitly disclose, perform, based on determining that at least one of the institution does not support a first fallback authorization mechanism or the first fallback authorization mechanism failed, actions, wherein the actions comprise: initiating a second fallback authorization mechanism; initiating one or more authorization transactions to the account using the first account identifier and an institution identifier associated with the institution; and verifying the one or more authorization transactions; and generate, based on verifying the one or more authorization transactions, another token.
However, Kadaster discloses determining that first authentication option fails, initiate secondary authentication procedure with another authentication server in order to authorize access to user account (Kadaster: [0007]-[0009] and [0041]-[0045]). It would have been obvious to one having ordinary skill in the art to establish multiple authentication/authorization options in the system of Hockey because Hockey and Kadaster both disclose proxy servers that process user’s authentication credentials to gain account access. The motivation to combine would be to offer greater flexibility by allowing secondary or other backup authentication processes when primary authentication mechanism fails.
As per claim 2, 9 and 16, Hockey as modified discloses the limitations of claims 1, 8 and 15 respectively. Hockey as modified further discloses wherein the other token is usable to authorize access to the account data or initiate transactions related to the account (Kadaster: [0007]-[0009]: allow account access by alternative means of authentication/authorization). Same rationale applies here as above in rejecting claim 1.
As per claim 3, 10 and 17, Hockey as modified discloses the limitations of claim 1, 8 and 15 respectively. Hockey further discloses wherein the one or more processors are further configured to: instantiate a simulated instance of an application associated with the institution, wherein the simulated instance is configured to communicate with the institution via the API (Hockey: [0008]-[0010]: simulated instance to communication with external institution via the normalized API).
As per claim 4, 11 and 18, Hockey as modified discloses the limitations of claims 1, 8 and 15 respectively. Hockey further discloses wherein the one or more processors are further configured to: generate, based on initiating the one or more authorization transactions and before verifying the one or more authorization transactions, an interim token (Hockey: [0362]-[0366] and [0369]; Kadaster: [0007]-[0009]). Same rationale applies here as above in rejecting claim 1.
As per claim 5, 12 and 19, Hockey as modified discloses the limitations of claims 1, 8 and 15 respectively. Hockey further discloses wherein the one or more processors are further configured to: provide permissions code configured to generate one or more user interfaces, wherein the one or more user interfaces are configured to receive the first account identifier and the account credentials associated with the account (Hockey: [0288]).
As per claim 6, 13 and 20, Hockey as modified discloses the limitations of claims 1, 8 and 15 respectively. Hockey further discloses wherein the second account identifier is extracted from a document accessed based on the API (Hockey: [0215]; [0240]; [0251]).
As per claim 7 and 14, Hockey as modified discloses the limitations of claims 1 and 8 respectively. Hockey further discloses wherein the one or more authorization transactions are verified based on at least one of: transaction type, transaction description, transaction amount, transaction identifier, datestamps, timestamps, source, or other transaction metadata (Kadaster: [0030]: verify transaction amount). Same rationale applies here as above in rejecting claim 1.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chitalia et al. U.S. 2019/0019185 discloses method for using a transaction identifier to protect sensitive credentials.
Sgambati et al. U.S. 2018/0157851 discloses method for authentication of access based on multi-data source information.
Subramanian et al. U.S. 11,954,671 discloses unified login across applications.
Liu et al. U.S. 2021/0182955 discloses financial transaction management system.
Pantfoerder et al. U.S. 2019/0325125 discloses identity credential verification techniques.
Putnam U.S. 2019/0188717 discloses data verified bank deposits.
Kujawski U.S. 2019/0114442 discloses API bridge for transporting a local request from a local client system to a target server system.
Anderson et al. U.S. 2019/0075115 discloses method for accessing cloud resources from a local development environment.
Kumar U.S. 2017/0272419 discloses identity authentication migration between different authentication systems.
Liu et al. U.S. 2017/0048114 discloses method for managing resources with an external account.
O’Donnell U.S. 9,961,069 discloses ticket generator for alternate authentication environments.
Caldwell U.S. 2016/0036801 discloses user authentication in separate authentication channels.
Schoen et al. U.S. 2015/0281225 discloses method to operate a service with machine generated authentication tokens.
Hoy et al. U.S. 2015/0128242 discloses federated identity mapping using delegated authorization.
Doyle et al. U.S. 2015/0088740 discloses method for managing financial transaction based on electronic check data.
Bhat et al. U.S. 2015/0012443 discloses financial account authentication.
Chourasia et al. U.S. 2014/0258063 discloses automated financial data aggregation.
Pant et al. U.S. 2014/0236792 discloses financial account authentication.
Speyer et al. U.S. 2010/0050251 discloses method for providing security token authentication.
Wu et al. U.S. 5,774,551 discloses pluggable account management interface with unified login and logout and multiple user authentication services.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIN HON (ERIC) CHEN whose telephone number is (571)272-3789. The examiner can normally be reached Monday to Thursday 9am- 7pm.
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, Lynn Feild can be reached at 571-272-2092. 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.
/SHIN-HON (ERIC) CHEN/Primary Examiner, Art Unit 2431