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 .
Status of the Claims
The office action is being examined in response to the amendments submitted by the applicant on May 26, 2026.
Claims 1, 16, and 20 have been amended and are hereby entered.
Claims 2–8, 10–15, 17, and 18 are original and remain as previously presented.
Claims 9 and 19 were previously presented and remain unchanged.
No claims have been cancelled.
No new claims have been added.
This action is made FINAL.
The examiner would like to note that this application is now being handled by examiner Michael Anderson.
RESPONSE TO ARGUMENTS
Applicant’s remarks filed May 26, 2026, have been fully considered. Applicant’s amendments to the claims have been entered. For the reasons set forth below, Applicant’s arguments are not persuasive to overcome the rejections maintained in this Office Action.
I. Regarding the Rejections under 35 U.S.C. § 101
Applicant traverses the § 101 rejection, arguing that the claims do not recite an abstract idea (Step 2A, Prong 1), that they integrate any purported abstract idea into a practical application (Step 2A, Prong 2), and that they recite significantly more than the abstract idea (Step 2B). These arguments have been considered but are respectfully traversed.
Step 2A, Prong 1: Applicant argues that the claims do not fall into the judicial exception of “certain methods of organizing human activity” because they relate to a technical solution for enabling secure account creation and data transfer. This argument is not persuasive. The core of the claimed invention—establishing a financial account for a user and generating account data—is a fundamental economic practice and a commercial interaction. The courts have routinely held that account origination, financial transactions, and managing user accounts are abstract ideas falling squarely within the realm of organizing human activity. The recitation of generic computer components (e.g., “interface elements,” “third-party application,” “network”) does not remove the claim from the realm of abstract ideas.
Step 2A, Prong 2: Applicant argues that the feature of presenting interface elements “within the third-party application without directing the user to a second application” provides a technical improvement to the functioning of computing systems by reducing computing time and resources. This argument is not persuasive. Presenting information or an interface without redirecting a user (e.g., via a pop-up, an iframe, or an API call) is a conventional user interface (UI) arrangement and a business-driven design choice to reduce user friction. It does not improve the basic functioning of the computer itself, nor does it effect a transformation or solve a uniquely technical problem in a non-conventional way. The reduction in “computing time and resources” alleged by Applicant is merely the natural result of performing the abstract idea (opening an account) using generic computer functions (an API instead of a full web redirect). Merely linking the use of a judicial exception to a particular technological environment (a third-party app) does not integrate the exception into a practical application. See MPEP 2106.04(d).
Step 2B: Applicant argues that the claims recite “significantly more” because the Specification states that it is “unconventional” to allow third parties to present an offer without directing the user to the financial institution’s website. This argument is not persuasive. A statement in the Specification that a business practice is “unconventional” does not make the technological implementation unconventional. The claims are implemented using generic computer components (processors, memory, networks, APIs, SDKs) performing their basic, routine functions (displaying interfaces, receiving data, parsing codes, transmitting data). Furthermore, as evidenced by the prior art of record (e.g., Dhar and Chen), presenting a provider’s payment or account-establishment interface within a merchant’s application without redirecting the user was well-understood, routine, and conventional in the art at the time of the invention. Therefore, the claims do not recite significantly more than the abstract idea itself.
The § 101 rejection is maintained.
II. Regarding the Rejections under 35 U.S.C. § 103
Applicant traverses the previous § 103 rejections based on Jiam, Kumar, Hruska, Chen, and Mendez, arguing primarily that the cited portions of Jiam, Kumar, and Hruska fail to teach “parsing the code to obtain the identifier of the provider, the identifier of the third-party computing device, and the identifier of the type of account to open,” as well as “validating the first set of user data or the second set of user data using the code.”
Applicant’s arguments with respect to the previous combination of Jiam, Kumar, and Hruska have been fully considered. In view of the amendments to the claims, the previous § 103 rejections based on those references have been withdrawn.
However, the withdrawal of the previous rejections does not render the claims patentable. A new ground of rejection has been set forth in this Office Action under 35 U.S.C. § 103 applying a new combination of art: Chen, Carrott, Drury, and Dhar (with Hamilton and Mahajan applied to dependent claims).
As detailed in the current § 103 rejection above, the newly cited art directly addresses the features Applicant added by amendment. Specifically, Carrott and Drury explicitly teach the generation, transmission, parsing, and validation of a composite code containing the exact identifiers recited in the amended claims:
Carrott teaches the generation of a one-time-use code comprising the provider identifier, the device/user identifier, and the transaction/account type, as well as the parsing algorithm (<transaction_id>::<account_id>::<encrypted_data>) and the validation of those identifiers against stored records.
Drury further teaches the specific inclusion of an enumerated AccountType identifier within a third-party-generated composite message, along with the designated format, parsing, and validation operations.
Because the newly applied prior art explicitly teaches the features Applicant argues were missing from the previous art, Applicant’s arguments are mooted by the new grounds of rejection. The claims remain unpatentable under 35 U.S.C. § 103.
III. Regarding the Rejection for Nonstatutory Double Patenting (ODP)
Applicant argues that the amendments to claims 1, 16, and 20 moot the nonstatutory double patenting rejection over U.S. Patent No. 11,995,619.
This argument has been considered but is not persuasive. While Applicant has amended the claims, the claims as amended remain patentably indistinct from the claims of the '619 patent. The addition of parsing a code for specific identifiers and validating data using that code represents an obvious variation of the account-establishment and data-transfer methods claimed in the '619 patent, particularly in view of the prior art cited in the current § 103 rejection (which demonstrates that such coding and parsing techniques are conventional in this exact environment).
Therefore, the ODP rejection has been updated to reflect the amended claim language and is maintained. To overcome this rejection, Applicant must either file a terminal disclaimer in compliance with 37 CFR 1.321© or demonstrate that the claims are patentably distinct.
Priority
Applicant’s claim for the benefit of prior-filed applications under 35 U.S.C. §§ 119(e) and 120 is acknowledged. The instant application is a continuation of U.S. Patent Application No. 16/405,157, filed May 7, 2019 (now U.S. Patent No. 11,995,619), which claims the benefit of U.S. Provisional Patent Application No. 62/668,632, filed May 8, 2018, and which is a continuation-in-part of U.S. Patent Application No. 16/215,548, filed December 10, 2018 (now U.S. Patent No. 11,106,515), which in turn claims the benefit of U.S. Provisional Patent Application No. 62/611,288, filed December 28, 2017.
The claim to the benefit of these prior-filed applications has been reviewed. To be entitled to the benefit of the filing date of a prior-filed application under 35 U.S.C. § 119(e) or § 120, the claimed subject matter must be disclosed in the prior-filed application in the manner provided by 35 U.S.C. § 112(a), and the disclosure must be present in each application in the chain of benefit. See MPEP 211.05; MPEP 2163. A claim is entitled only to the earliest filing date of an application in the chain that provides adequate written description support for the subject matter of that claim.
Upon review, the following effective filing dates apply:
(A) Claims Not Entitled to the Benefit of Provisional Application No. 62/611,288 or Application No. 16/215,548
No claim in the instant application is entitled to the benefit of the December 28, 2017 filing date of Provisional Application No. 62/611,288 or the December 10, 2018 filing date of Application No. 16/215,548.
Neither of these applications discloses the account-open subject matter recited in the instant claims. The disclosures of Provisional Application No. 62/611,288 and Application No. 16/215,548 are directed to multi-platform product integration by way of an application programming interface (“API”) bank, corresponding to FIGS. 1–8 of the instant specification. Neither application contains FIGS. 9–13 of the instant specification, nor the corresponding written description of methods 900 and 1000. Specifically, neither application discloses:
a first set of user data or a second set of user data as recited in the instant claims;
a code comprising an identifier of the provider, an identifier of the third-party computing device, and an identifier of a type of account to open, generated based on a format designated by the provider;
parsing the code or validating user data using the code;
encoding of a portion of the second set of user data by the user computing device such that it is incapable of being decoded by the third-party computing device;
establishing a new account and generating a set of account data associated therewith; or
transmitting the set of account data to the third-party computing device for use in a transaction.
The nearest disclosure in these applications is found at Application No. 16/215,548, ¶¶ [0083] and [0092], which state respectively that software components “may be configured to enable the user to register for an account at the financial institution from within the third party service,” and that “if the product selected by the customer is to register for an account at the financial institution, additional information may be requested from the user … [which] may be used to formulate a transaction request to fund the user’s new account.” These generalized statements do not reasonably convey to one of ordinary skill in the art that the inventors had possession of the specific multi-party data-exchange method recited in the instant claims. A disclosure that merely renders the claimed subject matter obvious does not satisfy the written description requirement. See MPEP 2163.02; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1352 (Fed. Cir. 2010) (en banc).
It is further noted that Provisional Application No. 62/668,632 states at ¶ [0001] that it “incorporates herein by reference in its entirety” Provisional Application No. 62/611,288. Incorporation by reference to a provisional application is not permitted for essential material. See 37 CFR 1.57(d); MPEP 608.01(p). In any event, the incorporation is of no consequence here, as Provisional Application No. 62/611,288 contains none of the subject matter at issue.
That Application No. 16/405,157 was filed as a continuation-in-part of Application No. 16/215,548 is consistent with this determination. Claims drawn to matter added in a continuation-in-part are entitled only to the filing date of the continuation-in-part. See MPEP 211.05; MPEP 201.08.
(B) Claims Entitled to the Benefit of Provisional Application No. 62/668,632 (May 8, 2018)
Claims 1–8, 10–18, and 20 are entitled to the benefit of the May 8, 2018 filing date of Provisional Application No. 62/668,632, with the exception noted in subsection (D) below.
Provisional Application No. 62/668,632 provides written description support for the limitations of these claims, including: the interaction with an interactive element displayed via the third-party application (¶¶ [0128]–[0129], [0140]); the first set of user data stored in association with the third-party account (¶¶ [0044], [0127]); presentation of interface elements without directing the user to a second application (¶¶ [0028], [0031], [0145]); the invocation of an API or SDK of the provider institution (¶¶ [0029], [0079]); the code comprising the recited identifiers and generated in a format designated by the financial institution, including an expiration portion (¶ [0133]); validation of user data using the code (¶¶ [0133], [0137]); the encoding of a portion of the second set of user data such that the third party is incapable of decoding it (¶ [0134]); establishment of the new account and generation of account data (¶ [0138]); and transmission of the account data for use in a transaction (¶¶ [0138]–[0139]). The corresponding disclosure appears in Application No. 16/405,157 at ¶¶ [0132]–[0133], [0048], [0033], [0036], [0149], [0034], [0083], [0137], [0141], [0138], [0142], and [0143], respectively.
(c) Claims Entitled Only to the Benefit of Application No. 16/405,157 (May 7, 2019)
Claims 9 and 19 are entitled only to the May 7, 2019 filing date of Application No. 16/405,157.
Claims 9 and 19 recite that “the first set of user data includes: a first user data subset received … before the third-party application receives a user request to open the new account … and a second user data subset received … after the third-party application receives the user request to open the new account.” Support for this limitation is found at Application No. 16/405,157, ¶ [0015].
Provisional Application No. 62/668,632 does not contain a counterpart to ¶ [0015] and does not describe the first set of user data as itself comprising a post-request subset. Rather, the provisional employs a different taxonomy, in which the “first set of user data” is the registration data collected before the user’s account-open selection (¶ [0127]) and the data collected after that selection is separately designated the “second set of user data” (¶¶ [0131]–[0132]). Accordingly, claims 9 and 19 are not entitled to the benefit of the May 8, 2018 provisional filing date.
(D) Limitation Not Entitled to the Benefit of Any Prior-Filed Application
The limitation of claim 20 requiring that the code be “encrypted by the service provider computing device according to an encryption format different from the format designated by the provider institution” is not supported in any application in the chain of benefit, and no effective filing date earlier than the filing date of the instant application has been identified for that limitation.
Paragraph [0137] of Application No. 16/405,157 — the sole passage describing the code — does not mention encryption of the code. The only encryption disclosure in the family appears at Application No. 16/405,157, ¶ [0116] (and correspondingly at Provisional Application No. 62/668,632, ¶ [0112], and Application No. 16/215,548, ¶ [0081]), which describes a token or digital certificate issued by the financial institution and encrypted with a key specific to the third party, in the context of the API access-permissioning flow of method 700. That disclosure is directed to a different artifact, generated by a different party, for a different purpose, and does not describe an encryption format that differs from a provider-designated code format. No passage in any application in the chain describes two distinct formats applied to the code.
It is further noted that the encryption limitation was introduced by amendment during prosecution of Application No. 16/405,157 and did not appear in the claims as originally filed in that application. Claims added by amendment do not themselves constitute written description support. See MPEP 2163.06.
No rejection under 35 U.S.C. § 112(a) is made at this time. This determination is set forth solely to establish the effective filing dates applicable to the claims for purposes of prior-art availability under 35 U.S.C. § 102.
Summary of Effective Filing Dates
Claim(s)
Effective Filing Date
Supporting Application
1–8, 10–18, 20
May 8, 2018
Provisional App. No. 62/668,632
9, 19
May 7, 2019
App. No. 16/405,157
20 (encryption limitation)
[Filing date of instant application] – 05/24/2024
No earlier support identified
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (rather than statute) and is primarily intended to prevent prolongation of the patent term by prohibiting claims in a second patent not patentably distinct from claims in a first patent. In In re Berg, the Court of Appeals for the Federal Circuit held that the two-way test applies only in the unusual circumstance where, inter alia, the application at issue is filed first but is the second to issue. The one-way test applies in all other circumstances. In re Berg, 140 F.3d 1428 (Fed. Cir. 1998).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321© 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 instant 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit the USPTO website. 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.
Claims 1–20 are rejected under the judicially created doctrine of obviousness-type double patenting as being unpatentable over claims 1–20 of U.S. Patent No. 11,995,619. Although the claims at issue are not identical, they are not patentably distinct from each other for the reasons set forth below.
The instant application and U.S. Patent No. 11,995,619 are commonly owned, and the instant application is a continuation of Application No. 16/405,157, from which the '619 patent issued. The one-way test applies, as the instant application was filed after and issues after the '619 patent. The safe harbor of 35 U.S.C. § 121 is unavailable, as the instant application is a continuation and was not filed as a divisional as a consequence of a restriction requirement imposed in Application No. 16/405,157.
Instant Claim 1 vs. Claim 1 of the '619 Patent
Instant claim 1 recites substantially the same method as claim 1 of the '619 patent. Both claims require receiving, in response to an interaction with a first interactive element displayed via a third-party application executing on a user computing device, a request for account open functionality comprising a first set of user data stored in association with the user’s third-party account; providing interface elements pre-populated with the first set of user data; receiving an account open request comprising a second set of user data and a code generated by the third-party computing device based on a format designated by the provider, the code comprising an identifier of the provider, an identifier of the third-party computing device, and an identifier of a type of account to open, wherein at least a portion of the second set of user data is encoded by the user computing device and is incapable of being decoded by the third-party computing device; establishing the new account by generating a set of account data using the first and second sets of user data without directing the user away from the third-party application; and transmitting the set of account data to the third-party computing device for use in a transaction involving the user computing device.
Instant claim 1 differs from claim 1 of the '619 patent in that instant claim 1:
omits the requirement that the code be “encrypted by the third-party computing device according to an encryption format different from the format designated by the provider”;
omits the requirement that the code comprise “an expiration time,” and the requirement that the new account be established “responsive to determining that the expiration time satisfies a predetermined time period”;
omits from the independent claim the requirement that the interface elements “invok[e] an application programming interface (API) of the provider,” which instant claim 1 relegates to dependent claim 2; and
omits from the independent claim the requirement that “the first set of user data is displayed within the subset of the one or more interface elements,” which instant claim 1 relegates to dependent claim 14.
Instant claim 1 is therefore broader in scope than, and fully encompasses, claim 1 of the '619 patent. Instant claim 1 reads on every embodiment falling within the scope of '619 claim 1, and additionally reads on embodiments in which the code is unencrypted, in which the code carries no expiration time, in which no API of the provider is invoked, and in which the first set of user data is not displayed. The omission of limitations present in a patented claim does not render the later claim patentably distinct from the patented claim. See MPEP 804(II)(B)(1); In re Van Ornum, 686 F.2d 937 (CCPA 1982); Eli Lilly & Co. v. Barr Labs., Inc., 251 F.3d 955, 968 (Fed. Cir. 2001).
Instant claim 1 further recites that establishing the new account is accomplished at least in part by “(i) parsing the code to obtain the identifier of the provider, the identifier of the third-party computing device, and the identifier of the type of account to open” and “(ii) validating the first set of user data or the second set of user data using the code.” These limitations do not render instant claim 1 patentably distinct from '619 claim 1. Claim 1 of the '619 patent already requires “establishing, based on the first set of user data, the second set of user data, and the code … the new account,” which necessarily entails reading and using the constituent identifier portions that the code is required to comprise. It would have been obvious to one of ordinary skill in the art at the time of the invention that establishing an account based on a code comprising a plurality of identifier portions entails parsing the code to obtain those identifiers, and that a code provided together with user data for the purpose of establishing an account is used to validate that user data. Accordingly, these limitations recite no more than an articulation of operations already required by, and obvious in view of, the patented claim.
Instant Claim 16 vs. Claim 16 of the '619 Patent
Instant claim 16 recites substantially the same method as claim 16 of the '619 patent, differing in that instant claim 16 (i) omits the requirement that the code be “encrypted by the service provider computing device according to an encryption format different from the format designated by the provider institution”; (ii) omits the requirement that the code comprise “an expiration time” and that the new account be established “responsive to determining that the expiration time satisfies a predetermined time period”; and (iii) adds the parsing and validating limitations addressed above with respect to instant claim 1.
Instant claim 16 recites “an identifier of the service provider computing device,” whereas '619 claim 16 recites “an identifier of the service provider.” This is an immaterial variation that does not render the claims patentably distinct, the specification describing the code as including “a second portion uniquely identifying the service provider” without distinguishing between the service provider and its computing device for this purpose.
Instant claim 16 additionally recites that the interface elements “are presented within the first application of the service provider without directing the user to a second application.” This limitation is substantially the same as the closing wherein clause of '619 claim 16, which requires that “the new account is established while the user uses the first website or the first application without directing the user to a second website of the provider institution or a second application of the provider institution,” a limitation also present in instant claim 16.
Instant claim 16 is therefore broader in scope than, and fully encompasses, claim 16 of the '619 patent, and is not patentably distinct therefrom.
Instant Claim 20 vs. Claim 20 of the '619 Patent
Instant claim 20 recites substantially the same institution computing system as claim 20 of the '619 patent, including the network interface, the processor(s) and memory storing instructions, and the recited receive, provide, receive, establish, and transmit operations. Instant claim 20 retains the requirement that the code be “encrypted by the service provider computing device according to an encryption format different from the format designated by the provider institution.”
Instant claim 20 differs in that it omits the requirement that the code comprise “an expiration time” and the requirement that the new account be established “responsive to determining that the expiration time satisfies a predetermined time period,” and adds the parsing and validating limitations addressed above with respect to instant claim 1. The recitation of “one or more processors and memory” in instant claim 20, as compared with “a processor and a memory” in '619 claim 20, is an immaterial variation.
Instant claim 20 is therefore broader in scope than, and fully encompasses, claim 20 of the '619 patent, and is not patentably distinct therefrom.
Instant Dependent Claims 2–15 and 17–19
The instant dependent claims recite limitations that are recited in the claims of the '619 patent, either in an independent claim or in a corresponding dependent claim, as set forth below. These claims are accordingly not patentably distinct from the claims of the '619 patent.
Instant Claim
Subject Matter
Corresponding '619 Claim(s)
2
Interface elements invoke an API of the provider
Claim 1 (recited therein); claim 2
3
Interface elements include SDKs
Claim 3
4
Account open request transmitted in response to a signal
Claim 4
5
Third-party elements presented after the signal
Claim 9
6
Third-party elements presented before the signal
Claim 5
7
Provider elements after signal; third-party elements after receipt of first set
Claims 6 and 7
8
Third-party elements after signal but before receipt of second set
Claim 8
9
First set includes pre-request and post-request user data subsets
Claim 10
10
Form with set of fields; subset prefilled by third-party computing device
Claims 11 and 12
11
Accepting transaction amount; processing funds transfer
Claim 13
12
New account accepts automated payments via the third party
Claim 14
13
Using the new account to make a payment for a purchase
Claim 15
14
First set of user data displayed within the interface elements
Claim 1 (recited therein)
15
Code comprises expiration time; account established responsive thereto
Claim 1 (recited therein)
17
Account open functionality provided via an SDK of the provider institution
Claim 17
18
Account open request transmitted in response to a signal
Claim 18
19
Set of user data includes pre-request and post-request subsets
Claim 19
To the extent instant claims 2 and 14–15 recite subject matter required by '619 claim 1 itself, and instant claims 5–8 correspond to '619 claims 5–9 in a differing order of dependency, such differences in claim arrangement do not render the claims patentably distinct.
This rejection may be overcome by the filing of a terminal disclaimer in compliance with 37 CFR 1.321©.
Note Regarding U.S. Patent No. 11,106,515
The claims of U.S. Patent No. 11,106,515 (issued from Application No. 16/215,548) have also been considered. No double patenting rejection is made over that patent. The claims of the '515 patent are directed to receiving indications of third-party preferences, selecting subsets of application programming interfaces based on an identifier of each third-party system and the received indications, updating access permissions associated with each subset of APIs based on a respective digital certificate of each third-party system, and transmitting information causing an external device to render a user interface element in a graphical user interface. The '515 claims recite no account open request, no first or second set of user data, no code, no encoding of user data, no establishment of a new account, and no transmission of account data for use in a transaction. The instant claims are accordingly patentably distinct from the claims of the '515 patent.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1 (Representative)
Step 1: Statutory Category
Claim 1 recites “A method implemented by a system associated with a provider, the method comprising” a series of receiving, providing, establishing, and transmitting steps. Claim 1 therefore falls within the statutory category of a process. The analysis proceeds to Step 2A.
Step 2A, Prong One: Recitation of a Judicial Exception
Claim 1 recites an abstract idea within the enumerated grouping of “certain methods of organizing human activity,” specifically a fundamental economic practice and a commercial interaction — namely, opening a financial account for a user and providing the resulting account information for use in a transaction. See MPEP 2106.04(a)(2)(II).
The following claim limitations, under their broadest reasonable interpretation, recite the abstract idea:
“receiving … a request for account open functionality …, the user having a third-party account with the third-party, the request comprising a first set of user data of the user stored in association with the third-party account”;
“providing one or more interface elements associated with the account open functionality for presentation …, at least a subset of the one or more interface elements pre-populated with the first set of user data associated with the user and received in the request”;
“receiving … an account open request comprising a second set of user data …, wherein the account open request is for a new account with the provider”;
“establishing the new account at least in part by: … (ii) validating the first set of user data or the second set of user data …, and (iii) upon validating the first set of user data or the second set of user data, generating a set of account data associated with the new account using the first set of user data and the second set of user data”; and
“transmitting, the set of account data to the third-party computing device for use by the third-party computing device in a transaction involving the user computing device.”
Stripped of the recited technology, these limitations describe nothing more than a provider receiving a customer’s information from an intermediary, presenting the customer with a partially completed application, receiving the remainder of the customer’s information, checking that information, opening an account, and giving the account information to the intermediary so that the intermediary may transact with the customer. Such account-opening and payment-facilitation activity is a longstanding commercial practice historically performed by banks, brokers, merchants, and their agents, and is squarely within the “fundamental economic principles or practices” and “commercial or legal interactions” sub-groupings of certain methods of organizing human activity. See MPEP 2106.04(a)(2)(II)(A) and (B); Alice Corp. v. CLS Bank Int’l, 573 U.S. 208 (2014); Bilski v. Kappos, 561 U.S. 593 (2010); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350 (Fed. Cir. 2014).
Applicant’s own specification confirms this characterization. Paragraph [0038] describes “[t]he routine, conventional approach to opening a new account,” and paragraphs [0042]–[0045] frame the disclosure in terms of “establishing accounts and facilitating payments between parties.” Paragraph [0033] defines “account open functionality” as “the ability to apply for or otherwise request that a new account be established … in the applicant’s / requestor’s … name,” which is a commercial activity.
Additionally, the “validating” and “generating” limitations recite evaluations and judgments of the type that can be performed in the human mind or by a human using pen and paper, and thus also implicate the mental processes grouping. See MPEP 2106.04(a)(2)(III).
Because claim 1 recites a judicial exception, the analysis proceeds to Step 2A, Prong Two.
Step 2A, Prong Two: Integration into a Practical Application
Claim 1 recites the following additional elements beyond the identified abstract idea:
(i) a “system associated with a provider,” a “user computing device,” a “third-party computing device,” and a “network”; (ii) a “third-party application” executing on the user computing device, and “a first interactive element displayed via” that application; (iii) “one or more interface elements … presented within the third-party application without directing the user to a second application”; (iv) “a code generated by the third-party computing device,” the code comprising “an identifier of the provider, an identifier of the third-party computing device, and … an identifier of a type of account to open,” the code “generated … based on a format designated by the provider”; (v) “parsing the code to obtain the identifier of the provider, the identifier of the third-party computing device, and the identifier of the type of account to open”; and (vi) “at least a portion of the second set of user data is encoded by the user computing device and is incapable of being decoded by the third-party computing device.”
These additional elements, considered individually and in combination, do not integrate the recited abstract idea into a practical application for the reasons set forth below.
(A) The recited computing components are generic and merely apply the abstract idea. The “system,” “user computing device,” “third-party computing device,” “network,” and “third-party application” are recited at a high level of generality and perform no function beyond serving as tools by which the account-opening and transaction steps are carried out. Applicant’s specification confirms the generic nature of these components: the user device “may include any sort of computing device, such as a smartphone, personal computer, a wearable computing device (e.g., eyewear, a watch or bracelet, etc.), a tablet, a portable gaming device, a laptop, and any other form of computing device (e.g., a smart appliance, a smart speaker, etc.)” (¶ [0065]), and processing components “may be provided as one or more general-purpose processors” (¶ [0157]). Such recitations amount to mere instructions to implement the abstract idea on a computer, which is insufficient to integrate the exception into a practical application. See MPEP 2106.05(f).
(B) The claim does not recite an improvement to the functioning of a computer or to any other technology. The specification asserts at paragraph [0042] that the disclosed arrangement reduces “the number of communications sessions that is required for setting up accounts and arranging payments,” such that “the clock time, processing time, programmatic instructions …, memory utilization, and other system resources are reduced.” However, claim 1 does not recite any limitation that captures this asserted improvement. Claim 1 does not recite the number of authenticated communication sessions, any session-management operation, any authentication architecture, or any other technical mechanism by which computing resources are conserved. Where an asserted improvement is described in the specification but is not reflected in the claim, the claim cannot be said to integrate the exception into a practical application on the basis of that improvement. See MPEP 2106.05(a) (“the claim must include the components or steps of the invention that provide the improvement described in the specification”).
Moreover, the benefit actually recited in the claim — that “the one or more interface elements are presented within the third-party application without directing the user to a second application,” and that “the new account is established without directing the user to a second application” — is a business and convenience advantage rather than a technological improvement. The specification characterizes this benefit in commercial terms: it “saves time and effort for the user” and “allows the service provider to maintain some control over the user experience (by, e.g., selecting what perceptible elements are presented …)” (¶ [0149]), it reduces “the likelihood that the customer will not return to the service provider” (¶ [0150]), and it “incentivizes service providers to partner with the financial institution, thereby establishing more accounts at and bringing more customers to the financial institution” (¶ [0150]). These are improvements to a commercial relationship and to a user’s experience of a business transaction; they are not improvements to the operation of a computer, a network, a memory, or any other technology. See MPEP 2106.05(a).
(c) The “code” and “parsing” limitations do not impose a meaningful limit. The recited “code” is defined solely by the informational content it carries — identifiers of the provider, of the third-party device, and of the account type — and is “generated … based on a format designated by the provider.” Neither the code’s data structure, nor the manner of its generation, nor any technical problem it solves is recited. Correspondingly, “parsing the code to obtain the identifier[s]” recites nothing more than generic extraction of data fields from a formatted data string. These limitations amount to nominal data formatting and data retrieval in service of the commercial interaction, and do not use the exception in a meaningful way beyond generally linking it to a technological environment. See MPEP 2106.05(e), (h).
(D) The “encoding” limitation is recited in result-oriented terms. The limitation “at least a portion of the second set of user data is encoded by the user computing device and is incapable of being decoded by the third-party computing device” recites the result to be achieved (data that the intermediary cannot read) without reciting how that result is achieved. No encoding algorithm, cryptographic primitive, key generation or exchange operation, protocol, or other technical mechanism is recited. It is noted that claim 1 does not even recite encryption. A limitation that states a desired outcome without reciting the technical means of accomplishing it does not integrate a judicial exception into a practical application. See MPEP 2106.05(a); Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350 (Fed. Cir. 2016).
(E) The remaining limitations constitute insignificant extra-solution activity and field-of-use limitations. The steps of “receiving … a request,” “providing one or more interface elements,” “receiving … an account open request,” and “transmitting … the set of account data” constitute mere data gathering, data output, and data transmission over a network, which are recognized as insignificant extra-solution activity. See MPEP 2106.05(g). Further, the confinement of the abstract idea to the environment of a “third-party application” and to the opening of financial accounts is a field-of-use limitation that does no more than generally link the exception to a particular technological environment or field of use. See MPEP 2106.05(h).
Because the additional elements do not improve the functioning of a computer or other technology, do not apply the exception with a particular machine, do not effect a transformation of an article, and do not apply or use the exception in some other meaningful way beyond generally linking it to a technological environment, claim 1 does not integrate the recited abstract idea into a practical application. Claim 1 is therefore directed to an abstract idea, and the analysis proceeds to Step 2B.
Step 2B: Whether the Additional Elements Amount to Significantly More
The additional elements identified above have been reevaluated, both individually and as an ordered combination, to determine whether they provide an inventive concept.
Individually, each additional element is a well-understood, routine, and conventional computer component or function employed in a conventional manner:
The generic computing components — the provider system, the third-party computing device, the user computing device, and the network — perform only the functions of receiving data, storing data, processing data, and transmitting data over a network. Receiving or transmitting data over a network, electronic recordkeeping, and performing repetitive calculations are recognized by the courts as well-understood, routine, and conventional computer functions. See MPEP 2106.05(d)(II)(i)–(iv); Alice, 573 U.S. at 225–26; buySAFE, 765 F.3d at 1355; OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359 (Fed. Cir. 2015). Applicant’s specification supports this finding, describing these components in generalized and functional terms and expressly contemplating implementation on “general purpose computing computers in the form of computers, including a processing unit, a system memory, and a system bus” (¶ [0158]) and on “general-purpose processors” (¶ [0157]).
Pre-populating interface elements with previously collected user data is a conventional data-handling function. The specification describes this operation as reusing “information already received from a user computing device” (¶ [0037]) and “‘prefill[ing]’ one or [more] of the data fields of the form by inserting answers into the data fields corresponding with the questions for which answers have already been entered” (¶ [0134]). Prefilling a form with data already on hand is a routine and conventional use of stored data and is not described in the specification as requiring any unconventional programming or hardware.
Generating a code in a designated format, encoding data, and parsing the code are generic data formatting, data encoding, and data extraction operations. The specification describes the code in purely functional terms as a “number in a format designated by or known to the financial institution computing device,” having “a first portion uniquely identifying the financial institution, a second portion uniquely identifying the service provider, a third portion uniquely identifying the type of account, [and] a fourth portion indicating when the code was generated” (¶ [0137]). No unconventional technique for generating, encoding, or parsing such a code is disclosed or claimed. Such operations are well-understood, routine, and conventional functions of a general-purpose computer. See MPEP 2106.05(d)(II).
As an ordered combination, the additional elements add nothing that is not already present when the elements are considered individually. The claim as a whole recites the abstract idea of opening an account and supplying the account data for a transaction, implemented on a conventional client–server network arrangement in which a user device communicates with an intermediary’s device, which in turn communicates with a provider’s system. The claimed ordering — receive information, present a partially completed application, receive further information with an accompanying identifier, validate, open the account, return the account data — follows the ordinary and expected sequence of the commercial practice itself and does not reflect a non-conventional or non-generic arrangement of components. The combination therefore does not supply an inventive concept. See Alice, 573 U.S. at 225 (“the mere recitation of a generic computer cannot transform a patent-ineligible abstract idea into a patent-eligible invention”); MPEP 2106.05(I)(A).
For completeness, the limitations identified above as insignificant extra-solution activity under Prong Two (the receiving, providing, and transmitting steps) have been reevaluated under Step 2B and are determined to be well-understood, routine, and conventional for the reasons stated in item (1) above.
Applicant’s attention is directed to paragraphs [0038]–[0041] of the specification, which state that certain aspects of the disclosure are “unconventional.” These statements are respectfully noted; however, they are directed to the business practice — that is, to the practice of permitting a third party to present an account-opening offer without directing the user to the financial institution’s own website, and to the practice of making a new account immediately usable — rather than to any unconventional technical component, function, or arrangement recited in the claim. An assertion that a commercial practice is unconventional does not establish that the additional elements recited in the claim are other than well-understood, routine, and conventional. The inquiry under Step 2B is directed to the additional elements, not to the judicial exception itself. See MPEP 2106.05(d), (I).
Accordingly, the additional elements of claim 1 do not amount to significantly more than the recited abstract idea, and claim 1 is ineligible under 35 U.S.C. § 101.
Claim 16
Step 1: Claim 16 recites “A method, implemented by an institution computing system of a provider institution, of providing account open functionality through a service provider computing device of a service provider, the method comprising” a series of steps, and therefore falls within the statutory category of a process.
Step 2A, Prong One: Claim 16 recites substantially the same abstract idea as claim 1 — opening a financial account for a user and providing the resulting account data for use in a transaction — which is a fundamental economic practice and a commercial interaction within the “certain methods of organizing human activity” grouping. The offending limitations are: “receiving … a request for account open functionality, … the request comprising a first set of user data of the user stored in association with the third-party account”; “providing … one or more interface elements …, at least a subset of the one or more interface elements generated pre-populated with the first set of user data”; “receiving … an account open request comprising a second set of user data … and a code”; “establishing a new account for the user of the user computing device at least in part by: (i) parsing the code …, (ii) validating the first set of user data or the second set of user data using the code, and (iii) upon validating …, generating a set of account data associated with the new account”; and “transmitting the set of account data to the service provider computing device for use by the service provider computing device in a transaction with the user computing device.”
Step 2A, Prong Two: The additional elements of claim 16 are those identified with respect to claim 1, with the further recitation that the interface elements are “invoking an application programming interface (API) of the provider institution to access the account open functionality,” and the further recitation that “the new account is established while the user uses the first application without directing the user to a second website of the provider institution or a second application of the provider institution.”
The recitation of an API does not integrate the abstract idea into a practical application. An application programming interface is a generic software construct recited here solely at the level of its function — enabling one system to request data or functionality from another. No particular API architecture, call structure, protocol, data schema, or technical problem addressed thereby is recited. The specification describes the API in correspondingly generic terms, as one of a plurality of interchangeable interfaces maintained in an “API bank” for the purpose of “facilitat[ing] the sharing of varying types of information with different third parties” (¶ [0062]; see also ¶¶ [0050], [0110]). Reciting an API to exchange data between two generic computing systems amounts to mere instructions to implement the abstract idea using a conventional software interface and generally links the exception to a technological environment. See MPEP 2106.05(f), (h).
The additional limitation that the account is established “without directing the user to a second website of the provider institution or a second application of the provider institution” is, as discussed with respect to claim 1, a statement of a business and convenience outcome rather than a technological improvement, and is recited without any technical mechanism for achieving it.
The remaining additional elements of claim 16 — the institution computing system, the service provider computing device, the user computing device, the telecommunications network, the first application, the generically recited “code” and the parsing thereof, and the result-oriented recitation that “at least a portion of the second set of user data is encoded by the user computing device and is incapable of being decoded by the service provider computing device” — are analyzed as set forth above with respect to claim 1 and likewise fail to integrate the exception into a practical application.
Step 2B: For the reasons given with respect to claim 1, the additional elements of claim 16 are well-understood, routine, and conventional. With respect to the API in particular, the use of an application programming interface to request and receive data between computing systems is a well-understood, routine, and conventional function, as reflected by the specification’s treatment of APIs as interchangeable, pre-existing, and selectable from a “bank” of such interfaces (¶¶ [0050], [0062], [0110], [0115]–[0117]). The ordered combination adds nothing beyond the sum of its conventional parts.
Claim 16 is therefore ineligible under 35 U.S.C. § 101.
Claim 20
Step 1: Claim 20 recites “An institution computing system … comprising: a network interface configured to communicate with the service provider computing device via a telecommunications network; and one or more processors and memory having stored thereon instructions …” Claim 20 therefore falls within the statutory category of a machine.
Step 2A, Prong One: Claim 20 recites the same abstract idea as claims 1 and 16 — opening a financial account and providing the resulting account data for use in a transaction — as set forth in the limitations directing the system to “receive … a request for account open functionality”; “provide … one or more interface elements … pre-populated with the first set of user data”; “receive … an account open request comprising a second set of user data … and a code”; “establish a new account … at least in part by: (i) parsing the code …, (ii) validating the first set of user data or the second set of user data using the code, and (iii) upon validating …, generating a set of account data associated with the new account”; and “transmit … the set of account data … for use … in a transaction with the user computing device.” That the abstract idea is recited as instructions executed by a system rather than as method steps does not alter the Prong One determination. See MPEP 2106.04(a); Alice, 573 U.S. at 226–27 (system claims reciting the same abstract idea as method claims fail for substantially the same reasons).
Step 2A, Prong Two: The additional elements of claim 20 comprise those of claim 16, together with (i) the recited hardware — “a network interface,” “one or more processors,” and “memory having stored thereon instructions that, when executed by the one or more processors, cause the institution computing system to” perform the recited operations — and (ii) the further recitation that the code is “encrypted by the service provider computing device according to an encryption format different from the format designated by the provider institution.”
The recited network interface, processors, and memory are generic hardware components that merely provide the environment in which the abstract idea is carried out. The specification describes these components in wholly generic terms (¶¶ [0155]–[0158]), including that “[e]ach processor may be provided as one or more general-purpose processors” (¶ [0157]). Reciting generic hardware to perform an abstract idea constitutes mere instructions to apply the exception using a computer as a tool. See MPEP 2106.05(f).
The encryption limitation has been carefully considered but does not integrate the abstract idea into a practical application. The limitation requires only that the code be “encrypted … according to an encryption format,” and that the encryption format be “different from the format designated by the provider institution.” No particular encryption algorithm, cipher, key length, key generation or distribution mechanism, handshake, or protocol is recited, nor is any technical problem in the field of data security identified and solved by the claimed arrangement. The requirement that one format merely differ from another format imposes no meaningful technical constraint. The specification likewise describes encryption at a functional level, stating only that “[t]he tokens or digital certificate may be encrypted via an encryption key specific to the third party” (¶ [0116]). The encryption operation is thus employed as a conventional tool to protect data in the course of carrying out the abstract commercial interaction, and does not reflect an improvement to computer functionality or to computer security technology. See MPEP 2106.05(a), (f).
Step 2B: The additional elements of claim 20 do not amount to significantly more. Generic processors, memory, and network interfaces performing the functions of receiving, storing, processing, and transmitting data are well-understood, routine, and conventional computer components performing well-understood, routine, and conventional functions. See MPEP 2106.05(d)(II)(i)–(iv). With respect to encryption, performing encryption and decryption using a general-purpose computer is likewise recognized as a well-understood, routine, and conventional computer function. See MPEP 2106.05(d)(II). Applicant’s specification does not describe the encryption operation as requiring any unconventional algorithm, hardware, or arrangement, and indeed treats encryption as an available and conventional measure to be applied to tokens and certificates (¶ [0116]). Considered as an ordered combination, the elements of claim 20 recite the abstract idea implemented on conventional hardware with conventional data encoding, encryption, and formatting, arranged in the ordinary manner, and therefore do not supply an inventive concept.
Claim 20 is therefore ineligible under 35 U.S.C. § 101.
Dependent Claims
The dependent claims have been considered and do not recite additional elements that integrate the abstract idea into a practical application or that amount to significantly more than the abstract idea.
Claims 2 and 17 further recite that the interface elements “invoke an application programming interface (API) of the provider” (claim 2) and that the institution computing system “provides the account open functionality through the first application via a software development kit (SDK) of the provider institution” (claim 17). An API and an SDK are generic software constructs recited solely at the level of their functions. As discussed with respect to claim 16, the specification treats APIs and SDKs as pre-existing, interchangeable, and conventional tools for sharing information and for integrating functionality into third-party platforms (¶¶ [0034], [0050], [0062], [0083], [0110]). These recitations amount to instructions to implement the abstract idea using conventional software interfaces and generally link the exception to a technological environment. MPEP 2106.05(f), (h). They are further well-understood, routine, and conventional under Step 2B. MPEP 2106.05(d).
Claim 3 further recites that “the one or more interface elements include one or more software development kits (SDKs).” This limitation is addressed by the analysis of claims 2 and 17 above.
Claims 4 and 18 further recite that the account open request is transmitted “in response to a signal, received via the third-party application, indicating the user has selected to open the new account with the provider.” Receiving a user selection and initiating a responsive action is a generic user-input function of a computing device and constitutes insignificant extra-solution data gathering. MPEP 2106.05(g). The limitation further specifies a step of the commercial interaction itself — that the customer elects to open the account — and thus in part further recites the abstract idea.
Claims 5, 6, 7, and 8 further recite the presentation of “visually perceptible elements associated with the third-party” and “visually perceptible elements associated with the provider” at specified points relative to the user’s selection. These limitations recite the generic display of information by a computing device and specify only what is displayed and when — namely, branding indicia. The specification identifies these elements as “a logo, an image …, and a text style (e.g., font, size, color, line spacing, indentation, etc.)” that “help identify and brand the service provider” (¶ [0145]) and “help identify and brand the financial institution” (¶ [0147]). Displaying branding indicia to control the commercial presentation of a transaction is directed to the commercial interaction and to the user’s experience of it; no improvement to display technology, to a graphical user interface as a technology, or to the functioning of the computing device is recited. Generic display of information is further recognized as a well-understood, routine, and conventional computer function. MPEP 2106.05(d)(II)(iv), 2106.05(f).
Claims 9 and 19 further recite that the first set of user data includes “a first user data subset received … before the third-party application receives a user request to open the new account” and “a second user data subset received … after the third-party application receives the user request.” These limitations merely specify the timing and source of the data collection and constitute insignificant extra-solution data gathering. MPEP 2106.05(g). They further recite additional detail of the abstract commercial practice of collecting application information from a customer.
Claim 10 further recites that “the third-party application presents a form having a set of fields into which the user enters user data …, wherein a subset of the set of fields of the form are prefilled by the third-party computing device using the first user data subset.” Presenting a data-entry form and prefilling fields with data already on hand are conventional data-handling and display functions, described in the specification without reference to any unconventional technique (¶¶ [0134], [0146]). This limitation does not integrate the exception into a practical application and is well-understood, routine, and conventional.
Claims 11, 12, and 13 further recite “accepting a transaction amount indicating how much funds are to be transferred into or out of the new account, and processing the transaction with the new account, the transaction involving a funds transfer between the third-party and the user” (claim 11); that “the new account accepts automated payments via the third-party” (claim 12); and “using the new account to make a payment to the third-party for a purchase made by the user using the third-party application” (claim 13). These limitations recite further aspects of the abstract idea itself — the transfer of funds and the making of payments are quintessential fundamental economic practices. See MPEP 2106.04(a)(2)(II)(A). Further limiting a judicial exception with additional recitations of the exception does not render the claim eligible. These claims accordingly do not add any additional element for consideration under Prong Two or Step 2B, and they further entrench the abstract character of the claimed subject matter.
Claim 14 further recites that “the first set of user data is displayed within the subset of the one or more interface elements.” Displaying data is a generic computer output function and insignificant extra-solution activity, and is well-understood, routine, and conventional. MPEP 2106.05(d)(II)(iv), 2106.05(g).
Claim 15 further recites that “the code further comprises an expiration time, and wherein the new account is established responsive to determining that the expiration time satisfies a predetermined time period.” Determining whether a time value satisfies a predetermined period is a generic comparison operation that can be performed as a mental evaluation and that a general-purpose computer performs in a well-understood, routine, and conventional manner. The specification describes the expiration feature functionally and without any technical detail, stating only that the code may include “a fourth portion indicating when the code was generated and/or should be deemed expired (e.g., 10 minutes from time of code generation)” (¶ [0137]). No cryptographic binding, replay-protection protocol, or other technical mechanism is recited. This limitation therefore neither integrates the exception into a practical application nor amounts to significantly more.
Conclusion
For the foregoing reasons, claims 1–20 are directed to an abstract idea within the “certain methods of organizing human activity” grouping — specifically, a fundamental economic practice and commercial interaction comprising opening a financial account for a user and providing the resulting account data for use in a transaction — without reciting additional elements that integrate the exception into a practical application under Step 2A, Prong Two, or that amount to significantly more than the exception under Step 2B. Claims 1–20 are accordingly rejected under 35 U.S.C. § 101.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 9, 11, 12, 13, 15 and 19 are rejected under 35 U.S.C. § 103 as being unpatentable over Chen (US 2015/0339767) in view of Carrott (US 2016/0132877) and Drury (US 2015/0088707).
A. Claim 1
A.1 Chen teaches the following limitations
“A method implemented by a system associated with a provider”
“A system comprising: a non-transitory memory storing a merchant account for a user; and one or more hardware processors in communication with the non-transitory memory and configured to …” Chen, claim 1 and 10. See also Chen, ¶¶ [0050]–[0055] (payment provider server 160 comprising mobile development application 162, payment processing application 170, database 166, and network interface component 168).
“receiving, in response to an interaction with a first interactive element displayed via a third-party application of a third-party executing on a user computing device of a user, a request for account open functionality accessible to a third-party computing device of the third-party via a network”
Chen discloses that the provider furnishes an account-establishment interface to the third party for incorporation into the third party’s own application, and then receives an account-open request originated through that interface:
“A service provider, such as a payment provider, may offer merchants a development kit that includes various processes and features the merchants may implement in mobile applications that offer ordering, payment, and account establishment with the merchant to consumers. A merchant may utilize the development kit to receive a payment application, including an account establishment application interface. The merchant may implement the development kit in a merchant application so that the merchant may utilize the account establishment application interface within the merchant application.” Chen, ¶ [0012].
“receive a request to register a merchant account by the user from a merchant application for a merchant, wherein the merchant application utilizes an account establishment application interface.” Chen, claim 1.
“receiving a request to register a first payment account from the user using a merchant application for a merchant, wherein the merchant application utilizes an application interface provided by a payment provider, and wherein the application interface allows the user to transmit the request to register the first payment account.” Chen, claim 18.
“At step 402, a merchant is provided with an account establishment application interface for registering a provisional account with the merchant … A request to register the provisional account is received by the user from a merchant application for the merchant, at step 404, wherein the merchant application utilizes the account establishment application interface.” Chen, ¶ [0069].
The request is initiated by the user’s interaction with a selectable element of that interface displayed within the merchant application:
“account establishment page 322 includes interface options to enter account information, such as user information 324 field, personal information 326 field, and log in through payment account 328 field … the user may be given a choice to ‘log in through payment account 328.’” Chen, ¶ [0064].
“the user having a third-party account with the third-party, the request comprising a first set of user data of the user stored in association with the third-party account”
“when establishing a user account, the user may be offered to ‘log in’ using the payment provider, where the user’s provisional account with the merchant is immediately synchronized to a previous payment account with the payment provider using the entered credentials for the payment account.” Chen, ¶ [0014].
“the user may then choose to log in to the payment provider in order to share the provisional account information with an account the user has established with the payment provider.” Chen, ¶ [0014].
See also Chen, ¶¶ [0028]–[0029], [0053]–[0054].
“providing one or more interface elements associated with the account open functionality for presentation via the third-party application, the one or more interface elements generated for presentation at the user computing device of the user via the third-party application associated with the third-party, at least a subset of the one or more interface elements pre-populated with the first set of user data associated with the user and received in the request”
“logging in to the payment account may cause the entered information in the account establishment application interface of merchant application 120 to be matched with the payment account’s information and missing information to be populated to the merchant account with merchant device 140. Merchant device 140 may receive the most relevant information for the profile, wallet, and histories.” Chen, ¶ [0029].
“The interface may be provided to merchant device 140 for use in merchant application 120 by payment provider server 160.” Chen, ¶ [0027].
“mobile development application 162 may include a process and/or interface used to add an account creation and/or establishment application interface in merchant application 120.” Chen, ¶ [0052].
“wherein the one or more interface elements are presented within the third-party application without directing the user to a second application”
“The merchant may implement the development kit in a merchant application so that the merchant may utilize the account establishment application interface within the merchant application.” Chen, ¶ [0012].
“the user may establish an account with the merchant using the merchant application.” Chen, ¶ [0061].
“communicate the merchant account to the merchant for use by the user in the merchant application.” Chen, claim 1.
“receiving, from the third-party computing device via the network, an account open request comprising a second set of user data”
“The account establishment application interface in the merchant application may allow for a user to enter personal and/or financial information in order to effectuate payments to the merchant.” Chen, ¶ [0012].
“Personal information 326 may correspond to additional information requested for the provisional merchant account, such as a name, address, and/or billing address for the user.” Chen, ¶ [0064].
“processing first payment account with user information for the user, wherein the user information comprises personal information and financial information for the user.” Chen, claim 19.
“wherein the account open request is for a new account with the provider”
“generating the first payment account for the user using the request; and transmitting the first payment account to a user device for the user for use by the user in the merchant application.” Chen, claim 18.
“wherein the second set of user data is received at the third-party computing device from the user computing device via the third-party application”
“When utilizing merchant application 120 to checkout and complete a payment with merchant device 140, user 102 may enter personal and/or financial information that may be utilize to generate a profile for user 102 and a digital wallet.” Chen, ¶ [0027]; see also ¶¶ [0012], [0044], [0064].
“establishing the new account” and “generating a set of account data associated with the new account using the first set of user data and the second set of user data”
“generating the first payment account for the user using the request.” Chen, claim 18.
“The request to register the provisional account is processed, at step 406.” Chen, ¶ [0070].
“When establishing the merchant account, a profile for user 102 may be determined, having information such as a name, address, birthdate, interests, and/or desired items for user 102. The merchant account may further include a digital wallet having payment instruments for user 102 (e.g., payment cards, payment accounts, bank accounts, etc.), benefits, received offers and/or upsells, and loyalty information.” Chen, ¶ [0044].
Chen expressly teaches that the account data so generated is derived from both the data held in the user’s pre-existing account and the data newly entered through the interface:
“Synchronization of accounts may share the provisional account’s profile information, digital wallet, and transaction histories with the payment account’s profile information, digital wallet, and transaction histories. Thus, the most recent information may be updated, or the profile, digital wallet, and/or transaction histories may be updated to reflect information in one account that is not possessed by the other account.” Chen, ¶ [0014].
“the entered information … [is] matched with the payment account’s information and missing information … populated to the merchant account.” Chen, ¶ [0029].
“at least a portion of the second set of user data … is incapable of being decoded by the third-party computing device”
Chen expressly teaches withholding specified user data from the merchant and supplies the motivation for doing so:
“the merchant may be prevented from obtaining certain information, such as sensitive payment instrument information not originally shared with the merchant (e.g., a payment card the user has chosen to not share with the merchant …). Other sensitive information that may be redacted from sharing with the provisional account may include receipts in the user’s transaction history with other merchant.” Chen, ¶ [0015].
“payment provider server 160 may redact or omit information from the payment account before sharing, updating, and/or generating the merchant account … Thus, if user 102 does not wish to share certain information with merchant device 140, the information may be redacted/omitted from the payment account.” Chen, ¶¶ [0030], [0045].
“determine available merchant information in the payment account, wherein the available merchant information comprises information available to the merchant … after redacting sensitive information from the digital wallet and the transaction history.” Chen, claim 5.
“transmitting the set of account data to the third-party computing device for use by the third-party computing device in a transaction involving the user computing device via the third-party application”
“communicate the merchant account to the merchant for use by the user in the merchant application.” Chen, claim 1.
“At step 408, the provisional/merchant account is communicated to the merchant for use by the user in the merchant application.” Chen, ¶ [0070].
“payment provider server 160 may provide sales application 150 with information from a payment account … The provisional or synchronized merchant account may then be used to checkout and complete the purchase order.” Chen, ¶ [0044].
“generating a payment code for the payment request; and communicating the payment code to a user device for the user” (claim 14), “wherein the payment code is displayed on the user device, and wherein the merchant inputs the payment code to fulfill payment for the payment request” (claim 15). Chen, claims 14–15; ¶ [0071].
A.2 Chen does not expressly disclose the code limitations. Carrott teaches:
“a code generated by the third-party computing device”
“causing, by said intermediate entity, said provider device to encrypt provider input related to said transaction to create an encrypted one-time-use provider code using a one-time-use provider encryption key produced, in part, using a uniquely sequenced number generated by a provider sequencer maintained by said provider device.” Carrott, claim 11; see also claims 1, 6, 16.
“A similarly structured OTUC is generated for each program provider, allowing the bank or other intermediate, under agreement with and instruction from each party, to bind each party to each transaction.” Carrott, ¶ [0057].
“the code comprising (i) an identifier of the provider, (ii) an identifier of the third-party computing device, and (iii) an identifier of a type of account to open”
“The OTUC is a single-use code that is formed using elements of the following. For the user: 1) user identifier values …; 2) the user’s account number with the acquiring bank; 3) the provider’s transaction/session number; 4) a transaction sequencer … For the provider: 1) provider identifier values …; 2) The provider’s account number with the bank; 3) the provider’s transaction or session number.” Carrott, ¶ [0124].
“The OTUC is the body of what both sides of the transaction sends to the bank cloud. It includes the transaction identification, the account identification in unencrypted form, and the encrypted string. In one specific example, the app can create the OTUC as follows: <transaction_id>::<account_id>::<encrypted_data>.” Carrott, ¶ [0098].
“the data that is encrypted includes the details of the transaction … and can optionally include the user/provider account numbers …, an identification of the type of transaction (purchase vs. authorization), the contract identifier, selection of payment method (e.g., identification of a card type or bank name, without including any card numbers or bank account numbers).” Carrott, ¶ [0139].
“verify that device_id belongs to account_id.” Carrott, ¶ [0104].
“the device’s identifiers are an integral part of the one-time-use code.” Carrott, ¶ [0057].
“the code generated by the third-party computing device based on a format designated by the provider”
“the intermediate entity provides a computer program application to each registered user and provider, and such applications allow the intermediate entity to control certain operations of the user devices and provider devices and cause the user and provider devices to take certain actions.” Carrott, ¶ [0128].
“the intermediate entity/bank generates the app that is installed on each provider and user device. This app is remote and, when activated, generates a new one-time-use code (OTUC), encrypted, using the new sequencer as a unique encryption key.” Carrott, ¶ [0150].
“Providers, after enrollment, download the bank’s application programming interface (API) that provides the secure linkage to the bank’s platform for program transactions. The API includes a provider app that generates the provider’s one-time-use code.” Carrott, ¶ [0060]; see also ¶ [0122].
“parsing the code to obtain the identifier of the provider, the identifier of the third-party computing device, and the identifier of the type of account to open”
“Step 1, split the elements: turn <transaction_id>::<account_id>::<encrypted_data> into: transaction_id = <transaction_id>; account_id = <account_id>; encrypted_data = <encrypted_data>.” Carrott, ¶¶ [0100]–[0101].
“Step 2, take the account_id and look up the Account … Step 4, decrypt the encrypted string using the key. The methods now have the key→value pairs of information that was encrypted.” Carrott, ¶¶ [0101], [0103].
“validating the first set of user data or the second set of user data using the code”
“Step 5, verify that device_id belongs to account_id, and that the amount of both sides (merchant side and consumer side) matches.” Carrott, ¶ [0104].
“With the decrypted provider and user information, the intermediate entity can check the user and provider registration records to verify the identities of the provider and user … the intermediate entity compares such previously encrypted additional identification information (e.g., the actual user/provider account number) with the corresponding data stored within the intermediate entity (at registration) to help verify the identity of the user and provider attempting to complete a transaction.” Carrott, ¶¶ [0144], [0156].
“at least a portion of the second set of user data is encoded by the user computing device”
“causing, by said intermediate entity, said user device to encrypt user input related to said transaction to create an encrypted one-time-use user code using a one-time-use user encryption key produced, in part, using a uniquely sequenced number generated by a user sequencer maintained by said user device.” Carrott, claim 11; see also claim 16.
Independent transmission; combination into a single request; addition of the user’s financial data by the institution
“causing, by said intermediate entity, said provider device to transmit said one-time-use provider code and said unique transaction number only to said intermediate entity … causing, by said intermediate entity, said user device to transmit said one-time-use user code and said unique transaction number only to said intermediate entity.” Carrott, claim 16; see also claim 11 (“independently transmit”).
“combining, by said intermediate entity, said unencrypted provider input and unencrypted user input into a single authorization request.” Carrott, claim 16.
“the intermediate entity can retrieve financial information obtained during user/provider registrations … and add such financial information of the user and/or provider (potentially in unencrypted form) to the single authorization request.” Carrott, ¶ [0157].
A.3 Drury further teaches the composite code, its designated format, and validation
“The financial institution assembles a BLOB of data (e.g., the AccountMapMessage …) containing information about the bank accounts that the user has opted to connect to the accounting software system.” Drury, ¶ [0143].
Instant Claim Element
Drury Field
Identifier of the provider
MessageContainer.PC = “PROVIDER/BANKXYZ”; AccountMapMessage.ProviderID — “Accounting system’s identifier for the financial institution.” Drury, ¶¶ [0193]–[0194]
Identifier of the third-party computing device
UserID; AccountID — “Financial institution’s account identifier. Globally unique.” Drury, ¶¶ [0192]–[0193]
Identifier of a type of account
AccountType — “CreditCard = 1, Current = 2, Savings = 3, Loan = 4, Investment = 5, Foreign = 6, Other = 7.” Drury, ¶ [0190]
Format designated by the recipient institution. Drury prescribes JSON structures with mandated field types and lengths (¶¶ [0190]–[0194]), mandated algorithms (“AES for symmetric encryption, the RSA algorithm … RSA-SHA2 for signing,” ¶ [0145]), and mandated minimum key sizes (“an AES or SHA key may be a minimum of 256 bits, and an RSA key may be a minimum of 2048 bits,” ¶ [0146]).
Parsing and validation.
“EncryptedIV = Base64Decode(MessageContainer.EIV) … IVBytes = RSADecrypt(EncryptedIV, X_PrivKey); … AccountMapMessage = Base64Decode(PlainTextDataString).” Drury, ¶¶ [0167]–[0177].
“Validating the origin of the message may be performed by verifying that the Check AccountMapMessage.ProviderID matches MessageContainer.PC. Validating that the message is current may be performed by verifying that TimeStampUTC is within the tolerance for valid messages, and the message has not expired. Validating that the message is not a replay attempt may be performed by verifying that the (TimeStampUTC, Nonce) pair have not been used for this provider.” Drury, ¶ [0178]; see also ¶¶ [0197]–[0207].
A.4 Regarding “encoded by the user computing device and is incapable of being decoded by the third-party computing device”
This limitation is taught by the combination of Carrott and Drury, with motivation supplied by Chen.
Carrott teaches that the user’s own device performs the encoding and that the intervening provider never obtains the encoded data:
“causing, by said intermediate entity, said user device to encrypt user input related to said transaction to create an encrypted one-time-use user code.” Carrott, claim 11.
“said encrypted one-time-use provider code and said encrypted one-time-use user code being devoid of personal financial information of said user.” Carrott, claims 5, 10, 15, 20.
“at the inception of the transaction … through to when the provider is notified of approval/denial of the transaction …, the provider is never given any information about the user. By preventing the provider from ever obtaining any information about the user, the provider is freed of the responsibility and cost of keeping any user information safe, and the user is more confident that their identity and personal information is secure.” Carrott, ¶ [0163].
Drury teaches the pass-through condition — the payload is rendered unreadable to the party relaying it:
the data “can be encrypted so the data within is opaque to the client browser transferring it.” Drury, ¶ [0143].
“The message encryption and packaging described above may be implemented to allow messages to pass from the financial institution to the accounting software system over an untrusted communication mechanism (e.g., over the Internet via the user’s browser).” Drury, ¶ [0180].
“The encryption and signing may provide guarantees that the message was legitimately generated by the financial institution, not tampered with or viewed in transit, and cannot be replayed. The financial institution can also be assured that only the accounting software system will be able to decrypt the data.” Drury, ¶ [0181].
“Information Disclosure: The AccountMapMessage may contain some sensitive information … This is encrypted using a one-time-use encryption key. The encryption key is transmitted in the message, but is encrypted asymmetrically using the accounting software system’s public key, which only the accounting software system can decrypt.” Drury, ¶ [0185].
Chen supplies the motivation in the account-establishment context, expressly identifying the need to prevent the merchant from obtaining specified user information. Chen, ¶¶ [0015], [0030], [0045]; claim 5.
It would have been obvious to one of ordinary skill in the art to encode a portion of the second set of user data at the user computing device such that the third-party computing device relaying that data cannot decode it, as taught by Carrott and Drury, in order to achieve the data-confidentiality objective Chen expressly identifies. MPEP 2143(I)©, (G).
A.5 Regarding the “without directing the user to a second application” limitation
Note on Drury. Drury discloses redirecting the user from the financial institution to the accounting software system (¶¶ [0120], [0129], [0189]). Drury is not relied upon for this limitation. Drury is relied upon solely for the composite code structure, the institution-designated format, encryption, parsing, and nonce/timestamp validation. The presence in Drury’s particular embodiment of a redirection step does not diminish its teaching of those separately identified features, which one of ordinary skill would have applied within a non-redirecting architecture.
The no-redirect limitation is taught by Chen (¶¶ [0012], [0061]; claim 1) and is additionally taught by Dhar, as applied in Rejection II.
B. Claims 9 and 19
Claims 9 and 19 recite that the first set of user data includes a first user data subset received before the third-party application receives the user request to open the new account, and a second user data subset received after the request.
Chen discloses both. Information held in the user’s pre-existing provider account exists prior to the registration request (¶¶ [0014], [0028]–[0029]); information is entered through the account-establishment interface after the request is initiated (¶¶ [0012], [0027], [0064]); and the two are reconciled such that “missing information [is] populated to the merchant account” (¶ [0029]).
“Synchronization of accounts may share the provisional account’s profile information, digital wallet, and transaction histories with the payment account’s profile information, digital wallet, and transaction histories. Thus, the most recent information may be updated, or the profile, digital wallet, and/or transaction histories may be updated to reflect information in one account that is not possessed by the other account.” Chen, ¶ [0014].
Chen further discloses that the user may establish the provisional account first and synchronize with the held account thereafter:
“the user may not have previously established a provisional account with the merchant, and thus account sharing and synchronization may occur when the user establishes the provisional account … In other embodiments, the merchant’s application may immediately establish the account with the payment provider so that information entered in the merchant application … is immediately shared with the payment provider.” Chen, ¶ [0014].
Note. Claims 9 and 19 are entitled only to the May 7, 2019 effective filing date as determined in the Priority section. Each reference relied upon predates that date by a substantial margin.
C. Claims 11, 12 and 13
Claim 11 — accepting a transaction amount and processing the transaction involving a funds transfer between the third party and the user.
“processing … a payment request to the merchant using the account.” Chen, claim 10.
“processing a payment to the merchant for an order entered by the user using the merchant application, wherein the payment is processed using the financial information.” Chen, claim 20; see also ¶ [0070].
“payment processing application 170 may complete the sale transaction by providing payment from user 102 to merchant device 140.” Chen, ¶ [0055].
Carrott discloses accepting the transaction amount at the provider device and processing the resulting authorization through the institution to completion. Carrott, ¶¶ [0086], [0091]–[0092], [0112]; claim 16.
Claim 12 — the new account accepts automated payments via the third party.
“a payment provider offering financial transaction processing to the user … any accrued rewards, updates to personal information, and/or new payment instruments … added to a payment account/wallet.” Chen, ¶ [0003].
“the merchant may review transaction histories to establish common orders by the user … when the user utilizes the merchant’s application, the user may view a standard order or orders that the merchant populates with commonly purchased items by the user. This may expedite future purchases with the merchant.” Chen, ¶¶ [0015]–[0016].
Carrott discloses that the established account is used for subsequent recurring transactions initiated through the third party. Carrott, ¶¶ [0112]–[0113], [0119].
Claim 13 — using the new account to make a payment to the third party for a purchase made using the third-party application.
“providing a payment to the merchant for the order using the account; and communicating a transaction history for the payment to the user.” Chen, claim 12; see also claims 10, 20; ¶ [0071].
Carrott, ¶¶ [0108]–[0113].
D. Claim 15
Claim 15 recites that the code further comprises an expiration time, and that the new account is established responsive to determining that the expiration time satisfies a predetermined time period.
Drury discloses an expiration time carried within the third-party-generated code:
“TimestampUTC DateTime (e.g. “2000-12-29T00:00:00Z”) — The time that the message was constructed by the caller. Used to expire messages that have passed a timeout threshold.” Drury, ¶ [0193].
The TimestampUTC field is a constituent element of the AccountMapMessage — the same data structure that carries the provider identifier, account identifier, and AccountType. Drury, ¶ [0193] (AccountMapMessage field table); see also the corresponding C# class and JSON example at ¶ [0193].
Drury further discloses the determination that the expiration satisfies a predetermined period:
“Validating that the message is current may be performed by verifying that TimeStampUTC is within the tolerance for valid messages, and the message has not expired.” Drury, ¶ [0178].
And conditions the user’s ability to proceed on that determination as an express precondition:
“prior to allowing a user to manage an account, one or more of the following preconditions is verified … [0207] The timestamp is within a valid timeout period.” Drury, ¶¶ [0197], [0207].
Carrott likewise discloses that the transaction terminates if the process is not completed within the allowed timeframe:
“the transaction times out (e.g., there was a network error, or the consumer did not type in their PIN in the allowed timeframe).” Carrott, ¶ [0109].
Rationale. It would have been obvious to one of ordinary skill in the art to include an expiration time within the code and to condition establishment of the new account on satisfaction of that time period, in order to limit the window during which the code may be used and thereby reduce the risk of replay or unauthorized reuse. Drury expressly identifies this benefit:
“Replay: Replay attacks are prevented by a timestamp and nonce value, which allows the accounting software system to guarantee it will receive and process a given message only once. If a message arrives with the same timestamp and nonce, the accounting software system will reject the message.” Drury, ¶ [0186].
“the use of a short expiration against the message timestamp … As the user is not required to perform any action between the message generation and the immediate POST to the accounting software system, the expiration can be kept short.” Drury, ¶ [0187].
MPEP 2143(I)©, (G).
E. Rationale to Combine — Rejection I
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Chen to incorporate the third-party-generated composite code, the institution-designated code format, the user-device encoding, the identifier parsing, and the validation operations of Carrott and Drury.
All three references are directed to the same field of endeavor — establishing and servicing an account for a user through an intermediary computing platform communicating with a provider institution over a network — and each is reasonably pertinent to the problem addressed by the instant claims. MPEP 2141.01(a).
Motivation is supplied by Chen itself. Chen identifies the need to prevent the merchant from obtaining sensitive user information during account establishment (¶¶ [0015], [0030]; claim 5), but accomplishes this by provider-side redaction. Carrott supplies a known mechanism by which the third-party device assembles a structured composite code in a format prescribed by the receiving institution, the user’s own device encrypts its data so that the third party never obtains it, and each party transmits independently to the institution, which parses and validates before completing the transaction. Drury supplies the enumerated account-type field within such a message together with nonce and timestamp validation.
Applying these message-construction, encoding, and validation schemes to Chen’s account-establishment flow is the use of a known technique to improve a similar method in the same way, and addresses a need Chen expressly articulates. MPEP 2143(I)©, (G).
The combination yields no more than the predictable result of each reference performing its established function. MPEP 2143(I)(A).
REJECTION II
Claims 2, 3, 4, 5, 6, 7, 8, 10, 14, 16, 17, 18 and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over Chen in view of Carrott and Drury as applied to claim 1 above, and further in view of Dhar (US 2014/0143151).
The teachings of Chen, Carrott, and Drury are as set forth in Rejection I above and are incorporated here by reference.
A. Dhar is additionally relied upon for the following teachings
Provider system distinct from the third-party system; API call initiating the process
“In example embodiments, the merchant system 106 is distinct from the payment provider system 108 — that is, the merchant system 106 is different or separate from the payment provider system 108.” Dhar, ¶ [0015].
“the communication module 202 may receive a request (e.g., an API call) for payment or account information of the user of the user device 102 or to process a payment transaction from the merchant system 106.” Dhar, ¶ [0025].
“In operation 502, a purchase request is received. In example embodiments, the communication module 202 may receive a request (e.g., an API call) that initiates the payment process.” Dhar, ¶ [0046].
Provider-supplied interface presented within the third party’s site, with pre-populated fields
“causing presentation of a payment interface having transaction fields populated with the account information retrieved from the payment account of the user, the payment interface presented to the user while the user maintains a presence on a webpage of a merchant system.” Dhar, claim 1; see also claims 11, 16.
“The data module 206 retrieves and provides account information from the payment account for populating transaction fields on a payment interface which may be provided on a website of the merchant system … some of the account information may be provided to the merchant system 106 to populate (or pre-fill in) transaction fields on the payment interface provided on or associated with the website of the merchant system.” Dhar, ¶ [0027].
“the data module 206 or communication module 202 may provide the payment interface to the merchant system 106 to be displayed in association with the merchant website (e.g., as a pop-up over a merchant webpage or in fields on the merchant webpage) and/or provide instructions that cause the merchant system 106 to present the payment interface on their website.” Dhar, ¶ [0050].
Presentation without redirecting the user
“payment fields may be automatically prepopulated for the user without leaving a merchant’s website. As such, the user simply needs to confirm payment. Accordingly, one or more of the methodologies discussed herein may obviate, for example, a need for accessing a payment system or filling in fields of a payment form. This may have the technical effect of reducing computing resources used by one or more devices within the system.” Dhar, ¶ [0014].
“Upon selection of the checkout button 302, a pop-up interface 310 may be presented to the user … The user remains on the merchant’s website while the pop-up interface 310 is presented.” Dhar, ¶ [0031].
“It is noted that the user remains on the website provided by the merchant system 106 during the payment transaction process … the user may transact for an item (e.g., checkout) simply by entering, for example, an email address and a password, without having to leave the merchant’s website.” Dhar, ¶ [0037].
“the identifier interface is a pop-up interface presented over the webpage of the merchant system.” Dhar, claim 3; see also claims 13, 18.
Initiation in response to a user selection
“The user may be provided an option in the form of a checkout button 302 to checkout using a payment service … Upon selection of the checkout button 302, a pop-up interface 310 may be presented to the user.” Dhar, ¶¶ [0030]–[0031]; see also ¶¶ [0038]–[0039].
“If the user does not have a payment account with the payment provider system 108, the user may sign up for the payment account through the pop-up interface 310.” Dhar, ¶ [0031].
Display of user data within the populated interface elements
“the account information used to populate the payment interface comprises an address of the user” (claim 8); “the account information used to populate the payment interface comprises funding source information” (claim 9). Dhar, claims 8–9.
“The transaction fields may include, for example, a shipping address, billing address, and funding source information (e.g., default payment method).” Dhar, ¶ [0035].
“the pop-up interface 420 is a billing address interface where a billing address and a phone number of the user are populated into the transaction fields.” Dhar, ¶ [0040].
Withholding of data sufficient to prevent the third party from processing the transaction independently
“the shipping address and/or the funding source information may be partially redacted for security. In one embodiment, the funding source information may only indicate a funding method to be used, but does not provide enough financial account information that would allow the merchant system 106 to process the payment transaction.” Dhar, ¶ [0035].
B. Claims 2 and 3
Claim 2 — “the one or more interface elements invoke an application programming interface (API) of the provider to access the account open functionality.”
Dhar discloses receiving “a request (e.g., an API call) that initiates the payment process.” Dhar, ¶¶ [0025], [0046]. Carrott discloses that the institution provides the API to the provider for integration into the provider’s transactional platform. Carrott, ¶¶ [0060], [0122]. Drury discloses that the institution “exposes a number of services to the accounting software system” through “a small web service that accepts and responds to JSON POST requests,” with specified endpoints. Drury, ¶¶ [0208]–[0210]. Chen discloses that the account-establishment interface is “provided by a payment provider” and utilized by the merchant application. Chen, claim 18; ¶¶ [0027], [0052].
Claim 3 — “the one or more interface elements include one or more software development kits (SDKs).”
“mobile development application 162 may offer a development tool set, such as a software development kit, which may be used by merchant device 140 in order to create and/or modify an application offered by merchant device 140, such as merchant application 120 … [and] may include a process and/or interface used to add an account creation and/or establishment application interface in merchant application 120.” Chen, ¶ [0052].
“A service provider, such as a payment provider, may offer merchants a development kit … The development kit may include an account establishment interface that may be utilized in a merchant ordering and payment application for a merchant.” Chen, Abstract; ¶ [0012].
It would have been obvious to employ an API or SDK as the delivery mechanism for the interface elements of Chen, these being the conventional means of exposing provider functionality to a third-party application, and Chen’s disclosure being predicated on development-kit delivery.
C. Claims 4 and 18
Claim 4 (“the account open request is transmitted to the system in response to a signal, received via the third-party application, indicating the user has selected to open the new account with the provider”) and claim 18 (same, for the service provider computing device).
Dhar, ¶¶ [0030]–[0031], [0038]–[0039], [0046]. Chen discloses initiation of account registration in response to the user’s request via the account-establishment interface. Chen, claim 1; claim 18 (“the application interface allows the user to transmit the request to register the first payment account”); ¶¶ [0064], [0069].
Carrott discloses that the process is initiated in response to the user’s affirmative selection, whereupon the provider device generates the transaction number and code:
“Upon being notified by the user 108 that payment will occur using the methods and systems herein, the provider 100 activates their app (if not already active), chooses ‘receive payment’ from the options, enters the amount of the transaction …, then clicks ‘generate bill.’” Carrott, ¶ [0086].
D. Claims 5, 6, 7 and 8
These claims recite the presentation of visually perceptible elements associated with the third party and with the provider at specified points relative to the user’s selection signal and relative to receipt of the first and second sets of user data.
Dhar discloses a provider-associated interface presented over the third party’s page, followed by a second provider-associated interface, within a flow that begins and ends on the third party’s page. Dhar, claims 1–3; ¶¶ [0030]–[0036]. Dhar’s FIGS. 3A–3D depict the alternating sequence expressly: merchant shopping-cart page bearing the merchant’s own content and a provider-branded checkout button 302 (FIG. 3A; ¶ [0030]) → provider-associated identifier interface 310 presented as a pop-up over that page (FIG. 3B; ¶ [0031]) → provider-associated payment interface 322 with populated fields (FIG. 3C; ¶¶ [0034]–[0035]) → merchant confirmation page (FIG. 3D; ¶ [0036]). See also FIGS. 4A–4G; ¶¶ [0038]–[0044].
Chen discloses an account-establishment page displayed within the merchant application bearing provider-specific fields and a provider-branded selectable option (“log in through payment account 328”). Chen, ¶ [0064].
The particular sequencing recited in claims 5–8 — which set of visually perceptible elements is displayed before the signal, after the signal, after receipt of the first set of user data, and before receipt of the second set of user data — constitutes an obvious ordering of display steps. The sequence disclosed in Dhar teaches alternation between third-party and provider presentation across the flow. Selecting among a finite number of identified, predictable display orderings would have been obvious to one of ordinary skill in the art. MPEP 2143(I)(E).
E. Claim 10
Claim 10 recites a form having a set of fields, at least a subset of which are prefilled by the third-party computing device using the first user data subset.
Dhar discloses precisely this — a form of transaction fields, prefilled with the user’s held-account data, presented by the merchant system:
“causing presentation of a payment interface having transaction fields populated with the account information retrieved from the payment account of the user.” Dhar, claim 1.
“some of the account information may be provided to the merchant system 106 to populate (or pre-fill in) transaction fields on the payment interface provided on or associated with the website of the merchant system.” Dhar, ¶ [0027].
“In operation 510, the account information is used to populate a payment interface (e.g., payment interface 322 of FIG. 3C). In one embodiment, the payment interface is generated by the merchant system 108 without instructions from the payment provider system 108.” Dhar, ¶ [0050].
“causing the payment interface to provide an option to the user to edit the account information or add new account information.” Dhar, claim 10; see also ¶ [0035] (“The populated account information may be edited (or replaced with new account information) by selecting an edit button 320”).
Chen discloses that entered information is “matched with the payment account’s information and missing information … populated to the merchant account with merchant device 140.” Chen, ¶ [0029].
Prefilling by the third-party computing device, rather than by the provider, is an obvious allocation of the step to the party already in possession of the data. Dhar ¶ [0050] expressly places generation of the populated interface at the merchant system, and Chen ¶ [0029] places the populated interface within the merchant application.
F. Claim 14
Claim 14 recites that the first set of user data is displayed within the subset of the one or more interface elements.
Dhar, claims 8–9; ¶¶ [0034]–[0035], [0040] (transaction fields populated with shipping address, billing address, phone number, and funding source information, displayed to the user in the payment interface). Chen discloses display of the populated account-establishment interface to the user. Chen, ¶ [0064]. Carrott discloses that the transaction details are displayed on the user device for review before the user submits. Carrott, ¶ [0134].
G. Claim 16
Claim 16 recites substantially the same method as claim 1, from the perspective of “an institution computing system of a provider institution … providing account open functionality through a service provider computing device of a service provider,” and is rejected on the same grounds as claim 1 for the corresponding limitations.
Claim 16 differs from claim 1 in the following respects, each of which is addressed:
“the one or more interface elements invoking an application programming interface (API) of the provider institution to access the account open functionality” — Recited in the independent claim rather than in a dependent claim. Addressed under claim 2 above: Dhar, ¶¶ [0025], [0046]; Carrott, ¶¶ [0060], [0122]; Drury, ¶¶ [0208]–[0210]; Chen, ¶¶ [0027], [0052], claim 18.
“transmitted by the service provider computing device to the institution computing system via a telecommunications network” — Chen, ¶¶ [0058]–[0059] (network 180 including the Internet, intranets, landline networks, wireless networks; network interface component 168). Dhar, ¶ [0015] (network 104 including the Internet, wireless network, cellular network, or WAN). Carrott, ¶¶ [0169]–[0170] (network 202; input/output device 214). Drury, ¶ [0142].
“the code comprising (i) an identifier of the provider institution, (ii) an identifier of the service provider computing device, and (iii) an identifier of a type of account to open” — Carrott, ¶¶ [0098], [0104], [0124], [0139]; Drury, ¶¶ [0190], [0192]–[0194], as set forth in Rejection I. The recitation of “an identifier of the service provider computing device” rather than of the service provider is an immaterial variation; Carrott expressly discloses that the code incorporates device identifiers, that the institution verifies “that device_id belongs to account_id” (¶ [0104]), and that “the device’s identifiers are an integral part of the one-time-use code” (¶ [0057]).
“wherein the second set of user data was transmitted by the user computing device of a user to the service provider computing device via the first application of the service provider using the one or more interface elements” — Chen, ¶¶ [0012], [0027], [0044], [0064].
“wherein the new account is established while the user uses the first website or the first application without directing the user to a second website of the provider institution or a second application of the provider institution” — Chen, ¶¶ [0012], [0061], claim 1; Dhar, claim 1 (“while the user maintains a presence on a webpage of a merchant system”), claim 3, ¶¶ [0014], [0031], [0037].
H. Claim 17
Claim 17 recites that the institution computing system provides the account open functionality through the first application via a software development kit (SDK) of the provider institution.
Addressed under claim 3 above: Chen, Abstract; ¶¶ [0012], [0052].
Carrott further discloses that the institution provides the application programming interface to the provider for integration into the provider’s transactional platform:
“Providers, after enrollment, download the bank’s application programming interface (API) that provides the secure linkage to the bank’s platform for program transactions. The API includes a provider app that generates the provider’s one-time-use code.” Carrott, ¶ [0060]; see also ¶ [0122].
I. Claim 20
Claim 20 recites an institution computing system performing substantially the same operations as the method of claim 16, and is rejected on the same grounds as claims 1 and 16 for the corresponding limitations.
“a network interface configured to communicate with the service provider computing device via a telecommunications network; and one or more processors and memory having stored thereon instructions that, when executed by the one or more processors, cause the institution computing system to …”
“A system comprising: a non-transitory memory storing a merchant account for a user; and one or more hardware processors in communication with the non-transitory memory and configured to …” Chen, claim 1.
“A non-transitory computer-readable medium comprising instructions which, in response to execution by a computer system, cause the computer system to perform a method comprising …” Chen, claim 18.
See also Chen, ¶¶ [0019], [0058], [0072]–[0075] (computer system 500 comprising bus 502, I/O component 504, network interface 506, processors 512, system memory 514, static storage 516, disk drive 517).
Dhar discloses machine 700 comprising processor 702, main memory 704, static memory 706, bus 708, storage unit 716 with machine-readable medium 722 storing instructions 724, and network interface device 720. Dhar, ¶¶ [0060]–[0062]; claims 1, 16.
Carrott discloses a computerized device comprising controller/tangible processor 216, communications port (input/output) 214 operatively connected to the processor and to computerized network 202, and non-transitory tangible computer storage medium 210 readable by the processor and storing instructions the processor executes. Carrott, ¶¶ [0169]–[0171]; FIG. 17.
Drury discloses a computer system comprising processor 2202, main memory 2204, static memory 2206, bus 2208, video display device 2210, disk drive unit 2216, and network interface device 2220. Drury, ¶ [0263].
Regarding the encryption limitation of claim 20
Claim 20 further recites that the code is “encrypted by the service provider computing device according to an encryption format different from the format designated by the provider institution.”
Carrott teaches this limitation directly. Carrott discloses that the provider (service provider) device applies its own encryption to the code, using an encryption format and key distinct from the format in which the institution prescribes the code payload, and distinct from the encryption key used by the user device for the same transaction:
“said provider sequencer and said user sequencer producing different encryption keys for said transaction.” Carrott, claims 11, 16; see also claims 1, 6.
“causing, by said intermediate entity, said provider device to encrypt provider input related to said transaction to create an encrypted one-time-use provider code using a one-time-use provider encryption key produced, in part, using a uniquely sequenced number generated by a provider sequencer maintained by said provider device.” Carrott, claim 16.
Carrott discloses that the payload structure is designated by the institution through the application it supplies (<transaction_id>::<account_id>::<encrypted_data>, ¶ [0098]), while the encryption applied to that payload is a separately specified format derived by a hash function over non-changing character strings combined with a sequenced number:
“To provide a higher level of encryption, the number produced by the matching sequencers is applied to a hashing function … the encryption key can be created by hashing the strings: string#1 + sequencer + string#2 (in any order) … These random string characters … are assigned when the device is registered, are unique to each device, and do not change; however, by combining such random string characters with an incrementing number …, each time the combination … is hashed, a unique one-time-use encryption is identically produced.” Carrott, ¶ [0097].
“The methods herein obfuscate the sequencer, so the encryption keys are random looking strings … The random character strings and hashing function are used so that the encryption key cannot be determined using a brute-force attack with incrementing numeric keys.” Carrott, ¶¶ [0085], [0097].
Carrott thus discloses two distinct formats applied to a single transaction artifact: the institution-designated payload structure, and the device-applied hash-derived encryption format. Carrott further discloses that the provider and user devices apply different encryption formats to their respective halves of the same transaction (claims 11, 16), and that the encryption keys are regenerated independently by the institution for decryption (claim 16; ¶¶ [0101]–[0103], [0155]).
Drury independently teaches the two-format arrangement.
“The AccountMapMessage data may be transferred by first encrypting the data, and then generating a message authentication code (MAC) for the encrypted data. This may be referred to as the ‘encrypt then MAC’ pattern. For example, a symmetric key is randomly generated, and used to encrypt the AccountMapMessage data. The financial institution, sending the data, has the accounting software system’s public RSA key that they use to encrypt the symmetric key.” Drury, ¶ [0144].
Drury further provides a dedicated container field expressly identifying the encryption/signature format as separately specifiable:
“SM String(50) — The method used to calculate the message signature. If not specified, the default of ‘RSA-SHA2’ is assumed.” Drury, ¶ [0194].
The payload is assembled in a format designated by the receiving institution (Base64-encoded JSON per the prescribed AccountMapMessage structure, ¶¶ [0190]–[0193]), and the sending institution then applies a separate and distinct encryption format to it using its own private key and the recipient’s public key (¶¶ [0144]–[0145], [0150]–[0151]).
Rationale. It would have been obvious to one of ordinary skill in the art to have the service provider computing device encrypt the code according to an encryption format distinct from the provider-designated payload format, in order to protect the code in transit over an untrusted network while preserving the receiving institution’s ability to parse the payload structure it specified.
Drury expressly identifies both the objective and the benefits obtained:
“The message encryption and packaging described above may be implemented to allow messages to pass from the financial institution to the accounting software system over an untrusted communication mechanism.” Drury, ¶ [0180].
“The encryption and signing may provide guarantees that the message was legitimately generated by the financial institution, not tampered with or viewed in transit, and cannot be replayed.” Drury, ¶ [0181]; see also ¶¶ [0182]–[0189] (spoofing, repudiation, tampering, information disclosure, replay, man-in-the-middle).
Carrott likewise identifies the objective of preventing the code from being usable if intercepted. Carrott, ¶¶ [0058]–[0059], [0083], [0150].
Applying a known, named encryption standard in a known manner to protect a structured message in transit is the use of a known technique to achieve a predictable result. MPEP 2143(I)©, (D).
Note on effective filing date. As determined in the Priority section of this Office Action, the encryption limitation of claim 20 is not entitled to the benefit of any prior-filed application. Each reference relied upon for this limitation predates the filing date of the instant application.
J. Rationale to Combine — Rejection II
The rationale set forth in Rejection I § E is incorporated here by reference.
It would have been further obvious to one of ordinary skill in the art to incorporate the teachings of Dhar into the combined method. Dhar, like Chen, is assigned to a payment service provider and is directed to the same field of endeavor — a provider system delivering account and payment functionality into a merchant’s own site or application without redirecting the user. Chen discloses account establishment within the merchant application but is less explicit as to the API-call mechanics and the sequence of provider-branded and merchant-branded interface presentations. Dhar supplies those mechanics expressly, including the API call that initiates the process (¶¶ [0025], [0046]), the presentation of the provider’s interface as a pop-up over the merchant’s webpage (claim 3; ¶ [0031]), and its replacement with a populated payment interface presented “while the user maintains a presence on a webpage of a merchant system” (claim 1).
One of ordinary skill would have been motivated to combine these teachings because both address the same objective of reducing user friction during account establishment and checkout while keeping the user within the merchant’s environment, and because Dhar expressly identifies the benefit of “reducing computing resources used by one or more devices within the system,” including “processor cycles, network traffic, memory usage, storage space, and power consumption” (¶ [0014]). The combination is the use of a known technique to improve a similar method in the same way. MPEP 2143(I)©.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
1. Hamilton et al., US 2014/0279533 A1 Hamilton discloses real-time API-mediated establishment of a merchant financial account with a financial service provider, including creation of an account profile, assignment of an account number, and identification of the account type in the open request. Hamilton is cumulative to Chen, which expressly recites “generating the first payment account for the user using the request” (claim 18) and generating associated profile, wallet, and transaction-history data (¶¶ [0044], [0070]). As to account type, Drury discloses the account-type identifier as an enumerated field within the third-party-generated message (¶ [0190]), which is a more specific teaching than Hamilton’s disclosure.
2. Mahajan et al., US 2015/0134962 A1 Mahajan discloses template-defined forms in which fields are prefilled from data captured by the user device’s camera and processed by optical character recognition, together with encryption at the user device and relay through a server that cannot decrypt the object. Mahajan’s prefill teaching is cumulative to Dhar, which discloses that the merchant system generates the interface and that account information is used “to populate (or pre-fill in) transaction fields” on the merchant’s own page (¶¶ [0027], [0050]; claim 1). Mahajan’s encryption teaching is cumulative to Carrott (claim 11; ¶ [0163]) and Drury (¶¶ [0143], [0181], [0185]).
3. Powell et al., WO 2015/054697 A1 Powell discloses a substitute code carrying a provider-portion identifier, a requestor identifier, an account/product type, and a token expiry date passed among entities during processing. Powell is cumulative to Drury, which discloses the expiration field within the third-party-generated message together with the specific validation operation and the precondition that gates the transaction on it (¶¶ [0178], [0186]–[0187], [0193], [0207]) — a more complete teaching of the claimed arrangement than Powell provides.
4. Additional References of Record The following were also located and considered. Each is cumulative for the reason stated and is cited on Form PTO-892.
Hruska, US 2013/0282588 A1: Third-party device appends its identifier to a received token and re-encrypts in a distinct format. Cumulative to Carrott (¶¶ [0098], [0139]) and Drury (¶ [0144]).
Hurley et al., US 2019/0147515 A1: SDK libraries mediating all interaction; relayed value “cannot be derived” by the intermediary; scoping information with validity period. Cumulative to Carrott, Drury (¶¶ [0181], [0185]), and Chen (SDK).
Kesavan et al., US 2018/0276053 A1: Generic and service-specific APIs; provider-supplied UI templates rendered in a client application; contextually prepopulated form data. Cumulative to Dhar (¶¶ [0025], [0050]) and Chen (¶ [0052]).
Mendez et al., US 2016/0005113 A1: New-account generation; transfer of data and automatic payment arrangements from an existing account. Cumulative to Chen (claim 18; ¶¶ [0045], [0070]).
Leavy et al., US 2015/0149772 A1: Provider-delivered browser script performing client-side cryptography; split key material. Cumulative to Carrott (claim 11) and Drury (¶ [0185]).
Leong et al., US 7,610,233 B1: Account opening with a provider institution through an intermediary platform; identifier-based routing to the correct institution; pre-filled forms. Cumulative to Chen and Dhar.
Oberheide et al., US 2014/0245389 A1: Managing-account identifier used to select the correct downstream configuration; attribute translation between protocols. Cumulative to Carrott (¶ [0098]) and Drury (¶¶ [0193]–[0194]).
Burmester et al., US 2019/0281051 A1: Confidence-level-based biometric authentication; provider-generated instructions to a client API. Not pertinent.
Fakhraie et al., US 2025/0131123 A1: Central portal for managing and revoking third-party access permissions. Not available as prior art. Publication postdates every effective filing date; and, subject to confirmation of the assignment record, disqualified under 35 U.S.C. § 102(b)(2)© as commonly owned with the instant application.
THIS ACTION IS MADE FINAL. 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 MICHAEL W ANDERSON whose telephone number is (571)270-0508. The examiner can normally be reached Monday - Thursday 9am-4pm.
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, Tariq Hafiz can be reached at (571) 272-5350. 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.
Mike Anderson
Supervisor Patent Examiner
Art Unit 3693
/Mike Anderson/Supervisory Patent Examiner, Art Unit 3693
