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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 23 September 2025 has been entered.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 16, and 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 16, and 20, respectively, of U.S. Patent No. 11,995,619. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 1 of the patent discloses all of the limitations of claim 1 of the instant application.
Because claim 1 of the patent includes all of the limitations of claim 1 of the application, claim 1 of the reference patent anticipates claim 1 of the instant application. Claim 1 of the patent includes additional details including establishing a new account based on based on an expiration time satisfying a predetermined time period.
This, however, essentially renders claim 1 of the patent a “species” of the generic invention of claim 1 of the instant application. It has been held that a generic invention is “anticipated” by a “species” within the scope of the generic invention. See In re Goodman, 11 F.3d 1046, 1052, 29 USPQ2d 2010, 2015-16 (Fed. Cir. 1993)and MPEP § 804.II.B.2.
Accordingly, claim 1 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. US 11,995,619 B2. In the same way, claim 16 of the patent anticipates claim 16 of the instant application. Claim 20 (which does not include encryption but does include limitations concerning expiration time) anticipates claim 20 of the application in the same way. Thus claims 1, 16, and 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 16, and 20, respectively, of U.S. Patent No. 11,995,619.
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.
Eligibility Step 1
Each of the claims are directed to a method (claims 1-19) or a system (claim 20) and thus fall into at least one statutory category enumerated in 35 U.S.C. § 101 (process, machine, manufacture, or composition of matter).
Eligibility Step 2A Prong One
However, claim 20 recites:
providing account open functionality;
Receive […] a request for account open functionality, the user having a third-party account with the service provider, the request comprising a first set of user data of the user stored in association with the third-party account; provide,; receive, […], an account open request comprising a second set of user data transmitted […] and a code […], the code comprising an identifier of the provider institution, an identifier of the service provider computing device, and an identifier of a type of account to open, wherein the second set of user data was transmitted, and wherein at least a portion of the second set of user data is encoded […], the code generated by the service provider computing device based on a format designated by the provider institution and encrypted […] according to an encryption format different from the format designated by the provider institution; establish, a new account for the user of the user computing device at least in part by_ (i) parsing the code to obtain the identifier of the provider institution, the identifier of the service provider computing device, and the identifier of the type of account to open,(ii) validating the first set of user data or the second set of user data using the code, 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 transmit, […] the set of account data […] for use […] in a transaction, wherein the new account is established […]
This recited subject matter falls under the abstract idea grouping of Certain Methods of Organizing Human Activity -- commercial or legal interactions (including agreements in the form of contracts; legal obligations; marketing or sales activities or behaviors; business relations) at least because it recites receiving an account open request and establishing a new account for use in a transaction. See MPEP 2106.04(a)(2) subsection II.B.
Eligibility Step 2A Prong Two
The additional limitations in the claims include:
An institution computing system for through a service provider computing device of a service provider,
the 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 that, when executed by the one or more processors,101
, in response to an interaction with a first interactive element displayed via a first application of the service provider executing on a user computing device of a user,
to the user computing device, one or more interface elements for presentation via the first application of the service provider, the one or more interface elements invoking an application programming interface (API) of the provider institution to access the account open functionality, at least a subset of the one or more interface elements generated to be pre-populated with the first set of user data associated with the user and received in the request
from the service provider computing device via the network interface
by the service provider computing device to the institution computing system via the telecommunications network
generated by the service provider computing device
by the user computing device of a user to the service provider computing device via the first application of the service provider
by the user computing device and is incapable of being decoded by the service provider computing device
by the service provider computing device
via the network interface,
to the service provider computing device
by the service provider computing device
with the user computing device via the first application
while the user uses the first application without directing the user to a second web site of the provider institution or a second application of the provider institution.
The Specification describes the components generically, see e.g.:
An indication that a user wishes to open an account “may be provided via any user interface mechanism deemed suitable, such as via touchscreen, voice prompt, keypad, etc. (Spec. at [0034]).
“The user device 110 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.)” (Spec. at [0065]).
“The various systems and devices may be communicatively and operatively coupled through a network 150, which may include one or more of the Internet, cellular network, Wi-Fi, Wi-Max, a proprietary banking network, or any other type of wired or wireless network or a combination of wired and wireless networks.” (Spec. at [0046]).
The additional claim elements are recited at a high-level of generality; and so, merely generally link the use of the judicial exception to a particular technological environment of networked computers and do not impose any meaningful limits on practicing the abstract idea. The claimed invention does not improve the functioning of a computer or improve another technology or technical field. Thus, the judicial exception is not integrated into a practical application.
Eligibility Step 2B
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately or in combination, they do no more than limit the above-identified abstract idea to the particular technological environment of networked computers, as discussed above. Limitations that merely confine the use of the abstract idea to a particular technological environment fail to add an inventive concept to the claims. See MPEP § 2106.05(h) discussing Affinity Labs of Texas v. DirecTV, LLC, 838 F.3d 1253, 120 USPQ2d 1201 (Fed. Cir. 2016) (particular technological environment of cellular telephones). The claims are not patent-eligible.
Independent claims 1 and 16 include substantially the same limitations and are rejected for the same reasons as claim 20.
Claim 2 adds invocation of APIs which is part of the environment of networked computers and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 3 adds that interface elements include SDKs, which is part of the environment of networked computers and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 4 adds transmitting a request in response to a signal, which is part of the environment of networked computers and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 5 adds the timing of presenting elements. Presentation timing is part of the abstract idea and presenting visual elements is part of the environment of networked computers and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 6 adds the timing of presenting elements. Presentation timing is part of the abstract idea and presenting visual elements is part of the environment of networked computers and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 7 adds the timing of presenting elements. Presentation timing is part of the abstract idea and presenting visual elements is part of the environment of networked computers and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 8 adds the timing of presenting elements. Presentation timing is part of the abstract idea and presenting visual elements is part of the environment of networked computers and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 9 specifies the sources of data sets and is part of the abstract idea and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 10 adds presenting a form having a set of fields for entering user data and pre-filling fields with user data. This is part of the abstract idea of establishing an account and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 11 adds accepting a transaction amount and indicating how funds are to be transferred and processing the transaction and the transaction involving a funds transfer. This is part of the abstract idea of establishing an account and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 12 specifies that the new account accepts automated payments . This is part of the abstract idea of commercial activity/establishing an account and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 13 specifies that the new account is used to make a payment for a purchase made by the user. This is part of the abstract idea of commercial activity/establishing an account and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 14 specifies displaying a set of user data within interface elements. Displaying user data is part of the abstract idea. Generically recited interface elements are part of the technological environment of computers and computer networks and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 15 specifies that an expiration time is included and that the account is established responsive to determining that the expiration time satisfies a predetermined time period. This is an abstract idea (mental process: concepts performed in the human mind (including an observation, evaluation, judgment, opinion) and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 17 adds that functionality is provided via SDKs, which is part of the environment of networked computers and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 18 adds transmitting the account open request to the institution computing system in response to a signal received at the suer computing device, the signal indicating that the user has selected to open the new account with the provider institution. Indicating that the user has selected to open the new account with the provider institution is part of the abstract idea identified above. The remaining elements are generic components of a networked computer environment and do not integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Claim 19 specifies the sources of data sets and is part of the abstract idea and does not integrate the abstract idea into a practical application or provide significantly more.
Thus, claims 1-20 are rejected under 35 U.S.C. § 101 as being directed to patent-ineligible subject matter.
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.
Claim(s) 1, 2, 4-10, and 13-16 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over JIAM, M. et al. to US 20170024716 A1 (“JIAM”) in view of US 20180060965 A1 to KUMAR, S. (“KUMAR”) n further view of US 20130282588 A1 to HRUSKA, J. (“HRUSKA”).
Regarding claim(s) 1,
JIAM discloses:
A method implemented by a system associated with a provider, the method comprising:
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 (see, at least, JIAM: [0002]: The present disclosure relates to the integration of banners into third party websites; [0023]: the browser loads a website with content from the merchant server 6 and a banner from the transaction account provider server; see, at least, JIAM: ¶[0013]: More specifically, a banner placed in the checkout journey may exchange integrated customer data, and upon a user clicking the banner, open a modal window on top of the merchant parent window, where a credit or charge card application may be completed and instantly decisioned.),
providing one or more interface elements associated with the account open functionality for presentation via the third-party application (see, at least, JIAM: [0013]: a banner may be placed within a merchant's “checkout journey” ; a banner placed in the checkout journey may exchange integrated customer data, and upon a user clicking the banner, open a modal window on top of the merchant parent window, where a credit or charge card application may be completed and instantly decisioned; all the assets starting with the banner and ending with the conclusion of the checkout journey may be hosted exclusively by the transaction account provider, and yet displayed properly integrated with the merchant shopping cart experience ) ,
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 (see, at least, JIAM: [003]: browser interaction by the user with the merchant page; [0013]: a user click[s] the banner; window may be iFrames or a browser window or a browser tab; [0013]: a banner may be placed within a merchant's “checkout journey” ; a banner placed in the checkout journey may exchange integrated customer data, and upon a user clicking the banner, open a modal window on top of the merchant parent window, where a credit or charge card application may be completed and instantly decisioned; all the assets starting with the banner and ending with the conclusion of the checkout journey may be hosted exclusively by the transaction account provider, and yet displayed properly integrated with the merchant shopping cart experience),
at least a subset of the one or more interface elements to be pre-populated with the first set of user data associated with the user and received in the request (see, at least, JIAM: [0013]: Integrated customer data may be exchanged between the user and merchant, the user and transaction account provider, and the merchant and transaction account provider. Integrated customer data may comprise data pre-filled into forms of the merchant and/or the transaction account provider based on data previously provided to the other; [0016]: Data entered by a user via the web browser 4 may be cross-populated to both the transaction account provider server 2 and the merchant server 6. Data retrieved individually from the transaction account provider server 2 and the merchant server 6 may be securely passed to the other of the transaction account provider server 2 and the merchant server 6.);
receiving, via the one or more interface elements, an account open request comprising a second set of user data transmitted to the system from the third-party computing device over the network (see, at least, JIAM: ¶[0013]: More specifically, a banner placed in the checkout journey may exchange integrated customer data, and upon a user clicking the banner, open a modal window on top of the merchant parent window, where a credit or charge card application may be completed and instantly decisioned.; see, at least, JIAM: [0013]: Integrated customer data may be exchanged between the user and merchant, the user and transaction account provider, and the merchant and transaction account provider. Integrated customer data may comprise data pre-filled into forms of the merchant and/or the transaction account provider based on data previously provided to the other; [0016]: Data entered by a user via the web browser 4 may be cross-populated to both the transaction account provider server 2 and the merchant server 6. Data retrieved individually from the transaction account provider server 2 and the merchant server 6 may be securely passed to the other of the transaction account provider server 2 and the merchant server 6.)
and a code generated by the third-party computing device (see, at least, JIAM: ¶[0015]:, as part of an onboarding process, a merchant may share a CA-signed public SSL certificate which was installed within a trust-store of a transaction account company application server; […] digital signature signing and verification based on the PKI and Public Key cryptography, as well as secured RESTful Service over HTTPS POST via transaction account company hosted JavaScript.; ¶[0018]: a banner request ID that uniquely identifies a request for banner to be placed on the webpage, [0019]: service call is instantiated from the web browser and the transaction account provider server may be configured to receive the secured service call; [0020]: transaction account provider server may validate and verify the originating domain of returned webpage content, the merchants digital signature, the banner request ID, the time stamp against a time limit constraint, and/or the like ; [0022]: the transaction account provider server may return to the web browser a secure banner token and a landing page URL for hosting in the iFrame; [0024]: for instance, the credit-card provider may validate and verify the secure URL linked to a portion of the banner corresponding to the user-banner interaction and/or the secure banner token with an expiration date of the dynamic banner; ¶[0027]: The IAN may be provided […] in a format that comprises an encrypted variable encrypted using the merchant's public key in a hidden variable of the displayed webpage displayed in the web browser),
the code comprising an identifier of the provider (see, at least, JIAM: ¶[0015]: various processes and systems involve the exchange of sensitive information, such as personally identifying information, transaction account numbers, and/or the like. For instance, as part of an onboarding process, a merchant may share a CA-signed public SSL certificate which was installed within a trust-store of a transaction account company application server; […] digital signature signing and verification based on the PKI and Public Key cryptography, as well as secured RESTful Service over HTTPS POST via transaction account company hosted JavaScript.; ¶[0018]: a banner request ID that uniquely identifies a request for banner to be placed on the webpage, [0019]: service call is instantiated from the web browser and the transaction account provider server may be configured to receive the secured service call; [0020]: transaction account provider server may validate and verify the originating domain of returned webpage content, the merchants digital signature, the banner request ID, the time stamp against a time limit constraint, and/or the like ; ¶[0021]: the transaction account provider server 2 may prepare a dynamic banner comprising one or more of a secure banner token with […] a secure URL linked to a portion of the banner ( e.g., an "APPLY NOW" button whereby a user may apply for a transaction account of the transaction account provider); [0022]: the transaction account provider server may return to the web browser a secure banner token and a landing page URL for hosting in the iFrame; [0024]: for instance, the credit-card provider may validate and verify the secure URL linked to a portion of the banner corresponding to the user-banner interaction and/or the secure banner token with an expiration date of the dynamic banner; [0015]: white list domain validation may be applied against the domain of the shopping cart experience and/or payment pages; Time-constraint, single-use security tokens for each banner request may be implemented as well),
an identifier of computing device (JIAM: ¶[0015]: For instance, as part of an onboarding process, a merchant may share a CAsigned public SSL certificate which was installed within a trust-store of a transaction account company application server. The merchant may also specify the domain of their shopping cart experience, and/or payment pages in which transaction account company hosted banners (e.g., dynamic banner JavaScript banners) will be sourced. The transaction account company may have assigned a merchant-id to the merchant, such that the merchant is identified. Moreover, further security may be implemented, such as digital signature signing and verification based on the PKI and Public Key cryptography, as well as secured RESTful Service over HTTPS POST via transaction account company hosted JavaScript.; ¶[0017]: In response, the merchant server 6 may prepare a checkout webpage, for instance, a JSP/ASP webpage. This may comprise, for example, creating a digital signature by signing on the current timestamp using the merchant's SSL certificate private key.),
wherein the account open request is for a new account with the provider (see, at least, JIAM: ¶[0013]: More specifically, a banner placed in the checkout journey may exchange integrated customer data, and upon a user clicking the banner, open a modal window on top of the merchant parent window, where a credit or charge card application may be completed and instantly decisioned.),
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 (see, at least, JIAM: [0013]: Integrated customer data may be exchanged between the user and merchant, the user and transaction account provider, and the merchant and transaction account provider. Integrated customer data may comprise data pre-filled into forms of the merchant and/or the transaction account provider based on data previously provided to the other.; [0016]: Data entered by a user via the web browser 4 may be cross-populated to both the transaction account provider server 2 and the merchant server 6. Data retrieved individually from the transaction account provider server 2 and the merchant server 6 may be securely passed to the other of the transaction account provider server 2 and the merchant server 6.),
and 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 (see, at least, JIAM: [0029]: encrypted [account number] and customer data may be posted to the merchant's shopping cart by the transmission of a cross document message only if the user authorizes it; [0015]: encrypted account information is returned to the merchant page subject to user consent; ¶[0029]: If the pre-fill is authorized, the encrypted IAN and customer data may be posted to the merchant's shopping cart by the transmission of a cross document message (step 606).; ¶[0028]: an iframe acquisition journey 601 may begin with encryption and signature of customer and account details with merchant's RSA public key and placement on the page displayed in the iframe, such as in step 302 (step 602)),
the code generated by the third-party computing device based on a format designated by the provider (see, at least, JIAM ¶[0027]: The IAN may be provided from the transaction account provider server 2 to the web browser 4 in a format that comprises an encrypted variable encrypted using the merchant's public key in a hidden variable of the displayed webpage displayed in the web browser; ¶[0015]: As will be discussed further herein, various processes and systems involve the exchange of sensitive information, such as personally identifying information, transaction account numbers, and/or the like. For instance, as part of an onboarding process, a merchant may share a CA-signed public SSL certificate which was installed within a trust-store of a transaction account company application server. The merchant may also specify the domain of their shopping cart experience, and/or payment pages in which transaction account company hosted banners (e.g., dynamic banner JavaScript banners) will be sourced. The transaction account company may have assigned a merchant-id to the merchant, such that the merchant is identified. Moreover, further security may be implemented, such as digital signature signing and verification based on the PKI and Public Key cryptography, as well as secured RESTful Service over HTTPS POST via transaction account company hosted JavaScript.),
wherein the new account is established without directing the user to a second application; (see, at least, JIAM: [0012]: merchants integrate banners or transaction account application processes into their online shopping cart pages.; [0014]: Personally identifiable information (PII) may be autofilled into documents of the transaction account provider and/or the merchant. [...] the real time or substantially real time approval and issuance of a transaction account by the transaction account provider to the user may be supplemented by card account pass back to the merchant checkout journey for immediate (or expedited) payment.); [0016]: a banner may be sourced from a transaction account provider server 2 and integrated into a shopping cart experience (sourced from a merchant server 6), which is displayed inside a web browser 4; [0023]: a seamless (or near seamless) user experience manifests, wherein the browser loads a website with content from the merchant server 6 and a banner from the transaction account provider server; [0027]-[0028]: Instant account number is returned to the merchant page for immediate use in completing a proposed transaction and the account details and purchase payment information are pre-filled into the shopping cart experience of the web browser).
transmitting, via the one or more interface elements, 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 (see, at least, JIAM: [0014]: Personally identifiable information (PII) may be autofilled into documents of the transaction account provider and/or the merchant. [...] the real time or substantially real time approval and issuance of a transaction account by the transaction account provider to the user may be supplemented by card account pass back to the merchant checkout journey for immediate (or expedited) payment.); [0027]-[0028]: Instant account number is returned to the merchant page for immediate use in completing a proposed transaction and the account details and purchase payment information are pre-filled into the shopping cart experience of the web browser)
JIAM does not expressly disclose the following limitations, which KUMAR however, teaches:
the user having a third-party account with the third-party (KUMAR: ¶[0041]: Turning first to the user-centered straight through processing 300 example, in 304, an investor 104 may login to the app 144 ( e.g., using a personal computer, smartphone, tablet, or other device as discussed above). In 306, using the app 144, the user may choose "self-service" or a similar option and enter information; ¶[0042]: In 310, the advisor 102 may log into the app 144 (e.g., using a personal computer, smartphone, tablet, or other device as discussed above). In 312, the advisor 102 may create an account for the investor 104 and/or transaction to be processed. In 314, the advisor 102 may select forms for the account using the app 144.; ¶[0048]: Turning to the system processing 400 example, corresponding to the user-centered straight through processing 300, in 402, the CRM cloud 140 may receive user login data from the advisor 102 ( e.g., through the app 144) and log the user in. In 404, the CRM cloud 140 may receive client information from the advisor 102 through the app 144. In 406, if the client information relates to a new client, the CRM cloud 140 may create a new account (if not, this step may be skipped),
the request comprising a first set of user data of the user stored in association with the third-party account (KUMAR: [0032]: b. Certain custodians may also provide an API/mechanism to transmit data elements to this portal such that these data elements may be prefilled in the portal, and the user may not have to re-enter them. In such cases, the system 100 may capture the account information, validate and transform it, and send it across to the custodian by a pre-fill API/ mechanism. The system 100 may launch the custodian portal for the user to complete the account opening process with the appropriate data pre-filled; [0036] For the forms pre-fill, system 100 data may be transformed and formatted as required by the forms vendors. The transformations may be analogous but distinct from the transformations required for the account opening APL The system 100 may retain the unified data model but perform custodian and even form specific transformations as needed; ¶[0093]: Generate pre-fill request for a forms)
[…]
the identifier of the provider institution (KUMAR: ¶[0084]: The JSON snippet may look like: TABLE-US-00001 {“skience_product_company”: “National Financial”, “skience_account_registration_type”: “Joint - With Rights of Survivorship”, “skience_product_type”: “Brokerage” }; ¶[0085]: The XML snippet may look like: TABLE-US-00002 <skience_product_company>National Financial</skience_product_company> <skience_account_registration_type> Joint - With Rights of Survivorship </skience_account_registration_type> <skience_product_type> Brokerage</skience_product_type > )
and the identifier of the type of account to open, (KUMAR: ¶[0026]: Individual registration type: A user may want to create an individual account. NFS (a custodian) may require a value of I for individual accounts. Pershing (another custodian) may require a value of INDV. The system 100 may present the registration type as Individual and then map to either I (for NFS) or INDV (for Pershing); [0029]: d. Data elements may be specific to certain custodians: For trust accounts, Pershing may require entry of the type of trust, for example family trust, charitable trust, irrevocable trust, living trust, and other types of trusts; [0029]: The system 100 data model may capture the type of trust. If opening an account for the trust, the system may send the type of trust to Pershing.);
and 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, (KUMAR: [0031]: Thus, users may input data in the system 100, the data may be validated and transformed in the system 100 and transmitted to the custodians via the appropriate custodian API. The custodian API may also run its own validations and if all validations succeed, may return an account number. This account number may be populated in the system 100 to complete the process. [0032]: the system 100 may capture the account information, validate and transform it,[…] The system 100 may launch the custodian portal for the user to complete the account opening process with the appropriate data pre-filled.; ¶[048]: the CRM cloud 140 may receive client information from the advisor 102 through the app 144. In 406, if the client information relates to a new client, the CRM cloud 140 may create a new account; [0055]: . If authentication is successful, in 432, the services cloud 110 may validate the client information.[…] If validation is successful, in 434, the services cloud 110 may send a web services request to the custodian 130 API including the validated information; [0056]: In 436, the custodian 130 may accept the information and generate an account number. The custodian 130 may return the account number to the services cloud 110, which may send the account number to the CRM cloud 140.)
It would have been obvious to one of ordinary skill in the art at the time of filing to combine/modify the system/method of JIAM, which discloses integrating transaction account application processes into merchant online shopping cart pages (JIAM [0003]) and transaction account provider server receiving a secured CORS HTTPS RESTful service call (JIAM [0019]) with the technique of KUMAR, which discloses opening a financial account using an integrated system (KUMAR [0008]) in order to provide users with a seamless account-opening experience (KUMAR [0030]) and to include data elements that are specific to certain custodians/account providers (KUMAR [0029]).
JIAM discloses a establishing an account, as shown, but does not expressly disclose the following limitations, which HRUSKA however, teaches:
establishing the new account at least in part by parsing the code to obtain (HRUSKA: ¶[0018]: server decrypts the unique, time-sensitive active digital token with the appended consumer and merchant information and token information is then “matched against the stored information”)
[…]
the identifier of the third-party computing device (HRUSKA: ¶[0004]: token which is then appended by the application with both the UDID and UAID, a registered merchant’s handheld wireless POS terminal (Tablet—POS) or a stationary wired device (ATM/KIOSK/POS) with the system’s proprietary POS application software capable of recognizing; ¶[0018]: the application subsequently appends the unique merchant identifier (UMID) from that merchant’s application (Note: this UMID was assigned to merchant application/device at the time of merchant account setups); Once scanned and decoded by the POS application, the application subsequently appends the unique merchant identifier (UMID) to the inactive valued digital token that was passed from the consumer's mobile device. Once this is confirmed, using the one way hashed encryption technique used on the receiving token and matched against the stored information on the server backend; the appended digital valued token data (the UDID, the UAID, the UMID and also the valued digital token itself must match to what is on file in the transactional server consumer's account to confirm transactional authentication; [0004] consumer's mobile handheld device has its own unique identifier (UDID), a proprietary unique mobile application also having its own unique identifier (UAID) downloaded to the registered device.),
[…]
validating the first set of user data or the second set of user data using the code (HRUSKA: ¶[0018]: Once scanned and decoded by the POS application, the application subsequently appends the unique merchant identifier (UMID) to the inactive valued digital token that was passed from the consumer's mobile device. Once this is confirmed, using the one way hashed encryption technique used on the receiving token and matched against the stored information on the server backend; the appended digital valued token data (the UDID, the UAID, the UMID and also the valued digital token itself must match to what is on file in the transactional server consumer's account to confirm transactional authentication; [0004] consumer's mobile handheld device has its own unique identifier (UDID), a proprietary unique mobile application also having its own unique identifier (UAID) downloaded to the registered device.),
It would have been obvious to one of ordinary skill in the art at the time of filing to combine/modify the system/method of JIAM, which discloses integrating transaction account application processes into merchant online shopping cart pages (JIAM [0003]) and transaction account provider server receiving a secured CORS HTTPS RESTful service call (JIAM [0019]) with the technique of HRUSKA, which discloses a system and a method for secure financial transactions over a computer network, internet system and telecommunication network (HRUSKA [0001]) in order to enhance security of transactions (HRUSKA [0006]) and protect transactions from prying eyes of hackers and secure personal information and financial instruments (HRUSKA ¶[0002]).
Regarding claim(s) 2,
JIAM, KUMAR, and HRUSKA teaches the limitations of claim 1.
JIAM does not expressly disclose the following limitations, which KUMAR however, teaches:
herein the one or more interface elements invoke an application programming interface (API) of the provider to access the account open functionality (see, at least, KUMAR: [0011]: financial accounts are established with custodians; Account opening information may include account type and account preferences; figure 1 and [0021]: Users/advisors interact with the App 14; [0021]: The services cloud may be in communication with custodian platforms including a custodian API service 134; Users (e.g., advisor 102) may interact with the app 144 using computing devices such as personal computers, smartphones, tablets, laptops, or the like; [0028]: account opening request; [0031]: For custodians that provide an API for opening accounts (straight through processing), the system 100 may send the translated data using proprietary custodian APIs and display the return status to provide users with a seamless experience and return an account number; [0032]: Other custodians may provide an API to transmit data elements to a portal for users to open accounts wherein the system launches the portal with prefilled data to complete the account opening process; [0040]: Straight through processing 300 may integrate the system 100 directly with the end custodian and allow a user to create an account with the click of a button).
It would have been obvious to one of ordinary skill in the art at the time of filing to combine/modify the system/method of JIAM, which discloses integrating transaction account application processes into merchant online shopping cart pages (JIAM [0003]) and transaction account provider server receiving a secured CORS HTTPS RESTful service call (JIAM [0019]) with the technique of KUMAR, which discloses opening a financial account using an integrated system (KUMAR [0008]) in order to provide users with a seamless account-opening experience (KUMAR [0030]) and to include data elements that are specific to certain custodians/account providers (KUMAR [0029]).
Regarding claim(s) 4,
JIAM, KUMAR, and HRUSKA teach the limitations of claim 1.
JIAM further discloses:
wherein 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 (see, at least, JIAM: [0002]: The present disclosure relates to the integration of banners into third party websites; [0023]: the browser loads a website with content from the merchant server 6 and a banner from the transaction account provider server; ¶[0021]: in response to a user interaction with the banner such as clicking an “APPLY NOW” button).
Regarding claim(s) 5,
JIAM, KUMAR, and HRUSKA teach the limitations of claims 1 and 4.
JIAM further discloses:
wherein the third-party application presents a set of visually perceptible elements associated with the third-party after the third-party application receives the signal indicating the user has selected to open the new account with the provider (see, at least, JIAM ¶[0029]: return to a merchant's shopping cart; [0029]: In response to the user selecting to activate a return-to-merchant aspect of the page (step 604), such as clicking a button to return to a merchant's shopping cart; JIAM: [0014]: In accordance with various embodiments, the systems and methods disclosed herein securely integrate consumer (e.g., card member) acquisition by the transaction account provider as an experience within an upfunnel shopping and/or checkout journey of a merchant. Personally identifiable information (PII) may be autofilled into documents of the transaction account provider and/or the merchant. The population of the documents may be in real time, or substantially real time. Moreover, the real time or substantially real time approval and issuance of a transaction account by the transaction account provider to the user may be supplemented by card account pass back to the merchant checkout journey for immediate (or expedited) payment. Furthermore, banners (e.g., prescreened offer requests) may be presented based on the PII.); [0024]: in various embodiments a customer may click an “APPLY NOW” button (step 202) presented in a banner in a web browser 4), JIAM: [0013]: Integrated customer data may be exchanged between the user and merchant, the user and transaction account provider, and the merchant and transaction account provider. Integrated customer data may comprise data pre-filled into forms of the merchant and/or the transaction account provider based on data previously provided to the other; [0014]: Personally identifiable information (PII) may be autofilled into documents of the transaction account provider and/or the merchant. The population of the documents may be in real time, or substantially real time. Moreover, the real time or substantially real time approval and issuance of a transaction account by the transaction account provider to the user may be supplemented by card account pass back to the merchant checkout journey for immediate (or expedited) payment. Furthermore, banners (e.g., prescreened offer requests) may be presented based on the PII.); [0034]: Internal data may be gathered before, during, or after a relationship between the credit issuer and the transaction account holder (e.g., the consumer or buyer).
Regarding claim(s) 6,
JIAM, KUMAR, and HRUSKA teach the limitations of claims 1 and 4.
JIAM further discloses:
wherein the third-party application presents a first set of visually perceptible elements associated with the third-party before the third-party application receives the signal indicating the user has selected to open the new account with the provider (JIAM:¶[0013]: a banner may be placed within a merchant's “checkout journey” (e.g., the process whereby a user selects and ultimately purchases items from the merchant); banner placed in the checkout journey may exchange integrated customer data, and upon a user clicking the banner, open a modal window on top of the merchant parent window, where a credit or charge card application may be completed and instantly decisioned.; ¶[0017]: web browser 4 navigate[s] to a merchant check out page (e.g., shopping cart experience/merchant checkout journey)).
Regarding claim(s) 7,
JIAM, KUMAR, and HRUSKA teach the limitations of claims 1, 4, and 6:
JIAM further discloses:
wherein the third-party application presents a second set of visually perceptible elements associated with the provider after the third-party application receives the signal indicating the user has selected to open the new account with the provider (see, at least, JIAM: [0012]: merchants may desire to integrate banners and/or transaction account application processes into their online shopping cart pages; [0023]: the browser loads a website with content from the merchant server and a banner from the transaction account provider server; [0023]: the banner may be dynamic for different users or different merchants; figure 2: customer clicks to navigate to merchant’s CheckOut page on customer web browser; banner with “apply now” button is prepared and returned to merchant’s page to be displayed; figure 3: customer clicks “apply now” button and applies for a transaction account; JIAM [0025]; figure 3: customer submitted card application, credit card provider ThankYou page; [0026]: the content provided within the iFrame from the transaction account provider server may include an IAN [instant account number]. “the user may complete a transaction account application, with the IAN details displayed in the iFrame (step 302)”; [0027]: Subsequently, the merchant server 6 may return the decrypted IAN details and pre-fill the purchase payment information into the shopping cart experience of the web browser 4 (step 310); [0029]: the web browser may evaluate whether a box authorizing the pre-fill the transaction information with the IAN details is checked),
and wherein the third-party application presents the first set of visually perceptible elements associated with the third-party after the third-party application receives, via the one or more interface elements, the first set of user data associated with the third-party account of the user (see, at least, JIAM: [0014]: In accordance with various embodiments, the systems and methods disclosed herein securely integrate consumer (e.g., card member) acquisition by the transaction account provider as an experience within an upfunnel shopping and/or checkout journey of a merchant. Personally identifiable information (PII) may be autofilled into documents of the transaction account provider and/or the merchant. The population of the documents may be in real time, or substantially real time. Moreover, the real time or substantially real time approval and issuance of a transaction account by the transaction account provider to the user may be supplemented by card account pass back to the merchant checkout journey for immediate (or expedited) payment. Furthermore, banners (e.g., prescreened offer requests) may be presented based on the PII.); [0024]: in various embodiments a customer may click an “APPLY NOW” button (step 202) presented in a banner in a web browser 4).
Regarding claim(s) 8,
JIAM, KUMAR, and HRUSKA teach the limitations of claims 1, 4, and 6:
JIAM further discloses:
wherein the third-party application presents the first set of visually perceptible elements associated with the third-party after the third-party application receives the signal indicating the user has selected to open the new account with the provider, but before the third-party application receives, via the one or more interface elements, the second set of user data for the account open request (see, at least, JIAM: [0013]: Integrated customer data may be exchanged between the user and merchant, the user and transaction account provider, and the merchant and transaction account provider. Integrated customer data may comprise data pre-filled into forms of the merchant and/or the transaction account provider based on data previously provided to the other; [0014]: Personally identifiable information (PII) may be autofilled into documents of the transaction account provider and/or the merchant. The population of the documents may be in real time, or substantially real time. Moreover, the real time or substantially real time approval and issuance of a transaction account by the transaction account provider to the user may be supplemented by card account pass back to the merchant checkout journey for immediate (or expedited) payment. Furthermore, banners (e.g., prescreened offer requests) may be presented based on the PII.); [0034]: Internal data may be gathered before, during, or after a relationship between the credit issuer and the transaction account holder (e.g., the consumer or buyer).
Regarding claim(s) 9,
JIAM, KUMAR, and HRUSKA teach the limitations of claim 1:
JIAM further discloses:
wherein the first set of user data includes: a first user data subset received at the system from the user computing device before the third-party application receives a user request to open the new account with the provider (see, at least, JIAM: [0013]: Integrated customer data may comprise data pre-filled into forms of the merchant and/or the transaction account provider based on data previously provided to the other.; [0017]: For example, a web browser 4 may receive a navigation command directing the web browser 4 to navigate to a merchant check out page (e.g., shopping cart experience/merchant checkout journey) (step 102). In response, the merchant server 6 may prepare a checkout webpage. [...]. Moreover, this may involve setting up personally identifiable information (PII) receiver fields of the merchant check out page in preparation for the collection of personally identifiable information (PII) from the user via the web browser);
and a second user data subset received at the third-party computing device from the user computing device after the third-party application receives the user request to open the new account with the provider (see, at least, JIAM: [0014]: account information may pass back from the transaction account prov-ider to the merchant, and PII may pass from the merchant to the transaction account provider; [0016]: Data entered by a user via the web browser 4 may be cross-populated to both the transaction account provider server 2 and the merchant server 6. Data retrieved individually from the transaction account provider server 2 and the merchant server 6 may be securely passed to the other of the transaction account provider server 2 and the merchant server 6.).
Regarding claim(s) 10,
JIAM, KUMAR, and HRUSKA teach the limitations of claim 1 and 9:
JIAM further discloses:
wherein in response to the third-party computing device receiving the user request, the third-party application presents a form having a set of fields into which the user enters user data to be transmitted to the system for use in opening the new account (see, at least, JIAM: [0017]: The banner display method 100 may involve various interoperations between a web browser 4 and a merchant server 6, and between a web browser 4 and a transaction account provider server 2. For example, a web browser 4 may receive a navigation command directing the web browser 4 to navigate to a merchant check out page (e.g., shopping cart experience/merchant checkout journey) (step 102). In response, the merchant server 6 may prepare a checkout webpage. [...]. Moreover, this may involve setting up personally identifiable information (PII) receiver fields of the merchant check out page in preparation for the collection of personally identifiable information (PII) from the user via the web browser),
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 (see, at least, JIAM: [0013]: The banner display method 100 may involve various interoperations between a web browser 4 and a merchant server 6, and between a web browser 4 and a transaction account provider server 2; [0017]: ). In response, the merchant server 6 may prepare a checkout webpage. [...]. Moreover, this may involve setting up personally identifiable information (PII) receiver fields of the merchant check out page in preparation for the collection of personally identifiable information (PII) from the user via the web browser).
Regarding claim(s) 13,
JIAM, KUMAR, and HRUSKA teach the limitations of claim 1:
JIAM further discloses:
further comprising using the new account to make a payment to the third-party for a purchase made by the user using the third-party application (see, at least, JIAM: [0014]: Moreover, the real time or substantially real time approval and issuance of a transaction account by the transaction account provider to the user may be supplemented by card account pass back to the merchant checkout journey for immediate (or expedited) payment.; [0027]: The user may further agree to have the IAN [(instant account number)] returned to the merchant page for forwarding to a merchant server 6 for immediate use in completing a proposed transaction; [0028]: return of the provision of the IAN from the transaction account provider server 2 to the web browser 4 and then the pre-filling of the purchase payment information and/or decrypted IAN details into the shopping cart experience of the merchant server).
Regarding claim(s) 14,
JIAM, KUMAR, and HRUSKA teach the limitations of claim 1:
JIAM further discloses:
wherein the first set of user data is displayed within the subset of the one or more interface elements (See JIAM: [0029]: encrypted [account number] and customer data may be posted to the merchant's shopping cart by the transmission of a cross document message only if the user authorizes it; [0015]: encrypted account information is returned to the merchant page subject to user consent; ¶[0029]: If the pre-fill is authorized, the encrypted IAN and customer data may be posted to the merchant's shopping cart by the transmission of a cross document message (step 606).; ¶[0028]: an iframe acquisition journey 601 may begin with encryption and signature of customer and account details with merchant's RSA public key and placement on the page displayed in the iframe, such as in step 302 (step 602)); JIAM: [0013]: Integrated customer data may be exchanged between the user and merchant, the user and transaction account provider, and the merchant and transaction account provider. Integrated customer data may comprise data pre-filled into forms of the merchant and/or the transaction account provider based on data previously provided to the other; [0016]: Data entered by a user via the web browser 4 may be cross-populated to both the transaction account provider server 2 and the merchant server 6. Data retrieved individually from the transaction account provider server 2 and the merchant server 6 may be securely passed to the other of the transaction account provider server 2 and the merchant server 6.).
Regarding claim(s) 15,
JIAM, KUMAR, and HRUSKA teach the limitations of claim 1:
JIAM further discloses:
wherein 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 (see, at least, JIAM: ¶[0015]: various processes and systems involve the exchange of sensitive information, such as personally identifying information, transaction account numbers, and/or the like. For instance, as part of an onboarding process, a merchant may share a CA-signed public SSL certificate which was installed within a trust-store of a transaction account company application server; […] digital signature signing and verification based on the PKI and Public Key cryptography, as well as secured RESTful Service over HTTPS POST via transaction account company hosted JavaScript.; ¶[0018]: a banner request ID that uniquely identifies a request for banner to be placed on the webpage, [0019]: service call is instantiated from the web browser and the transaction account provider server may be configured to receive the secured service call; [0020]: transaction account provider server may validate and verify the originating domain of returned webpage content, the merchants digital signature, the banner request ID, the time stamp against a time limit constraint, and/or the like ; [0022]: the transaction account provider server may return to the web browser a secure banner token and a landing page URL for hosting in the iFrame; [0024]: for instance, the credit-card provider may validate and verify the secure URL linked to a portion of the banner corresponding to the user-banner interaction and/or the secure banner token with an expiration date of the dynamic banner; [0015]: white list domain validation may be applied against the domain of the shopping cart experience and/or payment pages; Time-constraint, single-use security tokens for each banner request may be implemented as well; JIAM: [0015]: time-constraint, single-use security tokens for each banner request may be implemented; [0020]: For instance, the transaction account provider server may validate and verify the time stamp against a time limit constraint, and/or the like).
Regarding claim 16,
JIAM discloses:
A method, implemented by an institution computing system of a provider institution (see, at least, JIAM: [0039]: a host server or other computing systems including a processor; [0039]: database in the system includes financial institution data; [0013]: credit or charge card application may be completed and instantly decisioned; [0024]: transaction account provider/credit-card provider server), of providing account open functionality through a service provider computing device of a service provider (see, at least, JIAM: [0013]: all the assets starting with the banner and ending with the conclusion of the checkout journey may be hosted exclusively by the transaction account provider, and yet displayed properly integrated with the merchant shopping cart experience by virtue of the implemented cross domain scripting), the method comprising:
receiving, in response to an interaction with a first interactive element displayed via a first application of the service provider executing on a user computing device of a user, a request for account open functionality, (see, at least, JIAM: [0002]: The present disclosure relates to the integration of banners into third party websites; [0023]: the browser loads a website with content from the merchant server 6 and a banner from the transaction account provider server; see, at least, JIAM: ¶[0013]: More specifically, a banner placed in the checkout journey may exchange integrated customer data, and upon a user clicking the banner, open a modal window on top of the merchant parent window, where a credit or charge card application may be completed and instantly decisioned.)
[…]
providing, to the user computing device, one or more interface elements for presentation via the first application of the service provider (see, at least, JIAM: [0013]: a banner may be placed within a merchant's “checkout journey” ; a banner placed in the checkout journey may exchange integrated customer data, and upon a user clicking the banner, open a modal window on top of the merchant parent window, where a credit or charge card application may be completed and instantly decisioned; all the assets starting with the banner and ending with the conclusion of the checkout journey may be hosted exclusively by the transaction account provider, and yet displayed properly integrated with the merchant shopping cart experience; JIAM: [003]: browser interaction by the user with the merchant page; [0013]: a user click[s] the banner; window may be iFrames or a browser window or a browser tab; [0013]: a banner may be placed within a merchant's “checkout journey” ; a banner placed in the checkout journey may exchange integrated customer data, and upon a user clicking the banner, open a modal window on top of the merchant parent window, where a credit or charge card application may be completed and instantly decisioned; all the assets starting with the banner and ending with the conclusion of the checkout journey may be hosted exclusively by the transaction account provider, and yet displayed properly integrated with the merchant shopping cart experience),
[…]
at least a subset of the one or more interface elements generated to be pre-populated with the first set of user data associated with the user and received in the request (see, at least, JIAM: [0013]: Integrated customer data may be exchanged between the user and merchant, the user and transaction account provider, and the merchant and transaction account provider. Integrated customer data may comprise data pre-filled into forms of the merchant and/or the transaction account provider based on data previously provided to the other; [0016]: Data entered by a user via the web browser 4 may be cross-populated to both the transaction account provider server 2 and the merchant server 6. Data retrieved individually from the transaction account provider server 2 and the merchant server 6 may be securely passed to the other of the transaction account provider server 2 and the merchant server 6.);
receiving, from the service provider computing device, an account open request comprising a second set of user data transmitted by the service provider computing device to the institution computing system via a telecommunications network (see, at least, JIAM: ¶[0013]: More specifically, a banner placed in the checkout journey may exchange integrated customer data, and upon a user clicking the banner, open a modal window on top of the merchant parent window, where a credit or charge card application may be completed and instantly decisioned.; see, at least, JIAM: [0013]: Integrated customer data may be exchanged between the user and merchant, the user and transaction account provider, and the merchant and transaction account provider. Integrated customer data may comprise data pre-filled into forms of the merchant and/or the transaction account provider based on data previously provided to the other; [0016]: Data entered by a user via the web browser 4 may be cross-populated to both the transaction account provider server 2 and the merchant server 6. Data retrieved individually from the transaction account provider server 2 and the merchant server 6 may be securely passed to the other of the transaction account provider server 2 and the merchant server 6.)
and a code generated by the service provider computing device (see, at least, JIAM: ¶[0015]:, as part of an onboarding process, a merchant may share a CA-signed public SSL certificate which was installed within a trust-store of a transaction account company application server; […] digital signature signing and verification based on the PKI and Public Key cryptography, as well as secured RESTful Service over HTTPS POST via transaction account company hosted JavaScript.; ¶[0018]: a banner request ID that uniquely identifies a request for banner to be placed on the webpage, [0019]: service call is instantiated from the web browser and the transaction account provider server may be configured to receive the secured service call; [0020]: transaction account provider server may validate and verify the originating domain of returned webpage content, the merchants digital signature, the banner request ID, the time stamp against a time limit constraint, and/or the like ; [0022]: the transaction account provider server may return to the web browser a secure banner token and a landing page URL for hosting in the iFrame; [0024]: for instance, the credit-card provider may validate and verify the secure URL linked to a portion of the banner corresponding to the user-banner interaction and/or the secure banner token with an expiration date of the dynamic banner; ¶[0027]: The IAN may be provided […] in a format that comprises an encrypted variable encrypted using the merchant's public key in a hidden variable of the displayed webpage displayed in the web browser),
the code comprising an identifier of the service provider (see, at least, JIAM: ¶[0015]: various processes and systems involve the exchange of sensitive information, such as personally identifying information, transaction account numbers, and/or the like. For instance, as part of an onboarding process, a merchant may share a CA-signed public SSL certificate which was installed within a trust-store of a transaction account company application server; […] digital signature signing and verification based on the PKI and Public Key cryptography, as well as secured RESTful Service over HTTPS POST via transaction account company hosted JavaScript.; ¶[0018]: a banner request ID that uniquely identifies a request for banner to be placed on the webpage, [0019]: service call is instantiated from the web browser and the transaction account provider server may be configured to receive the secured service call; [0020]: transaction account provider server may validate and verify the originating domain of returned webpage content, the merchants digital signature, the banner request ID, the time stamp against a time limit constraint, and/or the like ; ¶[0021]: the transaction account provider server 2 may prepare a dynamic banner comprising one or more of a secure banner token with […] a secure URL linked to a portion of the banner ( e.g., an "APPLY NOW" button whereby a user may apply for a transaction account of the transaction account provider); [0022]: the transaction account provider server may return to the web browser a secure banner token and a landing page URL for hosting in the iFrame; [0024]: for instance, the credit-card provider may validate and verify the secure URL linked to a portion of the banner corresponding to the user-banner interaction and/or the secure banner token with an expiration date of the dynamic banner; [0015]: white list domain validation may be applied against the domain of the shopping cart experience and/or payment pages; Time-constraint, single-use security tokens for each banner request may be implemented as well),
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 (see, at least, JIAM: [0013]: Integrated customer data may be exchanged between the user and merchant, the user and transaction account provider, and the merchant and transaction account provider. Integrated customer data may comprise data pre-filled into forms of the merchant and/or the transaction account provider based on data previously provided to the other; [0014]: Personally identifiable information (PII) may be autofilled into documents of the transaction account provider and/or the merchant. The population of the documents may be in real time, or substantially real time. Moreover, the real time or substantially real time approval and issuance of a transaction account by the transaction account provider to the user may be supplemented by card account pass back to the merchant checkout journey for immediate (or expedited) payment. Furthermore, banners (e.g., prescreened offer requests) may be presented based on the PII.); [0034]: Internal data may be gathered before, during, or after a relationship between the credit issuer and the transaction account holder (e.g., the consumer or buyer), [0016]: Data entered by a user via the web browser 4 may be cross-populated to both the transaction account provider server 2 and the merchant server 6. Data retrieved individually from the transaction account provider server 2 and the merchant server 6 may be securely passed to the other of the transaction account provider server 2 and the merchant server 6.)),
and 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 service provider computing device (see, at least, JIAM: [0029]: encrypted [account number] and customer data may be posted to the merchant's shopping cart by the transmission of a cross document message only if the user authorizes it; [0015]: encrypted account information is returned to the merchant page subject to user consent; ¶[0029]: If the pre-fill is authorized, the encrypted IAN and customer data may be posted to the merchant's shopping cart by the transmission of a cross document message (step 606).; ¶[0028]: an iframe acquisition journey 601 may begin with encryption and signature of customer and account details with merchant's RSA public key and placement on the page displayed in the iframe, such as in step 302 (step 602)),
the code generated by the service provider computing device based on a format designated by the provider institution (see, at least, JIAM ¶[0027]: The IAN may be provided from the transaction account provider server 2 to the web browser 4 in a format that comprises an encrypted variable encrypted using the merchant's public key in a hidden variable of the displayed webpage displayed in the web browser; ¶[0015]: As will be discussed further herein, various processes and systems involve the exchange of sensitive information, such as personally identifying information, transaction account numbers, and/or the like. For instance, as part of an onboarding process, a merchant may share a CA-signed public SSL certificate which was installed within a trust-store of a transaction account company application server. The merchant may also specify the domain of their shopping cart experience, and/or payment pages in which transaction account company hosted banners (e.g., dynamic banner JavaScript banners) will be sourced. The transaction account company may have assigned a merchant-id to the merchant, such that the merchant is identified. Moreover, further security may be implemented, such as digital signature signing and verification based on the PKI and Public Key cryptography, as well as secured RESTful Service over HTTPS POST via transaction account company hosted JavaScript.),
[…]
and validating 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 via the first application (see, at least, JIAM: [0014]: Personally identifiable information (PII) may be autofilled into documents of the transaction account provider and/or the merchant. [...] the real time or substantially real time approval and issuance of a transaction account by the transaction account provider to the user may be supplemented by card account pass back to the merchant checkout journey for immediate (or expedited) payment.); [0027]-[0028]: Instant account number is returned to the merchant page for immediate use in completing a proposed transaction and the account details and purchase payment information are pre-filled into the shopping cart experience of the web browser),
wherein 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 (see, at least, JIAM: [0012]: merchants integrate banners or transaction account application processes into their online shopping cart pages.; [0014]: Personally identifiable information (PII) may be autofilled into documents of the transaction account provider and/or the merchant. [...] the real time or substantially real time approval and issuance of a transaction account by the transaction account provider to the user may be supplemented by card account pass back to the merchant checkout journey for immediate (or expedited) payment.); [0016]: a banner may be sourced from a transaction account provider server 2 and integrated into a shopping cart experience (sourced from a merchant server 6), which is displayed inside a web browser 4; [0023]: a seamless (or near seamless) user experience manifests, wherein the browser loads a website with content from the merchant server 6 and a banner from the transaction account provider server; [0027]-[0028]: Instant account number is returned to the merchant page for immediate use in completing a proposed transaction and the account details and purchase payment information are pre-filled into the shopping cart experience of the web browser).
JIAM discloses a establishing an account, as shown, but does not expressly disclose the following limitations, which HRUSKA however, teaches:
establishing, a new account for the user of the user computing device at least in part by (i) parsing the code to obtain the identifier of the provider institution (HRUSKA: ¶[0018]: server decrypts the unique, time-sensitive active digital token with the appended consumer and merchant information and token information is then “matched against the stored information”),
(ii) validating the first set of user data or the second set of user data using the code (HRUSKA: ¶[0018]: Once scanned and decoded by the POS application, the application subsequently appends the unique merchant identifier (UMID) to the inactive valued digital token that was passed from the consumer's mobile device. Once this is confirmed, using the one way hashed encryption technique used on the receiving token and matched against the stored information on the server backend; the appended digital valued token data (the UDID, the UAID, the UMID and also the valued digital token itself must match to what is on file in the transactional server consumer's account to confirm transactional authentication; [0004] consumer's mobile handheld device has its own unique identifier (UDID), a proprietary unique mobile application also having its own unique identifier (UAID) downloaded to the registered device.),
It would have been obvious to one of ordinary skill in the art at the time of filing to combine/modify the system/method of JIAM, which discloses integrating transaction account application processes into merchant online shopping cart pages (JIAM [0003]) and transaction account provider server receiving a secured CORS HTTPS RESTful service call (JIAM [0019]) with the technique of HRUSKA, which discloses a system and a method for secure financial transactions over a computer network, internet system and telecommunication network (HRUSKA [0001]) in order to enhance security of transactions (HRUSKA [0006]) and protect transactions from prying eyes of hackers and secure personal information and financial instruments (HRUSKA ¶[0002]).
JIAM does not expressly disclose the following limitations, which KUMAR however, teaches:
the user having a third-party account with the service provider (KUMAR: ¶[0041]: Turning first to the user-centered straight through processing 300 example, in 304, an investor 104 may login to the app 144 ( e.g., using a personal computer, smartphone, tablet, or other device as discussed above). In 306, using the app 144, the user may choose "self-service" or a similar option and enter information; ¶[0042]: In 310, the advisor 102 may log into the app 144 (e.g., using a personal computer, smartphone, tablet, or other device as discussed above). In 312, the advisor 102 may create an account for the investor 104 and/or transaction to be processed. In 314, the advisor 102 may select forms for the account using the app 144.; ¶[0048]: Turning to the system processing 400 example, corresponding to the user-centered straight through processing 300, in 402, the CRM cloud 140 may receive user login data from the advisor 102 ( e.g., through the app 144) and log the user in. In 404, the CRM cloud 140 may receive client information from the advisor 102 through the app 144. In 406, if the client information relates to a new client, the CRM cloud 140 may create a new account (if not, this step may be skipped),
the request comprising a first set of user data of the user stored in association with the third-party account (KUMAR: [0032]: b. Certain custodians may also provide an API/mechanism to transmit data elements to this portal such that these data elements may be prefilled in the portal, and the user may not have to re-enter them. In such cases, the system 100 may capture the account information, validate and transform it, and send it across to the custodian by a pre-fill API/ mechanism. The system 100 may launch the custodian portal for the user to complete the account opening process with the appropriate data pre-filled; [0036] For the forms pre-fill, system 100 data may be transformed and formatted as required by the forms vendors. The transformations may be analogous but distinct from the transformations required for the account opening APL The system 100 may retain the unified data model but perform custodian and even form specific transformations as needed; ¶[0093]: Generate pre-fill request for a forms);
the one or more interface elements invoking an application programming interface (API) of the provider institution to access the account open functionality (see, at least, KUMAR: [0011]: financial accounts are established with custodians; Account opening information may include account type and account preferences; figure 1 and [0021]: Users/advisors interact with the App 14; [0021]: The services cloud may be in communication with custodian platforms including a custodian API service 134; Users (e.g., advisor 102) may interact with the app 144 using computing devices such as personal computers, smartphones, tablets, laptops, or the like; [0028]: account opening request; [0031]: For custodians that provide an API for opening accounts (straight through processing), the system 100 may send the translated data using proprietary custodian APIs and display the return status to provide users with a seamless experience and return an account number; [0032]: Other custodians may provide an API to transmit data elements to a portal for users to open accounts wherein the system launches the portal with prefilled data to complete the account opening process; [0040]: Straight through processing 300 may integrate the system 100 directly with the end custodian and allow a user to create an account with the click of a button),
an identifier of the provider institution (KUMAR: ¶[0084]: The JSON snippet may look like: TABLE-US-00001 {“skience_product_company”: “National Financial”, “skience_account_registration_type”: “Joint - With Rights of Survivorship”, “skience_product_type”: “Brokerage” }; ¶[0085]: The XML snippet may look like: TABLE-US-00002 <skience_product_company>National Financial</skience_product_company> <skience_account_registration_type> Joint - With Rights of Survivorship </skience_account_registration_type> <skience_product_type> Brokerage</skience_product_type > ),
the identifier of the service provider computing device (KUMAR: ¶[0084]: The JSON snippet may look like: TABLE-US-00001 {“skience_product_company”: “National Financial”, “skience_account_registration_type”: “Joint - With Rights of Survivorship”, “skience_product_type”: “Brokerage” }; ¶[0085]: The XML snippet may look like: TABLE-US-00002 <skience_product_company>National Financial</skience_product_company> <skience_account_registration_type> Joint - With Rights of Survivorship </skience_account_registration_type> <skience_product_type> Brokerage</skience_product_type >; [0095] i. Map requested custodian to registered straight through processing interface; ¶[0039]: internet information services (IIS) server 210 may process an account creation, including communicating with an account opening API 212 of a custodian platform 130 to actually open the account within the custodian's database 214. ),
an identifier of a type of account to open (KUMAR: ¶[0029]: For trust accounts, Pershing may require entry of the type of trust, for example family trust, charitable trust, irrevocable trust, living trust, and other types of trusts. NFS may not require or support a data element for the type of trust. The system 100 data model may capture the type of trust. If opening an account for the trust, the system may send the type of trust to Pershing but not send the same to NFS. If this value were not filled, the system 100 may allow the user to create an account with NFS, but if the user were to try and create an account with Pershing without filling the type of trust, the system 100 may display a message and require the user to fill in the value in order to avoid a NIGO [not in good order (NIGO) rejection].);
and the identifier of the type of account to open (KUMAR: ¶[0026]: Individual registration type: A user may want to create an individual account. NFS (a custodian) may require a value of I for individual accounts. Pershing (another custodian) may require a value of INDV. The system 100 may present the registration type as Individual and then map to either I (for NFS) or INDV (for Pershing); [0029]: d. Data elements may be specific to certain custodians: For trust accounts, Pershing may require entry of the type of trust, for example family trust, charitable trust, irrevocable trust, living trust, and other types of trusts; [0029]: The system 100 data model may capture the type of trust. If opening an account for the trust, the system may send the type of trust to Pershing.),
, 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 (KUMAR: [0031]: Thus, users may input data in the system 100, the data may be validated and transformed in the system 100 and transmitted to the custodians via the appropriate custodian API. The custodian API may also run its own validations and if all validations succeed, may return an account number. This account number may be populated in the system 100 to complete the process. [0032]: the system 100 may capture the account information, validate and transform it,[…] The system 100 may launch the custodian portal for the user to complete the account opening process with the appropriate data pre-filled.; ¶[048]: the CRM cloud 140 may receive client information from the advisor 102 through the app 144. In 406, if the client information relates to a new client, the CRM cloud 140 may create a new account; [0055]: . If authentication is successful, in 432, the services cloud 110 may validate the client information.[…] If validation is successful, in 434, the services cloud 110 may send a web services request to the custodian 130 API including the validated information; [0056]: In 436, the custodian 130 may accept the information and generate an account number. The custodian 130 may return the account number to the services cloud 110, which may send the account number to the CRM cloud 140.);
It would have been obvious to one of ordinary skill in the art at the time of filing to combine/modify the system/method of JIAM, which discloses integrating transaction account application processes into merchant online shopping cart pages (JIAM [0003]) and transaction account provider server receiving a secured CORS HTTPS RESTful service call (JIAM [0019]) with the technique of KUMAR, which discloses opening a financial account using an integrated system (KUMAR [0008]) in order to provide users with a seamless account-opening experience (KUMAR [0030]) and to include data elements that are specific to certain custodians/account providers (KUMAR [0029]).
Regarding claim(s) 18,
JIAM, KUMAR, and HRUSKA teach the limitations of claim 16.
JIAM further discloses:
wherein the service provider computing device transmits the account open request to the institution computing system in response to a signal received at the user computing device via the first application, the signal indicating that the user has selected to open the new account with the provider institution (see, at least, JIAM: [0002]: The present disclosure relates to the integration of banners into third party websites; [0023]: the browser loads a website with content from the merchant server 6 and a banner from the transaction account provider server; ¶[0021]: in response to a user interaction with the banner such as clicking an “APPLY NOW” button; JIAM:¶[0013]: a banner may be placed within a merchant's “checkout journey” (e.g., the process whereby a user selects and ultimately purchases items from the merchant); banner placed in the checkout journey may exchange integrated customer data, and upon a user clicking the banner, open a modal window on top of the merchant parent window, where a credit or charge card application may be completed and instantly decisioned.; ¶[0017]: web browser 4 navigate[s] to a merchant check out page (e.g., shopping cart experience/merchant checkout journey)).
Regarding claim(s) 19,
JIAM, KUMAR, and HRUSKA teach the limitations of claim 16.
JIAM further discloses:
wherein the first set of user data includes: a first user data subset received at the service provider computing device from the user computing device before the first application receives a user request to open the new account with the provider institution (see, at least, JIAM: [0013]: Integrated customer data may comprise data pre-filled into forms of the merchant and/or the transaction account provider based on data previously provided to the other.; [0017]: For example, a web browser 4 may receive a navigation command directing the web browser 4 to navigate to a merchant check out page (e.g., shopping cart experience/merchant checkout journey) (step 102). In response, the merchant server 6 may prepare a checkout webpage. [...]. Moreover, this may involve setting up personally identifiable information (PII) receiver fields of the merchant check out page in preparation for the collection of personally identifiable information (PII) from the user via the web browser); and
a second user data subset received at the service provider computing device from the user computing device after the first application receives the user request to open the new account with the provider institution (see, at least, JIAM: [0014]: account information may pass back from the transaction account provider to the merchant, and PII may pass from the merchant to the transaction account provider; [0016]: Data entered by a user via the web browser 4 may be cross-populated to both the transaction account provider server 2 and the merchant server 6. Data retrieved individually from the transaction account provider server 2 and the merchant server 6 may be securely passed to the other of the transaction account provider server 2 and the merchant server 6.).
Regarding claim(s) 20,
JIAM discloses:
An institution computing system (see, at least, JIAM: [0039]: a host server or other computing systems including a processor; [0039]: database in the system includes financial institution data; [0013]: credit or charge card application may be completed and instantly decisioned; [0024]: transaction account provider/credit-card provider server)
for providing account open functionality through a service provider computing device of a service provider (see, at least, JIAM: [0013]: all the assets starting with the banner and ending with the conclusion of the checkout journey may be hosted exclusively by the transaction account provider, and yet displayed properly integrated with the merchant shopping cart experience by virtue of the implemented cross domain scripting),
the institution computing system being associated with a provider institution, the institution computing system (see, at least, JIAM: [0039]: a host server or other computing systems including a processor; [39]: database in the system includes financial institution data; [0013]: credit or charge card application may be completed and instantly decisioned; [0024]: transaction account provider/credit-card provider server)
of providing account-open functionality through a service provider computing device of a service provider (see, at least, JIAM: [0013]: all the assets starting with the banner and ending with the conclusion of the checkout journey may be hosted exclusively by the transaction account provider, and yet displayed properly integrated with the merchant shopping cart experience by virtue of the implemented cross domain scripting)
comprising: a network interface configured to communicate with the service provider computing device via a telecommunications network (see, at least, JIAM: [0016]: A web browser may communicate with both the transaction account provider server and the merchant server; [0032]: network; [0041]: The processor is connected to a communication infrastructure (e.g., a communications bus, cross over bar, or network); [0044]: Computer system may also include a communications interface which allows software and data to be transferred between computer system and external devices.; [0052]: Web services applications interacting with other applications over a communications means, such as the internet);
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 (JIAM: [0039]: The various system components may include one or more of the following: a host server or other computing systems including a processor for processing digital data; a memory coupled to the processor for storing digital data; an input digitizer coupled to the processor for inputting digital data; an application program stored in the memory and accessible by the processor for directing processing of digital data by the processor; a display device coupled to the processor and memory for displaying information derived from digital data processed by the processor; and a plurality of databases;. [0040] The present system or any part(s) or function(s) thereof may be implemented using hardware, software or a combination thereof and may be implemented in one or more computer systems or other processing systems).
receive, in response to an interaction with a first interactive element displayed via a first application of the service provider executing on a user computing device of a user, a request for account open functionality , (see, at least, JIAM: [0002]: The present disclosure relates to the integration of banners into third party websites; [0023]: the browser loads a website with content from the merchant server 6 and a banner from the transaction account provider server; see, at least, JIAM: ¶[0013]: More specifically, a banner placed in the checkout journey may exchange integrated customer data, and upon a user clicking the banner, open a modal window on top of the merchant parent window, where a credit or charge card application may be completed and instantly decisioned.),
[…]
provide, to the user computing device, one or more interface elements for presentation via the first application of the service provider (see, at least, JIAM: [0013]: a banner may be placed within a merchant's “checkout journey” ; a banner placed in the checkout journey may exchange integrated customer data, and upon a user clicking the banner, open a modal window on top of the merchant parent window, where a credit or charge card application may be completed and instantly decisioned; all the assets starting with the banner and ending with the conclusion of the checkout journey may be hosted exclusively by the transaction account provider, and yet displayed properly integrated with the merchant shopping cart experience; JIAM: [003]: browser interaction by the user with the merchant page; [0013]: a user click[s] the banner; window may be iFrames or a browser window or a browser tab; [0013]: a banner may be placed within a merchant's “checkout journey” ; a banner placed in the checkout journey may exchange integrated customer data, and upon a user clicking the banner, open a modal window on top of the merchant parent window, where a credit or charge card application may be completed and instantly decisioned; all the assets starting with the banner and ending with the conclusion of the checkout journey may be hosted exclusively by the transaction account provider, and yet displayed properly integrated with the merchant shopping cart experience),
[…]
at least a subset of the one or more interface elements generated to be pre-populated with the first set of user data associated with the user and received in the request (see, at least, JIAM: [0013]: Integrated customer data may be exchanged between the user and merchant, the user and transaction account provider, and the merchant and transaction account provider. Integrated customer data may comprise data pre-filled into forms of the merchant and/or the transaction account provider based on data previously provided to the other; [0016]: Data entered by a user via the web browser 4 may be cross-populated to both the transaction account provider server 2 and the merchant server 6. Data retrieved individually from the transaction account provider server 2 and the merchant server 6 may be securely passed to the other of the transaction account provider server 2 and the merchant server 6.);
receive, from the service provider computing device via the network interface, an account open request comprising a second set of user data transmitted by the service provider computing device to the institution computing system via the telecommunications network (see, at least, JIAM: ¶[0013]: More specifically, a banner placed in the checkout journey may exchange integrated customer data, and upon a user clicking the banner, open a modal window on top of the merchant parent window, where a credit or charge card application may be completed and instantly decisioned.; see, at least, JIAM: [0013]: Integrated customer data may be exchanged between the user and merchant, the user and transaction account provider, and the merchant and transaction account provider. Integrated customer data may comprise data pre-filled into forms of the merchant and/or the transaction account provider based on data previously provided to the other; [0016]: Data entered by a user via the web browser 4 may be cross-populated to both the transaction account provider server 2 and the merchant server 6. Data retrieved individually from the transaction account provider server 2 and the merchant server 6 may be securely passed to the other of the transaction account provider server 2 and the merchant server 6.)
and a code generated by the service provider computing device (see, at least, JIAM: ¶[0015]:, as part of an onboarding process, a merchant may share a CA-signed public SSL certificate which was installed within a trust-store of a transaction account company application server; […] digital signature signing and verification based on the PKI and Public Key cryptography, as well as secured RESTful Service over HTTPS POST via transaction account company hosted JavaScript.; ¶[0018]: a banner request ID that uniquely identifies a request for banner to be placed on the webpage, [0019]: service call is instantiated from the web browser and the transaction account provider server may be configured to receive the secured service call; [0020]: transaction account provider server may validate and verify the originating domain of returned webpage content, the merchants digital signature, the banner request ID, the time stamp against a time limit constraint, and/or the like ; [0022]: the transaction account provider server may return to the web browser a secure banner token and a landing page URL for hosting in the iFrame; [0024]: for instance, the credit-card provider may validate and verify the secure URL linked to a portion of the banner corresponding to the user-banner interaction and/or the secure banner token with an expiration date of the dynamic banner; ¶[0027]: The IAN may be provided […] in a format that comprises an encrypted variable encrypted using the merchant's public key in a hidden variable of the displayed webpage displayed in the web browser),
the code comprising an identifier of the provider institution (see, at least, JIAM: ¶[0015]: various processes and systems involve the exchange of sensitive information, such as personally identifying information, transaction account numbers, and/or the like. For instance, as part of an onboarding process, a merchant may share a CA-signed public SSL certificate which was installed within a trust-store of a transaction account company application server; […] digital signature signing and verification based on the PKI and Public Key cryptography, as well as secured RESTful Service over HTTPS POST via transaction account company hosted JavaScript.; ¶[0018]: a banner request ID that uniquely identifies a request for banner to be placed on the webpage, [0019]: service call is instantiated from the web browser and the transaction account provider server may be configured to receive the secured service call; [0020]: transaction account provider server may validate and verify the originating domain of returned webpage content, the merchants digital signature, the banner request ID, the time stamp against a time limit constraint, and/or the like ; ¶[0021]: the transaction account provider server 2 may prepare a dynamic banner comprising one or more of a secure banner token with […] a secure URL linked to a portion of the banner ( e.g., an "APPLY NOW" button whereby a user may apply for a transaction account of the transaction account provider); [0022]: the transaction account provider server may return to the web browser a secure banner token and a landing page URL for hosting in the iFrame; [0024]: for instance, the credit-card provider may validate and verify the secure URL linked to a portion of the banner corresponding to the user-banner interaction and/or the secure banner token with an expiration date of the dynamic banner; [0015]: white list domain validation may be applied against the domain of the shopping cart experience and/or payment pages; Time-constraint, single-use security tokens for each banner request may be implemented as well),
[…]
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 (see, at least, JIAM: [0013]: Integrated customer data may be exchanged between the user and merchant, the user and transaction account provider, and the merchant and transaction account provider. Integrated customer data may comprise data pre-filled into forms of the merchant and/or the transaction account provider based on data previously provided to the other; [0014]: Personally identifiable information (PII) may be autofilled into documents of the transaction account provider and/or the merchant. The population of the documents may be in real time, or substantially real time. Moreover, the real time or substantially real time approval and issuance of a transaction account by the transaction account provider to the user may be supplemented by card account pass back to the merchant checkout journey for immediate (or expedited) payment. Furthermore, banners (e.g., prescreened offer requests) may be presented based on the PII.); [0034]: Internal data may be gathered before, during, or after a relationship between the credit issuer and the transaction account holder (e.g., the consumer or buyer), [0016]: Data entered by a user via the web browser 4 may be cross-populated to both the transaction account provider server 2 and the merchant server 6. Data retrieved individually from the transaction account provider server 2 and the merchant server 6 may be securely passed to the other of the transaction account provider server 2 and the merchant server 6.)),
and 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 service provider computing device (see, at least, JIAM: [0029]: encrypted [account number] and customer data may be posted to the merchant's shopping cart by the transmission of a cross document message only if the user authorizes it; [0015]: encrypted account information is returned to the merchant page subject to user consent; ¶[0029]: If the pre-fill is authorized, the encrypted IAN and customer data may be posted to the merchant's shopping cart by the transmission of a cross document message (step 606).; ¶[0028]: an iframe acquisition journey 601 may begin with encryption and signature of customer and account details with merchant's RSA public key and placement on the page displayed in the iframe, such as in step 302 (step 602)),
the code generated by the service provider computing device based on a format designated by the provider institution (see, at least, JIAM ¶[0027]: The IAN may be provided from the transaction account provider server 2 to the web browser 4 in a format that comprises an encrypted variable encrypted using the merchant's public key in a hidden variable of the displayed webpage displayed in the web browser; ¶[0015]: As will be discussed further herein, various processes and systems involve the exchange of sensitive information, such as personally identifying information, transaction account numbers, and/or the like. For instance, as part of an onboarding process, a merchant may share a CA-signed public SSL certificate which was installed within a trust-store of a transaction account company application server. The merchant may also specify the domain of their shopping cart experience, and/or payment pages in which transaction account company hosted banners (e.g., dynamic banner JavaScript banners) will be sourced. The transaction account company may have assigned a merchant-id to the merchant, such that the merchant is identified. Moreover, further security may be implemented, such as digital signature signing and verification based on the PKI and Public Key cryptography, as well as secured RESTful Service over HTTPS POST via transaction account company hosted JavaScript.)
[…]
generating a set of account data associated with the new account (JIAM: ¶[0015]: For instance, as part of an onboarding process, a merchant may share a CAsigned public SSL certificate which was installed within a trust-store of a transaction account company application server. The merchant may also specify the domain of their shopping cart experience, and/or payment pages in which transaction account company hosted banners (e.g., dynamic banner JavaScript banners) will be sourced. The transaction account company may have assigned a merchant-id to the merchant, such that the merchant is identified. Moreover, further security may be implemented, such as digital signature signing and verification based on the PKI and Public Key cryptography, as well as secured RESTful Service over HTTPS POST via transaction account company hosted JavaScript.; ¶[0017]: In response, the merchant server 6 may prepare a checkout webpage, for instance, a JSP/ASP webpage. This may comprise, for example, creating a digital signature by signing on the current timestamp using the merchant's SSL certificate private key; JIAM: ¶[0027]-[0028]: Instant account number is returned to the merchant page for immediate use in completing a proposed transaction and the account details and purchase payment information are pre-filled into the shopping cart experience of the web browser; ¶[0027]: instant account number (IAN) may be provided in a format that comprise an encrypted variable using the merchant’s public key in a hidden variable of the displayed webpage);
and transmit, via the network interface, 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 via the first application (see, at least, JIAM: [0014]: Personally identifiable information (PII) may be autofilled into documents of the transaction account provider and/or the merchant. [...] the real time or substantially real time approval and issuance of a transaction account by the transaction account provider to the user may be supplemented by card account pass back to the merchant checkout journey for immediate (or expedited) payment.); [0027]-[0028]: Instant account number is returned to the merchant page for immediate use in completing a proposed transaction and the account details and purchase payment information are pre-filled into the shopping cart experience of the web browser),
wherein 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 (see, at least, JIAM: [0012]: merchants integrate banners or transaction account application processes into their online shopping cart pages.; [0014]: Personally identifiable information (PII) may be autofilled into documents of the transaction account provider and/or the merchant. [...] the real time or substantially real time approval and issuance of a transaction account by the transaction account provider to the user may be supplemented by card account pass back to the merchant checkout journey for immediate (or expedited) payment.); [0016]: a banner may be sourced from a transaction account provider server 2 and integrated into a shopping cart experience (sourced from a merchant server 6), which is displayed inside a web browser 4; [0023]: a seamless (or near seamless) user experience manifests, wherein the browser loads a website with content from the merchant server 6 and a banner from the transaction account provider server; [0027]-[0028]: Instant account number is returned to the merchant page for immediate use in completing a proposed transaction and the account details and purchase payment information are pre-filled into the shopping cart experience of the web browser).
JIAM does not expressly disclose the following limitations, which KUMAR however, teaches:
the user having a third-party account with the service provider, the request comprising a first set of user data of the user stored in association with the third-party account (KUMAR: ¶[0041]: Turning first to the user-centered straight through processing 300 example, in 304, an investor 104 may login to the app 144 ( e.g., using a personal computer, smartphone, tablet, or other device as discussed above). In 306, using the app 144, the user may choose "self-service" or a similar option and enter information; ¶[0042]: In 310, the advisor 102 may log into the app 144 (e.g., using a personal computer, smartphone, tablet, or other device as discussed above). In 312, the advisor 102 may create an account for the investor 104 and/or transaction to be processed. In 314, the advisor 102 may select forms for the account using the app 144.; ¶[0048]: Turning to the system processing 400 example, corresponding to the user-centered straight through processing 300, in 402, the CRM cloud 140 may receive user login data from the advisor 102 ( e.g., through the app 144) and log the user in. In 404, the CRM cloud 140 may receive client information from the advisor 102 through the app 144. In 406, if the client information relates to a new client, the CRM cloud 140 may create a new account (if not, this step may be skipped);
the one or more interface elements invoking an application programming interface (API) of the provider institution to access the account open functionality (see, at least, KUMAR: [0011]: financial accounts are established with custodians; Account opening information may include account type and account preferences; figure 1 and [0021]: Users/advisors interact with the App 14; [0021]: The services cloud may be in communication with custodian platforms including a custodian API service 134; Users (e.g., advisor 102) may interact with the app 144 using computing devices such as personal computers, smartphones, tablets, laptops, or the like; [0028]: account opening request; [0031]: For custodians that provide an API for opening accounts (straight through processing), the system 100 may send the translated data using proprietary custodian APIs and display the return status to provide users with a seamless experience and return an account number; [0032]: Other custodians may provide an API to transmit data elements to a portal for users to open accounts wherein the system launches the portal with prefilled data to complete the account opening process; [0040]: Straight through processing 300 may integrate the system 100 directly with the end custodian and allow a user to create an account with the click of a button),
an identifier of the provider institution, […] (KUMAR: ¶[0084]: The JSON snippet may look like: TABLE-US-00001 {“skience_product_company”: “National Financial”, “skience_account_registration_type”: “Joint - With Rights of Survivorship”, “skience_product_type”: “Brokerage” }; ¶[0085]: The XML snippet may look like: TABLE-US-00002 <skience_product_company>National Financial</skience_product_company> <skience_account_registration_type> Joint - With Rights of Survivorship </skience_account_registration_type> <skience_product_type> Brokerage</skience_product_type > )
the identifier of the service provider computing device (KUMAR: ¶[0084]: The JSON snippet may look like: TABLE-US-00001 {“skience_product_company”: “National Financial”, “skience_account_registration_type”: “Joint - With Rights of Survivorship”, “skience_product_type”: “Brokerage” }; ¶[0085]: The XML snippet may look like: TABLE-US-00002 <skience_product_company>National Financial</skience_product_company> <skience_account_registration_type> Joint - With Rights of Survivorship </skience_account_registration_type> <skience_product_type> Brokerage</skience_product_type >; [0095] i. Map requested custodian to registered straight through processing interface; ¶[0039]: internet information services (IIS) server 210 may process an account creation, including communicating with an account opening API 212 of a custodian platform 130 to actually open the account within the custodian's database 214. ),
and an identifier of a type of account to open (KUMAR: ¶[0026]: Individual registration type: A user may want to create an individual account. NFS (a custodian) may require a value of I for individual accounts. Pershing (another custodian) may require a value of INDV. The system 100 may present the registration type as Individual and then map to either I (for NFS) or INDV (for Pershing); [0029]: d. Data elements may be specific to certain custodians: For trust accounts, Pershing may require entry of the type of trust, for example family trust, charitable trust, irrevocable trust, living trust, and other types of trusts; [0029]: The system 100 data model may capture the type of trust. If opening an account for the trust, the system may send the type of trust to Pershing.);
It would have been obvious to one of ordinary skill in the art at the time of filing to combine/modify the system/method of JIAM, which discloses integrating transaction account application processes into merchant online shopping cart pages (JIAM [0003]) and transaction account provider server receiving a secured CORS HTTPS RESTful service call (JIAM [0019]) with the technique of KUMAR, which discloses opening a financial account using an integrated system (KUMAR [0008]) in order to provide users with a seamless account-opening experience (KUMAR [0030]) and to include data elements that are specific to certain custodians/account providers (KUMAR [0029]).
JIAM teaches establishing an account does not expressly disclose the following limitations, which HRUSKA however, teaches:
establish a new account for the user of the user computing device at least in part by (i) parsing the code to obtain (HRUSKA: ¶[0018]: server decrypts the unique, time-sensitive active digital token with the appended consumer and merchant information and token information is then “matched against the stored information”)
(ii) validating the first set of user data or the second set of user data using the code (HRUSKA: ¶[0018]: Once scanned and decoded by the POS application, the application subsequently appends the unique merchant identifier (UMID) to the inactive valued digital token that was passed from the consumer's mobile device. Once this is confirmed, using the one way hashed encryption technique used on the receiving token and matched against the stored information on the server backend; the appended digital valued token data (the UDID, the UAID, the UMID and also the valued digital token itself must match to what is on file in the transactional server consumer's account to confirm transactional authentication; [0004] consumer's mobile handheld device has its own unique identifier (UDID), a proprietary unique mobile application also having its own unique identifier (UAID) downloaded to the registered device.),
and encrypted by the service provider computing device according to an encryption format different from the format designated by the provider institution (see, at least, HRUSKA: [0004]: The invention describes a consumer setting up a financial proxy account; the merchant proprietary application then appending the merchant specific id to the digital inactive token code to render the token active and subsequently encrypting the information with the system's public key for transmission to the backend transactional server.),
It would have been obvious to one of ordinary skill in the art at the time of filing to combine/modify the system/method of JIAM, which discloses integrating transaction account application processes into merchant online shopping cart pages (JIAM [0003]) and transaction account provider server receiving a secured CORS HTTPS RESTful service call (JIAM [0019]) with the technique of HRUSKA, which discloses a system and a method for secure financial transactions over a computer network, internet system and telecommunication network (HRUSKA [0001]) in order to enhance security of transactions (HRUSKA [0006]) and protect transactions from prying eyes of hackers and secure personal information and financial instruments (HRUSKA ¶[0002]).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over JIAM, M. et al. to US 20170024716 A1 (“JIAM”) in view of US 20180060965 A1 to KUMAR, S. (“KUMAR”) in further view of US 10467689 B2 to CHEN, H., (“CHEN”).
Regarding claim(s) 3,
JIAM, KUMAR, and HRUSKA teach the limitations of claim 1.
JIAM does not expressly disclose the following limitations, which CHEN however, teaches:
wherein the one or more interface elements include one or more software development kits (SDKs) (see, at least, CHEN column(s) 13, line(s) 52-67 to column(s) 14, line(s) 1-10: “[...] [M]obile 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. [...] In various embodiments, 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. [...]”).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify the combination of JIAM, KUMAR, and HRUSKA which teaches integrating transaction account application processes into merchant online shopping cart pages (JIAM ¶[0003]) and opening a financial account using an integrated system (KUMAR ¶[0008]), with the method/system of CHEN, in order to create and/or modify an application offered by a merchant device, such as a merchant application (CHEN column(s) 13, line(s) 58-67) to include an improved payment ability that can account for accrued rewards and user updates (CHEN column(s) 1, line(s) 37-41) and to provide opportunities for the merchant to upsell to customers (CHEN column(s) 1, line(s) 49-50).
Claims 11 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over JIAM, M. et al. to US 20170024716 A1 (“JIAM”) in view of 20180060965 A1 to KUMAR,; S. (“KUMAR”) in further view of US 20160005113 A1 to Mendez, M. et al. (“MENDEZ”).
Regarding claim(s) 11,
JIAM, KUMAR, and HRUSKA teach the limitations of claim 1:
JIAM does not expressly disclose the following limitations, which MENDEZ however, teaches:
further comprising 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 (see, at least, MENDEZ: [0031]: It should be understood that switching of transactions may refer to any process by which a current or future transaction is made through one financial account instead of another financial account.; [0051]: device may be configured to prompt the user to enter additional information associated with the existing bank account through a touch-screen display, a keypad, a keyboard, a voice input, or the like. The additional information to be entered by user may include whether the user wishes to transfer all the remaining funds in the existing bank account to the new bank account, whether the user wishes to set up automatic bill payment with the new bank account, etc.; [0060]: financial service provider system may receive a user selected amount of funds from device 120, and financial service provider system may transfer the selected amount of funds from the existing bank account to the new bank account; [0026]: Third-party system may communicate with financial service provider system to allow transfer of funds from the customer account to the merchant for making one or more payments; [0051]: user indicates whether the user wishes to set up automatic bill payment with the new bank account).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify the combination of JIAM, KUMAR, and HRUSKA, which teaches integrating transaction account application processes into merchant online shopping cart pages (JIAM [0003]) and opening a financial account using an integrated system (KUMAR [0008]), with the method/system of MENDEZ, which teaches creating a new account (MENDEZ [0023]) in order to simply and quickly switch existing financial balances or accounts to a new financial account (MENDEZ [0079]) and to avoid delay when transferring funds from an existing financial account to a new account (MENDEZ [0004]).
Regarding claim(s) 12,
JIAM, KUMAR, and HRUSKA teach the limitations of claim 1:
JIAM does not expressly disclose the following limitations, which MENDEZ however, teaches:
wherein the new account accepts automated payments via the third-party (see, at least, MENDEZ: [0026]: the payments may be recurring payments to the merchant associated with third-party system 130 for goods and/or services received by the customer [...]. Third-party system 130 may communicate with financial service provider system 110 to allow transfer of funds from the customer account to the merchant for making one or more payments.; [0032]: account switch system 102 may communicate with a third-party system 130 associated with a merchant to switch automatic recurring payments made by the customer to the merchant from one financial account (e.g., an old financial account) to another financial account (e.g., a new financial account) ).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify the combination of JIAM, and KUMAR, which teaches integrating transaction account application processes into merchant online shopping cart pages (JIAM [0003]) and opening a financial account using an integrated system (KUMAR [0008]), with the method/system of MENDEZ, which teaches creating a new account (MENDEZ [0023]) in order to simply and quickly switch existing financial balances or accounts to a new financial account (MENDEZ [0079]) and to avoid delay when transferring funds from an existing financial account to a new account (MENDEZ [0004]).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over JIAM, M. et al. to US 20170024716 A1 (“JIAM”) in view of 20180060965 A1 to KUMAR,; S. (“KUMAR”) in further view of US 20130282588 A1 to HRUSKA, J. (“HRUSKA”) and in further view of US 10467689 B2 to CHEN, H., (“CHEN”)..
Regarding claim(s) 17,
JIAM, KUMAR, and HRUSKA teach the limitations of claim 16.
JIAM does not expressly disclose the following limitations, which CHEN however, teaches:
wherein the institution computing system provides the account open functionality through the first application via a software development kit (SDK) of the provider institution (see, at least, CHEN column(s) 13, line(s) 52-67 to column(s) 14, line(s) 1-10: “[...] [M]obile 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. [...] In various embodiments, 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. [...]”).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify the combination of JIAM, KUMAR, and HRUSKA which teaches integrating transaction account application processes into merchant online shopping cart pages (JIAM ¶[0003]) and opening a financial account using an integrated system (KUMAR ¶[0008]), with the method/system of CHEN, in order to create and/or modify an application offered by a merchant device, such as a merchant application (CHEN column(s) 13, line(s) 58-67) to include an improved payment ability that can account for accrued rewards and user updates (CHEN column(s) 1, line(s) 37-41) and to provide opportunities for the merchant to upsell to customers (CHEN column(s) 1, line(s) 49-50).
Response to Arguments
Double Patenting
Applicant's arguments filed 25 August 2025 have been fully considered but they are not persuasive. The double patenting rejection applies to the current claims for the reasons given above.
35 U.S.C. § 101
With regard to claims 1, 2, 4-10, and 13-15, at page 11 Applicant argues that the present claims use of encoded data and validation according to specifically generated codes to generate information that may be used in an account open request relate to a technical solution for enabling secure account creation and data transfer between different computing systems. Encoding and validating data are abstract ideas that could be performed in the human mind or generic computer. Thus, this argument is not persuasive.
At page 12, 2nd – 3rd paragraphs, applicant points to features in the specification that are not claimed (expiration time of code). Furthermore, the generation of a unique code is an abstract idea that can be performed mentally or with pen and paper and is not a technical improvement.
35 U.S.C. § 103
Applicant's arguments filed 8/25/2025 have been fully considered but they are not persuasive. Applicant argues that merely using a CA certificate and generating a dynamic banner is not the same as establishing a new account at least in part by parsing the code, validating a set of data, and generating a set of account data using the data. This argument has been considered but is unpersuasive. These limitations include newly added limitations and are rejected using a combination of references in addition to JIAM as shown above.
The arguments concerning the 103 rejection of claims 3, 11, 12, 16, 18, 19 and 17and 20 at pages 15-17 are predicated upon the same arguments concerning claims 1, 2, 4-10, and 13-15 addressed above and are unpersuasive for the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
1) US 20190096005 A1 to Drury, R. K. teaches a method for facilitating access control and system integration between computer systems and enables a mutual customer to establish a connection between an accounting software system and the financial institution by allowing a financial institution customer to opt to make feeds from the bank accounts available to the accounting software system within financial internet software.
2) US 20190281051 A1 to Burmester; S. teaches a method that involves identifying a request to access a protected resource, where the request is received from a client device. A confidence level associated with the protected resource is identified based on a resource hierarchy which associates multiple protected resources with respective confidence levels for authentication.
3) US 20180276053 A1 to Kesavan, R. teaches an architecture that dynamically integrates a client application with one or more network-accessible third-party services. A client application can send a request to perform an action to the integration service using an API that is generic to the third-party services and the integration service then communicates with a particular third-party service to perform the requested action using an API specific to the particular third-party service.
4) US 7610233 B1 to Leong; C. W. teaches a Secure Electronic Transaction protocol that requires certificates for authenticating consumers wherein consumers get their encryption keys using a specific program integrated into their browser. This certificate contains a key and will be attached permanently to the browser of the consumer. Then, for every transaction the consumer asks the merchant to send his certificate, and the merchant can ask the consumer's bank for authentication with the customer's certificate. Certificates are to be issued for each credit card a consumer wishes to use on the Internet.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BOLKO HAMERSKI whose telephone number is (571)270-7621. The examiner can normally be reached Monday-Friday 10:00 AM to 6:00 PM.
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, BENNETT SIGMOND can be reached at (303) 297-4411. 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.
BOLKO HAMERSKI
Examiner
Art Unit 3694
/BOLKO M HAMERSKI/ Examiner, Art Unit 3694
/BENNETT M SIGMOND/ Supervisory Patent Examiner, Art Unit 3694