DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This is a first office action on the merits, in response to the claims filed on April 25, 2025.
Claims 1-20 are pending.
Claims 1-20 have been examined.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-18 of Bloy et al. US 12315007 B2 (hereinafter, “Patent Document”). Although the claims at issue are not identical, they are not patentably distinct from each other.
This Application
Patent Document
Claim 1: A computing system comprising: a processor; and memory coupled to the processor, the memory storing computer-executable instructions that, when executed by the processor, configure the processor to:
receive, via a merchant application, a request to process a credit application associated with a first user account in connection with a transaction that is initiated at a merchant system;
provide for display, via a user interface of the merchant application, a dynamically-generated interactive form associated with the credit application;
[…]
[…]
pre-populate a selected set of input fields in the interactive form using personally identifiable information associated with the first user account that is obtained from a merchant database;
[…]
transmit, from the merchant application to a device having an application programming interface (API) exposed by a backend system for accessing the credit application process, a first signal comprising a merchant-specific identifier of the first user account and completed form data of the interactive form;
receive, by the merchant application, a second signal comprising an approval associated with the credit application, a payment credential associated with a new credit account created in response to the approval, and the merchant-specific identifier of the first user account, the payment credential being associated with a user profile corresponding to the merchant-specific identifier;
provision the payment credential to a proprietary wallet associated with the first user account at the merchant system; and
process the current transaction using the payment credential.
Claim 1: A system comprising: at least one memory storing instructions; at least one hardware processor interoperably coupled with the at least one memory, wherein the instructions, when executed by the at least one hardware processor, causes the system to perform operations comprising:
receiving, at a merchant application, a request to perform a credit application process associated with a particular user account during a current transaction being conducted at the merchant application,
wherein the credit application process is associated with and performed by a particular institution;
providing for display, via a user interface and within the merchant application, a dynamically-generated interactive form and current disclosure information associated with a credit application for the particular institution, wherein providing the dynamically-generated interactive form for display, comprises:
performing, using an application programming interface (API) exposed by a financial institution and for the credit application, a selection of the current disclosure information and current application requirements for the credit application, wherein the selection is based on a plurality of application requirements conforming with respective regional requirements and a plurality of disclosure forms received from a particular institution system over a particular time period; and
determining, at runtime and based on the current application requirements, a current set of user input fields for inclusion on at least partially pre-populating the dynamically-generated interactive form;
pre-populating the current set of the user input fields of the dynamically-generated interactive form using additional information associated with the user account, obtained, from a merchant database; and
performing, based on the current application requirements, a dynamic formatting of the current set of user input fields for display on the dynamically-generated interactive form for format compatibility with the API associated with the particular institution;
transmitting, from the merchant application, to a device having the API associated with the particular institution, and based at least in part on information entered into the dynamically-generated interactive form, a first signal comprising data for performing the credit application process, comprising a merchant-specific identifier of the particular user account;
receiving, by the merchant application, a second signal comprising an approval associated with the credit application process, a payment credential associated with a new credit account created in response to the approval of the credit application process, and the merchant-specific identifier, the merchant-specific identifier linking the payment credential to the particular user account;
storing, by the merchant application and using the merchant-specific identifier, the payment credential in a proprietary wallet associated with a merchant and a user profile associated with the particular user account corresponding to the merchant-specific identifier; and
processing the current transaction using the payment credential.
The nonstatutory double patenting rejection in this case should explain the fact that the species or sub-genus claimed in the conflicting patent or application anticipates the claimed genus in the application being examined and, therefore, a patent to the genus would improperly extend the right to exclude granted by a patent to the species or sub-genus should the genus issue as a patent after the species or sub-genus.
Regarding dependent claims:
Claim 2: The computing system of claim 1, wherein the personally identifiable information associated with the first user account is obtained based on accessing the user profile of the first user account at the merchant database.
Claim 2: The system of claim 1, the instructions, when executed by the at least one hardware processor, causes the system to perform operations comprising: accessing a user profile of the particular user account to obtain a set of personally identifiable information associated with the particular user account; and updating at least a portion of the dynamically-generated interactive form with a portion of the set of personally identifiable information.
Claim 3: The computing system of claim 2, wherein the instructions, when executed, configure the processor to: receive, via the user interface, user input comprising additional information for use in completing the interactive form, wherein the completed form data of the interactive form includes the pre-populated data and the user-inputted additional information.
Claim 3: The system of claim 2, the instructions, when executed by the at least one hardware processor, causes the system to perform operations comprising: receiving, via the user interface, additional user input providing additional information to the dynamically-generated interactive form associated with the credit application.
Claim 4: The computing system of claim 1, wherein the payment credential comprises at least one of: a personal account number; an expiration date of a payment card; or a payment token associated with the new credit account.
Claim 5: The system of claim 1, wherein the payment credential comprises at least one of (i) a personal account number, (ii) an expiration date of a payment card, or (iii) a payment token, associated with the new credit account.
Claim 7: The computing system of claim 1, wherein receiving the second signal comprises receiving the second signal via at least one API associated with the merchant application.
Claim 6: The system of claim 1, wherein receiving the second signal comprises receiving the second signal via at least one API associated with the merchant application.
Claim 8: The computing system of claim 1, wherein the instructions, when executed, configure the processor to:
dynamically determine disclosure information for the credit application; and provide for display, by the merchant application, the disclosure information.
Claim 7: The system of claim 1, the instructions, when executed by the at least one hardware processor, causes the system to perform operations comprising:
dynamically determining, by the API of the financial institution and for the credit application, disclosure information for the credit application; and providing for display, by the merchant application, the disclosure information
Claim 10: The computing system of claim 9, wherein the instructions, when executed, further configure the processor to perform, based on current application requirements for the credit application, a dynamic formatting of the data fields for display on the interactive form for format compatibility with the API exposed by the backend system.
Claim 1:
performing, based on the current application requirements, a dynamic formatting of the current set of user input fields for display on the dynamically-generated interactive form for format compatibility with the API associated with the particular institution;
Regarding claim 5: Although claim 5 of this application and claim 1 of the Patent Document are not identical, the claimed subject matter of this application is not patentably distinct from the Patent Document.
Regarding claim 6: Although claim 6 of this application and claim 1 of the Patent Document are not identical, the claimed subject matter of this application is not patentably distinct from the Patent Document.
Regarding claim 9: Although claim 9 of this application and claim 1 of the Patent Document are not identical, the claimed subject matter of this application is not patentably distinct from the Patent Document.
Claims 11-20 recite subject matter similar to that discussed above in connection with claims 1-10. Accordingly, claims 11-20 are rejected under a similar rationale as claims 1-10.
Therefore, it would have been obvious to a person of ordinary skill in the art to modify claims 1-18 of the Patent Document by removing the additional limitations, resulting generally in the claims of this application, since the claims of this application and the claim recited in the Patent Document actually perform a similar function. It is well settled that the omission of an element and its function is an obvious expedient if the remaining elements perform the same function as before. In re Karison, 136 USPQ 184 (CCPA 1963). Also note Ex parte Rainu, 168 USPQ 375 (Bd. App. 1969). Thus, omission of a reference element whose function is not needed would be obvious to one of ordinary skill in the art.
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 of requesting a payment method, receiving the payment method, provisioning the payment method and processing a transaction using the payment method without significantly more.
Examiner has identified claim 1 as the claim that represents the claimed invention presented in independent claims 1, 11 and 20.
In the instant case, claims 1-10 are directed to a system comprising a processor and memory, claims 11-19 are directed to a non-transitory computer-readable storage medium, and claim 20 is directed to a method. Therefore, these claims fall within the four statutory categories of invention. (Step 1: YES).
Claim 1 is directed to a computing system comprising: a processor; and memory coupled to the processor, the processor configured to, which performs a series of steps: “receive, via a merchant application, a request to process a credit application associated with a first user account in connection with a transaction that is initiated at a merchant system; provide for display, via a user interface of the merchant application, a dynamically-generated interactive form associated with the credit application; pre-populate a selected set of input fields in the interactive form using personally identifiable information associated with the first user account that is obtained from a merchant database; transmit, from the merchant application to a device having an application programming interface (API) exposed by a backend system for accessing the credit application process, a first signal comprising a merchant-specific identifier of the first user account and completed form data of the interactive form; receive, by the merchant application, a second signal comprising an approval associated with the credit application, a payment credential associated with a new credit account created in response to the approval, and the merchant-specific identifier of the first user account, the payment credential being associated with a user profile corresponding to the merchant-specific identifier; provision the payment credential to a proprietary wallet associated with the first user account at the merchant system; and process the current transaction using the payment credential.” These series of steps describe the abstract idea of requesting a payment method, receiving the payment method, provisioning the payment method and processing a transaction using the payment method (with the exception of the italicized terms above), which correspond to Certain Methods of Organizing Human Activity: fundamental economic principles. The system limitations, e.g., processor, memory, merchant system, user interface, device, and backend system do not necessarily restrict the claim from reciting an abstract idea. Thus, claim 1 recites an abstract idea. (Step 2A-Prong 1: YES).
This judicial exception is not integrated into a practical application because the additional elements of claim 1 such as a processor, memory, merchant system, user interface, device, and backend system are no more than simply applying the abstract idea using generic computer elements. Specifically, the processor, memory, merchant system, user interface, device, and backend system performs the steps or functions of: “receive, via a merchant application, a request to process a credit application associated with a first user account in connection with a transaction that is initiated at a merchant system; provide for display, via a user interface of the merchant application, a dynamically-generated interactive form associated with the credit application; pre-populate a selected set of input fields in the interactive form using personally identifiable information associated with the first user account that is obtained from a merchant database; transmit, from the merchant application to a device having an application programming interface (API) exposed by a backend system for accessing the credit application process, a first signal comprising a merchant-specific identifier of the first user account and completed form data of the interactive form; receive, by the merchant application, a second signal comprising an approval associated with the credit application, a payment credential associated with a new credit account created in response to the approval, and the merchant-specific identifier of the first user account, the payment credential being associated with a user profile corresponding to the merchant-specific identifier; provision the payment credential to a proprietary wallet associated with the first user account at the merchant system; and process the current transaction using the payment credential.” The additional elements listed above are all recited at a high level of generality and under their broadest reasonable interpretation comprises a generic computing arrangement. The presence of a generic computer arrangement is nothing more than to implement the claimed invention (MPEP 2106.05(f)). Therefore, the recitations of additional elements do not meaningfully apply the abstract idea and hence do not integrate the abstract idea into a practical application. Thus, claim 1 does not integrate the abstract idea into a practical application. (Step 2A-Prong 2: NO).
Claim 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements of a processor, memory, merchant system, user interface, device, and backend system limitations are recited at a high level of generality in that it results in no more than simply applying the abstract idea using generic computer elements. The additional elements when considered separately and as an ordered combination do not amount to add significantly more as these limitations provide nothing more than to simply apply the exception in a generic computer environment. Thus, claim 1 is not patent eligible. (Step 2B: NO).
Similar arguments can be extended to the independent claim 20 and hence, claim 20 is rejected on similar grounds as claim 1.
Claim 11 recites the abstract idea subject matter similar to that discussed above in connection with claim 1. The newly identified additional element of non-transitory, computer-readable medium storing computer-readable instructions also fails to recite a practical application or significantly more than the abstract idea as it is no more than simply applying the abstract idea using generic computer elements. Thus, claim 11 is rejected on similar grounds as claim 1.
Regarding dependent claims 2-10 and 12-19:
Claims 2 and 12 recite: wherein the personally identifiable information associated with the first user account is obtained based on accessing the user profile of the first user account at the merchant database.
Claims 3 and 13 recite: receive, via the user interface, user input comprising additional information for use in completing the interactive form, wherein the completed form data of the interactive form includes the pre-populated data and the user-inputted additional information
Claims 4 and 14 recite: wherein the payment credential comprises at least one of: a personal account number; an expiration date of a payment card; or a payment token associated with the new credit account.
Claims 5 and 15 recite: wherein the request to process the credit application is received in association with a data exchange to be performed at the merchant application, and wherein the instructions, when executed, further configure the processor to automatically perform the data exchange using the payment credential after associating the payment credential with the user profile
Claims 6 recites: wherein the data exchange comprises a transaction associated with the merchant application.
Claims 7 and 16 recite: wherein receiving the second signal comprises receiving the second signal via at least one API associated with the merchant application.
Claims 8 and 17 recite: dynamically determine disclosure information for the credit application; and provide for display, by the merchant application, the disclosure information.
Claims 9 and 18 recite: wherein providing the interactive form associated with the credit application for display comprises: requesting, via the API exposed by the backend system, a set of data fields required for inclusion in the credit application; receiving an indication of the set of required data fields for the credit application; and dynamically generating the interactive form associated with the credit application, wherein the dynamically generated interactive form includes the set of required data fields.
Claims 10 and 19 recite: perform, based on current application requirements for the credit application, a dynamic formatting of the data fields for display on the interactive form for format compatibility with the API exposed by the backend system.
The dependent claims 2-10 and 12-19 have further defined the abstract idea that is present in their respective independent claims: Claims 1, 11 and 20; and thus, correspond to Certain Methods of Organizing Human Activity: a commercial interaction and hence are abstract in nature for the reason presented above.
The dependent claims 2-10 and 12-19 do not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Therefore, 2-10 and 12-19 are directed to an abstract idea without significantly more.
Thus, claims 1-20 are not patent-eligible.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Purves et al. (US 20180189756 A1, “Purves”), in view of Daniel Simon (US 10417706 B1, “Simon”), and alternatively, further in view of Praveen K. Andapally (US 20110082809 A1, “Andapally”).
Regarding claims 1, 11 and 20: Purves discloses: A computing system comprising:
a processor (see paragraphs [ [0263] and [0267]-[0268] and Fig. 2); and
memory coupled to the processor, the memory storing computer-executable instructions that, when executed by the processor, configure the processor to (see paragraphs [ [0263] and [0267]-[0268] and Fig. 2):
receive, via a merchant application, a request to [get payment methods] associated with a first user account in connection with a transaction that is initiated at a merchant system (Purves [0073]: Referring to FIG. 7a, in one implementation, a customer may launch a merchant site 705; [0069]: The merchant server may execute an API call to get payment methods from the W-CONNECTOR server; [0101]: FIG. 14 shows an exemplary screenshot depicting a merchant checkout system. In one embodiment, the W-CONNECTOR may facilitate the administration of payments to merchants that contain a current transaction 1401), (see paragraphs [0073], [0068]-[0070] and [0101]);
provide for display, via a user interface of the merchant application, a dynamically-generated interactive form associated with the [get payment methods] (Purves [0074]: The wallet widget may then direct the customer to the merchant site 725. The wallet may also share or load or dynamically inject to the merchant site information according to the customer preferences. The merchant site 725 may obtain the shared information and display the shared payment methods, address, and other information 725a to the customer to confirm the connection between the merchant account and the wallet; [0075]: When the login with wallet button is selected, a wallet widget 815 may be launched within the merchant site 805), (see paragraphs [0073]-[0075] and [0102] and Figs. 7B and 14A);
pre-populate a selected set of input fields in the interactive form using personally identifiable information associated with the first user account that is obtained, from a [customer profile database] (Purves [0116]: FIG. 21 is an example data and logic flow illustrating the enrollment of a consumer account in a virtual wallet service and the utilization of a pre-fill service to pre-populate information necessary for wallet enrollment…In some embodiments, the request for retrieval of pre-provisioned data 2106 (e.g., “prefill data”) may be in the form of an HTTP(S) message including XML-formatted data containing fields; [0065]: In some implementations, the merchant may use this unique identifier to make calls to the wallet to retrieve and/or update commerce-relevant or other customer data), (see paragraphs [0116]-[0118], [0065], [0083] and [0073]-[0075] and Figs. 7A-7B);
transmit, from the merchant application to a device having an application programming interface (API) exposed by a backend system for accessing (e.g., get) the [payment methods], a first signal comprising a merchant-specific identifier of the first user account and completed form data of the interactive form (Purves [0087]: In one implementation, the merchant may send the new user information message 956 to the wallet server. An example new user information message 956, substantially in the form of a HTTP(S) POST message including XML-formatted data; [0081]: The user information request message 926 may include, without limitation, the customer ID that is unique to the customer and the merchant relationship, a token, an API key, a digital certificate, and/or the like. In one implementation, the token may be generated using one or more parameters such as the merchant's API key, customer ID, merchant ID, merchant name, customer name, and/or the like. In a further implementation the token may be encrypted), (see paragraphs [0075], [0087], [0081] and [0084] and Fig. 9a and 9b, see also paragraphs [0065], [0068] and [0070]);
receive, by the merchant application, a second signal comprising an [response message 934] associated with the [get payment methods/accounts], a payment credential (e.g., financial accounts, debit cards, credit cards) associated with a new credit account (e.g., new card) created in response to the [response message 934], and the merchant-specific identifier of the first user account, the payment credential being associated with a user profile corresponding to the merchant-specific identifier (Purves [0083]: In one implementation, the wallet server may use the associated preferences and permissions specified by the user to determine payment methods that the user has approved for sharing with the merchant. The wallet server may then generate the user information response message 934 for transmission to the merchant. An example response message 934 substantially in the form of a HTTP(S) POST message including XML-formatted data; [0094]: The payment methods may also include bank or other financial accounts, debit cards, credit cards, prepaid cards, gift cards, and/or the like. In some implementations, the customer may also add new card to the wallet directly from the control panel interface. The customer may select one or more of these payment methods for sharing with the merchant 1205c); [0069]: embodiments of the W-CONNECTOR, API and inline widget methods, among others, may be implemented. Using the API method, the merchant server may make API calls to the V-Connect server to retrieve customer data…The merchant server may execute an API call to get payment methods from the W-CONNECTOR server. The merchant may then display the currently active payment method is a wallet (e.g., Wallet wallet) with account nickname and ending in digits. For example, referring to FIG. 5, the merchant may obtain payment methods 530a and 530b from W-CONNECTOR and display them using their nicknames such as “My Business Credit Card PaymentCard Ending . . . 1234” (e.g., 530a) and “My Personal Debit Card PaymentCard Ending . . . 1234” (e.g., 530b). In this way, via API calls, the merchant may display rich, up to date account information including card art), (see paragraphs [0083]-[0084], [0079] and [0069]);
provision the payment credential to a proprietary wallet associated with the first user account at the merchant system (Purves [0067]: in a merchant site 505, under the customer account 510, information relating to order status 515, account profile 520, address book 525, payment methods 530, and/or the like may be displayed. The merchant may have their own set of customer information (e.g., order information or size information) that they maintain in their customer database. However, other information such as primary shipping address and payment methods may be dynamically linked and synced to W-CONNECTOR such that the merchant has access to the customer's preferred shipping address and payment methods. For example, address book 525 may display the default shipping address and the payment methods 530 may display a list of payment methods that are stored with the merchant for faster checkout. Using callbacks, the W-CONNECTOR may obtain not only payment methods and addresses, but also loyalty accounts, payment authorizations, entitlements, payment preferences, and/or the like; [0068]: In one implementation, each callback may include the customer ID that is unique to the customer-merchant relationship. In a further implementation, API calls to the W-CONNECTOR may include one or more API keys such as a public key and/or a shared secret key. An API key may be a string value that identifies the general API access configuration and settings for the site. In some embodiments, callbacks for W-CONNECTOR may include, without limitation, the following), (see paragraphs [0067]-[0068], [0074], [0070] and [0136] and Fig. 16); and
process the current transaction using the payment credential (Purves [0075]: In one implementation, the payment method 825c obtained from the wallet may be a payment method nickname (e.g., my personal account)…In one implementation, the customer may also edit shipping address, payment method and other details directly from the merchant site using the edit with wallet button 830. Upon successful transaction authorization, the merchant site 805 may display the page 840, including information such as receipt 840a relating to the transaction), (see paragraphs [0075], [0101], [0107]-[0109] and Fig. 8b and Fig. 18).
As indicated above, Purves discloses, receiving a request to get payment methods/payment accounts (e.g., a credit card and a debit card) previously opened with a bank/issuer for enrollment in a virtual wallet (see abstract, paragraphs [0044]-[0045] and [0052]).
Purves does not specifically disclose, receiving a request to process a credit application.
However, Simon, an analogous art of online/retail payment transaction, discloses:
receive, via a merchant application (e.g. online shopping platform 102 / online store server 108), a request (e.g., step 306, e.g. first request) to process a credit application (e.g. loan application form or pay over time, visual icons 202) associated with a first user account in connection with a transaction that is initiated at a merchant system (see Column 6, lines 32-65 and Column 12, lines 8-58 and Fig. 1 and Figs. 2A-2J);
receive, by the merchant application, a second signal comprising an approval associated with the credit application (e.g., step 312, informing the consumer that the loan is approved), a payment credential associated with a new credit account created in response to the approval, and the [consumer] identifier of the first user account, the payment credential being associated with a user profile corresponding to the [consumer] identifier (Simon, Column 3, lines 1-67: Once the consumer confirms the purchase via the embedded component integrated in the online store UI, the software program running on the loan provider server may generate and transmit a transaction token back to the online store server. The merchant may associate the transaction token with the purchase order transacted with the loan and store the token in association with the purchase order), (see Column 3, lines 1-67 – Column 4, lines 1-10; Column 11, lines 28-40 and Column 16, lines 35-49 and Fig. 3).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Purves’s multi-directional wallet connector apparatuses, methods and systems (“W-CONNECTOR”) facilitates the enrollment of payment accounts in a consumer's virtual wallet. (e.g., merchant wallet) with Simon’s integrating externally-supplied interface component into transaction platform to include a credit application process to offer new credit cards/account to a user to enhance user experience during a transaction and to extend functions (e.g., capabilities) of the Purves’s multi-directional wallet connector systems.
As indicated above, Purves discloses, dynamically-generated interactive form and pre-populate a selected set of input fields in the interactive form using personally identifiable information associated with the first user account that is obtained from a [customer profile database] (see paragraphs [0116]-[0118], [0080], [0083] and [0065]). Thus, Purves, discloses, user account data is obtained from a merchant database. However, for compact prosecution and clarity purpose, the Examiner cites Andapally to specifically disclose, user account data is obtained from a merchant database.
Alternatively, Andapally discloses:
pre-populate a selected set of input fields in the interactive form using personally identifiable information associated with the first user account that is obtained from a merchant database (e.g., institutions) (Andapally [0026]: The application management platform identifies 103 applicant information sought by the selected institutions by parsing application forms associated with the selected institutions. The application management platform dynamically generates 104 a universal application form comprising a consolidated set of input fields corresponding to the identified applicant information…The consolidated set of inputs fields comprises input fields corresponding to the applicant information sought by the selected institutions without any repetition of common input fields. Consolidation of the set of input fields in the dynamically generated universal application form for capturing the applicant information sought by the selected institutions in the online environment provides an integrated means for applying to multiple institutions, without duplicate data entry from the applicant; [0027]: The institutions may require certain applicant information in prescribed formats; [abstract]: The application management platform identifies applicant information sought by the selected institutions by parsing application forms associated with the selected institutions. The application management platform generates a universal application form comprising a consolidated set of input fields corresponding to the identified applicant information. The application management platform captures the applicant information filled into the consolidated set of input fields of the dynamically generated universal application form via the online interface), (see paragraphs [0026]-[0029] and [0055]-[0056] and Figs. 1 and 5A).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Purves’s multi-directional wallet connector apparatuses, methods and systems (“W-CONNECTOR”) facilitates the enrollment of payment accounts in a consumer's virtual wallet. (e.g., merchant wallet) and Simon’s integrating externally-supplied interface component into transaction platform with Andapally’s integrated institution application management system to include a well-known generating web pages functions, such as generating web pages/forms based on user requirements to enhance user experience and system performance.
Regarding claims 2 and 12: Purves, Simon and Andapally, discloses the limitations of claim 1 above.
Purves further discloses: The computing system of claim 1, wherein the personally identifiable information associated with the first user account is obtained based on accessing the user profile of the first user account at the [customer profile database] (Purves [0065]: In some implementations, the merchant may use this unique identifier to make calls to the wallet to retrieve and/or update commerce-relevant or other customer data. The customer has the option to maintain, in one place, address book, payment methods, and payment preferences.) (see paragraphs [0116]-[0118], [0065], [0083] and [0073]-[0075] and Figs. 7A-7B).
As indicated above, Purves discloses, the first user account [data] that is obtained from a [customer profile database] (see paragraphs [0116]-[0118] and [0080]). Thus, Purves, discloses, user account data is obtained from a merchant database. However, for compact prosecution and clarity purpose, the Examiner cites Andapally to specifically disclose, user account data is obtained from a merchant database.
Alternatively, Andapally discloses: the first user account [data] that is obtained from a merchant database (e.g., institutions), (see paragraphs [0026]-[0029] and [0055]-[0056] and Figs. 1 and 5A).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Purves’s multi-directional wallet connector apparatuses, methods and systems (“W-CONNECTOR”) facilitates the enrollment of payment accounts in a consumer's virtual wallet. (e.g., merchant wallet) and Simon’s integrating externally-supplied interface component into transaction platform with Andapally’s integrated institution application management system to include a well-known generating web pages functions, such as generating web pages/forms based on user requirements to enhance user experience and system performance.
Regarding claims 3 and 13: Purves, Simon and Andapally, discloses the limitations of claim 1 above.
PrimaryReference further discloses: The computing system of claim 2, wherein the instructions, when executed, configure the processor to:
receive, via the user interface, user input comprising additional information for use in completing the interactive form (see paragraphs [0075] and [0071]),
wherein the completed form data of the interactive form includes the pre-populated data and the user-inputted additional information (see paragraphs [0116]-[0118] and [0080]).
Regarding claims 4 and 14: Purves, Simon and Andapally, discloses the limitations of claim 1 above.
Purves further discloses: The computing system of claim 1, wherein the payment credential comprises at least one of: a personal account number; an expiration date of a payment card; or a payment token [associated with the new credit account] (Purves [0118]: <Card Details> Account Number PAN Number of the 19 Alpha Numeric Card Number Cardholder Card Expiry Date Expiration date of 4 UN The expiration date as provide on the card the Cardholder Format), (see paragraphs [0118], [0128] and [0104]).
Alternatively, Simon also discloses: wherein the payment credential comprises at least one of: a personal account number; an expiration date of a payment card; or a payment token (e.g., transaction token) associated with the new credit account (See Column 4, lines 11-22 and Column 3, lines 58-65).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Purves’s multi-directional wallet connector apparatuses, methods and systems (“W-CONNECTOR”) facilitates the enrollment of payment accounts in a consumer's virtual wallet. (e.g., merchant wallet) with Simon’s integrating externally-supplied interface component into transaction platform to include a credit application process to offer new credit cards/account to a user to enhance user experience during a transaction and to extend functions (e.g., capabilities) of the Purves’s multi-directional wallet connector systems.
Regarding claims 5 and 15: Purves, Simon and Andapally, discloses the limitations of claim 1 above.
Purves doesn’t specially disclose; however, Simon discloses: The computing system of claim 1, wherein the request to process the credit application is received in association with a data exchange to be performed at the merchant application, and wherein the instructions, when executed, further configure the processor to automatically perform the data exchange using the payment credential after associating the payment credential with the user profile (Simon [Column 6, lines 22-32]: In one implementation, in addition to providing the content for the consumer to complete a purchase, the online shopping platform 102 may also allow a loan service provider to provide a loan option integrated in the online store UI. The loan option may allow the consumer to pay for a purchase through a series of installment payments. In one implementation, the loan service provider may be an external entity that is separate from the online store and provides the loan option by integrating an embedded software component in one or more of the content pages supplied by online store server 108), (See Column 6, lines 22-32; and Column 16, lines 19-52; and Fig. 1 and Fig. 3).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Purves’s multi-directional wallet connector apparatuses, methods and systems (“W-CONNECTOR”) facilitates the enrollment of payment accounts in a consumer's virtual wallet. (e.g., merchant wallet) with Simon’s integrating externally-supplied interface component into transaction platform to include a credit application process to offer new credit cards/account to a user to enhance user experience during a transaction and to extend functions (e.g., capabilities) of the Purves’s multi-directional wallet connector systems.
Regarding claim 6: Purves, Simon and Andapally, discloses the limitations of claim 1 above.
Purves further discloses: The computing system of claim 5, wherein the data exchange comprises a transaction associated with the merchant application (Purves [0075]: FIGS. 8a-b show user interfaces illustrating example sign-in and checkout in some embodiments of the W-CONNECTOR. Referring to FIG. 8a, in one implementation, a customer may launch a merchant site 805 (or merchant application) …In one implementation, the customer may also edit shipping address, payment method and other details directly from the merchant site using the edit with wallet button 830. Upon successful transaction authorization, the merchant site 805 may display the page 840, including information such as receipt 840a relating to the transaction), (see paragraphs [0075], [0101], [0107]-[0109] and Fig. 8b and Fig. 18).
Regarding claims 7 and 16: Purves, Simon and Andapally, discloses the limitations of claim 1 above.
Purves further discloses: The computing system of claim 1, wherein receiving the second signal comprises receiving the second signal via at least one API associated with the merchant application (Purves [0068]: In one implementation, each callback may include the customer ID that is unique to the customer-merchant relationship. In a further implementation, API calls to the W-CONNECTOR may include one or more API keys such as a public key and/or a shared secret key. An API key may be a string value that identifies the general API access configuration and settings for the site), (see paragraphs [0068]-[0069] and [0075]).
Alternatively, Simon also discloses: wherein receiving the second signal comprises receiving the second signal via at least one API associated with the merchant application (OSS Application Interface 120), (see Column 6, lines 3-7 and lines 33-55 and Fig. 3).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Purves’s multi-directional wallet connector apparatuses, methods and systems (“W-CONNECTOR”) facilitates the enrollment of payment accounts in a consumer's virtual wallet. (e.g., merchant wallet) with Simon’s integrating externally-supplied interface component into transaction platform to include a credit application process to offer new credit cards/account to a user to enhance user experience during a transaction and to extend functions (e.g., capabilities) of the Purves’s multi-directional wallet connector systems.
Regarding claims 8 and 17: Purves, Simon and Andapally, discloses the limitations of claim 1 above.
Purves doesn’t explicitly disclose, however, Simon discloses: The computing system of claim 1, wherein the instructions, when executed, configure the processor to:
dynamically determine disclosure information for the credit application (Simon [Column 14, lines 45-55]: In response to the consumer clicking on the “Review my Order” button on the form 214, the loan provider server may provide the final terms in the iframe. FIG. 2G shows a term sheet 216 according to an implementation of the present disclosure. As shown in FIG. 2G, the loan provider server may provide the term sheet as an overlay in the online store UI. The term sheet 216 may provide an updated payment plan taking into consideration the shipping cost and sales tax. If the consumer accepts the updated term sheet by clicking the “Accept and Checkout” button, the sales transaction is confirmed), (see Column 14, lines 45-55 and Fig. 2G); and
provide for display, by the merchant application, the disclosure information (see Column 14, lines 45-55 and Fig. 2G).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Purves’s multi-directional wallet connector apparatuses, methods and systems (“W-CONNECTOR”) facilitates the enrollment of payment accounts in a consumer's virtual wallet. (e.g., merchant wallet) with Simon’s integrating externally-supplied interface component into transaction platform to include a credit application process to offer new credit cards/account to a user to enhance user experience during a transaction and to extend functions (e.g., capabilities) of the Purves’s multi-directional wallet connector systems.
Regarding claims 9 and 18: Purves, Simon and Andapally, discloses the limitations of claim 1 above.
Purves doesn’t specially disclose; however, Simon discloses: The computing system of claim 1, wherein providing the interactive form associated with the credit application for display comprises:
requesting, via the API exposed by the backend system, a set of data fields required for inclusion in the credit application (See Column 12, lines 58-67 and Fig. 2C);
receiving an indication of the set of required data fields for the credit application (See Column 13, lines 1-14 and Fig. 2C); and
dynamically generating the interactive form associated with the credit application, wherein the dynamically generated (e.g. a six-digit passcode) interactive form includes the set of required data fields (See Column 15, lines 15-25 and Fig. 2D).
69. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Purves’s multi-directional wallet connector apparatuses, methods and systems (“W-CONNECTOR”) facilitates the enrollment of payment accounts in a consumer's virtual wallet. (e.g., merchant wallet) with Simon’s integrating externally-supplied interface component into transaction platform to include a credit application process to offer new credit cards/account to a user to enhance user experience during a transaction and to extend functions (e.g., capabilities) of the Purves’s multi-directional wallet connector systems.
Regarding claims 10 and 19: Purves, Simon and Andapally, discloses the limitations of claim 1 above.
Purves further discloses: The computing system of claim 9, wherein the instructions, when executed, further configure the processor to perform, based on current application requirements for the [merchant site information according to the customer preferences], a dynamic formatting of the data fields for display on the interactive form for format compatibility with the API exposed by the backend system (Purves [0074]: The wallet widget may then direct the customer to the merchant site 725. The wallet may also share or load or dynamically inject to the merchant site information according to the customer preferences. The merchant site 725 may obtain the shared information and display the shared payment methods, address, and other information 725a to the customer to confirm the connection between the merchant account and the wallet), (see paragraphs [0073]-[0075] and [0102] and Figs. 7B and 14A).
Alternatively, Andapally also discloses: perform, based on current application requirements for the credit application, a dynamic formatting of the data fields for display on the interactive form for format compatibility with the API exposed by the backend system (Andapally [0027]: The institutions may require certain applicant information in prescribed formats. For example, the name of the applicant is required to be filled out in a certain format, for example, last name-first name-middle name. In an embodiment, the institutions prescribe a format for filling the applicant information. The application management platform generates inputs fields with prompts to fill the applicant information in the prescribed format; [0029]: For example, one of the institutions subsequently selected by the applicant may require scholarship details of the applicant. In this example, the application management platform appends additional input fields corresponding to the scholarship details of the applicant to the consolidated set of input fields in the dynamically generated universal application form).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Purves’s multi-directional wallet connector apparatuses, methods and systems (“W-CONNECTOR”) facilitates the enrollment of payment accounts in a consumer's virtual wallet. (e.g., merchant wallet) and Simon’s integrating externally-supplied interface component into transaction platform with Andapally’s integrated institution application management system to include a well-known generating web pages functions, such as generating web pages/forms based on user requirements to enhance user experience and system performance.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAHED ALI whose telephone number is (571)270-1085. The examiner can normally be reached 8:00 - 5:00 M-F.
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, Neha Patel can be reached on (571) 270-1492. 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.
/JAHED ALI/
Examiner, Art Unit 3699
/NEHA PATEL/Supervisory Patent Examiner, Art Unit 3699