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-3, 5-7, 15-17 and 19-29 have been examined.
Response to Arguments
Applicant’s arguments with respect to claims 1-3, 5-7, 15-17 and 19-29 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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-3, 5-7, 9-17 and 19-29 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, from a user device, a first account identifier associated with an account;
access, based on a failure of a primary authorization mechanism and via an application programming interface (API) associated with an institution, a second account identifier associated with the account, wherein the second account identifier is useable for a first fallback authorization mechanism;
determine that a condition associated with the first fallback authorization mechanism is not satisfied, wherein the condition is based on at least one of:
determining that the institution does not support the first fallback authorization mechanism, the first fallback authorization mechanism failed, or the first account identifier and the second account identifier do not match;
initiate, based on the failure of the first fallback authorization and as part of a second fallback authorization mechanism, one or more authorization transactions to the account using the first account identifier and an institution identifier associated with the institution;
wherein the second fallback authorization is associated with generating an interim token, and
wherein the interim token is generated prior to verifying the one or more authorization transactions while awaiting confirmation of the one or more authorization transactions; and
change a state of the interim token in association with authorizing further activities on the account.
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, from a user device, a first account identifier associated with an account;
access, based on a failure of a primary authorization mechanism and via an application programming interface (API) associated with an institution, a second account identifier associated with the account, wherein the second account identifier is useable for a first fallback authorization mechanism;
determine that a condition associated with the first fallback authorization mechanism is not satisfied, wherein the condition is based on at least one of:
determining that the institution does not support the first fallback authorization mechanism, the first fallback authorization mechanism failed, or the first account identifier and the second account identifier do not match;
initiate, based on the failure of the first fallback authorization and as part of a second fallback authorization mechanism, one or more authorization transactions to the account using the first account identifier and an institution identifier associated with the institution;
wherein the second fallback authorization is associated with generating an interim token, and
wherein the interim token is generated prior to verifying the one or more authorization transactions while awaiting confirmation of the one or more authorization transactions; and
change a state of the interim token in association with authorizing further activities on the account.
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-3, 5-7, 15-17 and 20-29 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) and further in view of Csinger et al. U.S. 2011/0270751 (hereinafter Csinger).
As per claim 1, 15 and 21, Hockey discloses a device/CRM/method, comprising: one or more memories; one or more processors, coupled to the one or more memories, configured to:
receive, from a user device, a first account identifier 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, based on a failure of a primary authorization mechanism and via an application programming interface (API) associated with an institution, a second account identifier associated with the account, wherein the second account identifier is useable for a first fallback authorization mechanism (Hockey: Figs. 1-2 and [0203]-[0209]: system communicates through APIs associated with different financial institutions);
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: initiate 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.
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]: various authentication options based on user’s account and institution identifiers). 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.
Hockey as modified does not explicitly disclose wherein the second fallback authorization is associated with generating an interim token, and wherein the interim token is generated prior to verifying the one or more authorization transactions while awaiting confirmation of the one or more authorization transactions; and change a state of the interim token in association with authorizing further activities on the account. However, Csinger discloses generating token for initial verification and upgrade the initial token after subsequent authentication (Csinger: [0093]-[0097]: initial session token/interim token is generated, and the session token is upgraded by providing payment terms and amount). It would have been obvious to one having ordinary skill in the art to generate session ID to allow specific requests and subsequently upgrade/update the session authorization level because Csinger, Hockey and Kadaster are in the same field of endeavor involving authorization access to financial transactions. The motivation to combine would be allow additional features to the prior sessions that enable broader array of transactions to occur (Csinger: [0012]).
As per claim 2, 16 and 22, Hockey as modified discloses the limitations of claims 1, 15 and 21 respectively. Hockey as modified further discloses wherein the interim 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; Csinger: [0012]). Same rationale applies here as above in rejecting claim 1.
As per claim 3, 17 and 23, Hockey as modified discloses the limitations of claim 1, 15 and 21 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 5, 19 and 24, Hockey as modified discloses the limitations of claims 1, 15 and 21 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, 20 and 25, Hockey as modified discloses the limitations of claims 1, 15 and 21 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 26, Hockey as modified discloses the limitations of claims 1 and 21 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.
As per claim 27-29, Hockey as modified discloses the limitations of claims 21, 1 and 15 respectively. Hockey as modified further discloses determining whether there is support for transaction information related to the account to be pulled from the institution, wherein the verification of the one or more authorization transactions is based on pulling transaction information from the institution when it is determined that there is support for the transaction information to be pulled from the institution (Hockey: [0232]: collecting and pulling verification information from financial institutions are well-known).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hoy et al. U.S. 2015/0128242 discloses federated identity mapping using delegated authorization.
Pant et al. U.S. 2014/0236792 discloses financial account authentication.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
Prosecution Insights