DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Claims
The following is a Final Office Action rejection prepared in response to applicant’s amendment filed on 01/29/2026.
Claims 1-2, 9 and 16 are amended.
Claims 4-5, 11-12 and 18-19 are cancelled.
Claims 1-3, 6-10, 13-17 and 20 are pending and have been considered below.
Claim Interpretation
Intended use/result language:
Regarding claims 1, 8 and 15, the claim limitations below consist of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
“to…” in “…first icon to initiate the request…”
“to…” in “…a second gesture that selects the second icon to authenticate the request;”
“to…” in “… a second icon to authenticate…”
“causing…” in “causing display of a plurality of payment methods”
Regarding claims 6, 13 and 20, the claim limitation “causing…” in “causing display of a presentation of the confirmation at the client device” consists of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Regarding claims 7 and 14, the claim limitation “causing…” in “causing display of a presentation of the plurality of payment methods associated with the user profile at the client device” consists of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Nonfunctional language:
Regarding claims 1, 8 and 15, the claim limitation “…associated with a merchant”, “…associated with the application…”, “…comprises a first gesture”, “…associated with the client device”, “…associated with the user profile” and “…comprising a second gesture” are non-functional material that does not move to distinguish over prior art as it does not affect the recited steps in the claim.
Regarding claim 3, 10 and 17, the claimed limitation “… includes a third-party database” is non-functional material that does not move to distinguish over prior art as it does not affect the recited steps in the claim.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 1 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventors, at the time the application was filed, had possession of the claimed invention.
Claim 1 is rejected for reciting “simultaneously display of a first icon… and a second icon…” which introduces new matter not originally disclosed in the specification. The originally filed specifications and drawings do not contain any description, suggestion or mention of a simultaneous display of a first icon and a second icon. The specification consistently recites the display of a first icon to initiate a payment request that upon selection triggers the display of a second icon to authenticate the transaction. Therefore, because the original specifications fail to reasonably convey to a person of ordinary skills in the art that the applicant had possession of the concept of a sensor integrated with the user device to obtain user credentials, the limitation constitutes new matter under 35 U.S.C. 112(a). The applicant is advised to delete or amend the unsupported limitation.
Claims 2-3 and 6-7 are also rejected as they depend from claim 1.
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-3, 6-10, 13-17 and 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1-3 and 6-7 are directed to a method (i.e., process). Claims 8-10 and 13-14 are directed to a system (i.e., machine, and manufacture). Claims 15-17 and 20 are directed to a machine-readable storage medium (i.e., manufacture). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One: Claim 1, recites (i.e., sets forth or describes) an abstract idea. More specifically, the following bolded claim elements recite abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
A method comprising: executing an application at a client device, the application associated with a merchant;
presenting a graphical user interface (GUI) associated with the application at the client device, the GUI including a simultaneous display of a first icon to initiate a request for a payment to the merchant associated with the application and a second icon to authenticate the request for the payment to the merchant associated with the application;
receiving a first input that comprises a first gesture that selects the first icon to initiate the request ;
accessing a user profile associated with the client device from within a database in response to the first gesture; the user profile comprising a plurality of payment methods and corresponding payment credentials stored in association with each individual of the plurality of payment methods;
causing display of a presentation of the plurality of payment methods;
receiving a selection of a payment method from among the plurality of payment methods associated with the user profile;
receiving a second input comprising a second gesture that selects the second icon to authenticate the request; and
accessing a payment credential associated with the selected payment method from among the corresponding payment credentials from within the database responsive to the second gesture, the payment credential corresponding to the selected payment method.
authorizing the payment to the merchant based on the payment credential; and
passing a payment token to the merchant responsive to the authorizing the payment to the merchant within the application, the payment token comprising a validation.
Claim 1, recites (i.e., sets forth or describes) an abstract idea of a method to authenticate the identity and profile data of individuals to process payments. The claim achieves this by receiving an input to initiate a request, accessing a user profile in response to the input, presenting payment methods associated with the user profile, receiving a selection of one of the payment methods, receiving a second input to authenticate the request, accessing credentials associated with the selected payment method, authorizing the payment method based on the credentials, passing an authorization token to a merchant. Claims 8 and15 are significantly similar to claim 1. As such claim 8 and 15 also recite an abstract idea. The claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas (i.e. fundamental economic practices).
Step 2A Prong Two: Because the claim recites abstract ideas, the analysis proceeds to
determine whether the claim recites additional elements that recite a practical application of the
abstract ideas. Here, the additional elements of an application, a client device, a graphical user interface (GUI), a first icon, a second icon, a memory, a database, at least one hardware processor in claim 8 and the one or more processors of a machine in claim 15 merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Therefore, the claim as a whole fail to recite a practical application of the abstract ideas.
Step 2B: Determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims: Claims 2-3, 6-7, 9-10, 13-14, 16-17 and 20 have also been analyzed for subject matter eligibility. However, claims 2-3, 6-7, 9-10, 13-14, 16-17 and 20 also fail to recite patent eligible subject matter for the following reasons:
Claims 2, 9 and 16 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the accessing the user profile associated with the client device in response to the input that selects the icon further comprises: accessing the database that includes the user profile data responsive to the input that selects the icon from the client device.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity”. The non-bolded additional elements of a client device and an icon fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 3, 10 and 17 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the database includes a third-party database.
The non-bolded additional element of a database fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 6, 13 and 20 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
receiving, at the client device, a confirmation of the payment based on the validation; and causing display of a presentation of the confirmation at the client device.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity”. The non-bolded additional element of a client device fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 7 and 14 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the user profile data associated with the user profile includes a plurality of payment methods associated with the user profile, and the generating the payment credential based on the user profile data from the user profile includes: causing display of a presentation of the plurality of payment methods associated with the user profile at the client device; receiving a selection of a payment method from the presentation of the plurality of payment methods; and generating the payment credential based on the payment method.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity”. The non-bolded additional element of a client device fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 6-10, 13-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Badal-Badalian (US 2018/0150832 A1) in view of Subbarayan (US 10,579,999 B2).
Regarding claim 1, Badal-Badalian discloses:
executing an application at a client device, the application associated with a merchant; (Badal-Badalian ¶0198, FIG. 6 is a diagram of an example system for e-commerce transactions using mobile devices. The ecommerce application 506 can include the merchant website 106 in some embodiments.)
causing display of a presentation of the plurality of payment methods; receiving a selection of a payment method from among the plurality of payment methods associated with the user profile; (Badal-Badalian ¶0201, The user can select a payment option for purchasing the products and/or services using the mobile wallet application 104. The payment options may include different payment card options, for example. Badal-Badalian ¶0232, FIG. 15 is a screenshot of an interface of the wallet application 104 with visual representations of one or more payment accounts such as bank account, credit card account, and so on. The wallet application 104 enables selection of a payment account for a particular transaction. The wallet application 104 enables the addition of additional payment options for transactions. The wallet application 104 enables the removal of payment options. Accordingly, the wallet application 104 enables users to add, remove, and update payment options for transactions. As noted herein, the interface with different payment accounts can be used to link or associate a handle with a particular payment account.)
Badal-Badalian does not disclose, however Subbarayan teaches:
presenting a graphical user interface (GUI) associated with the application at the client device, the GUI including a simultaneous display of a first icon to initiate a request for a payment to the merchant associated with the application and a second icon to authenticate the request for the payment to the merchant associated with the application; (Subbarayan Col 12 lines 64-67 & col 13 lines 1-8, For example, FIGS. 3A-3F illustrate various views of GUis provided by a client application to facilitate electronic messaging and sending and receiving payments. FIGS. 3A-3F illustrate a consumer client-device 300 that can allow a user (e.g., a consumer) to interact with a merchant via the client application. Specifically, the client application allows the consumer to view information associated with goods and services provided by the merchant and to enter into a payment transaction with the merchant. As described in more detail below, the consumer and the merchant can communicate with each other via the client applications on the respective client devices. Subbarayan col 13 lines 42-64, In one or more embodiments, the client application also allows the consumer to communicate with the merchant about the displayed item. For example, the merchant page interface 302 can present a communication option 310 to communicate with the merchant. To illustrate, selecting the communication option 310 can cause the client application to open a messaging interface that allows the consumer to communicate (e.g., by instant messaging) with the merchant. The consumer can discuss pricing, purchase options, delivery options, availability, customization, and/or other information about the displayed product. The merchant product interface 302 can also display a purchase option 312 for a product on the merchant page for the product. Selecting the purchase option 312 can cause the client application to add the product to a virtual shopping cart and/or display a purchase interface. FIG. 3B illustrates a purchase interface 314 to purchase the product illustrated in FIG. 3A. When the consumer selects the purchase option 312, the client application adds the selected product to a virtual shopping cart and displays the purchase interface 314 with the contents of the shopping cart. The consumer can select a plurality of objects to add to the shopping cart prior to purchasing the product(s). )
receiving a first input that comprises a first gesture that selects the first icon to initiate the request (Subbarayan Col 13 lines 53-62, The merchant product interface 302 can also display a purchase option 312 for a product on the merchant page for the product. Selecting the purchase option 312 can cause the client application to add the product to a virtual shopping cart and/or display a purchase interface. FIG. 3B illustrates a purchase interface 314 to purchase the product illustrated in FIG. 3A. When the consumer selects the purchase option 312, the client application adds the selected product to a virtual shopping cart and displays the purchase interface 314 with the contents of the shopping cart. Fig. 3A, 312. Subbarayan col 15 lines 63-67 & col 16 lines 1-3, The method 400 includes an act 402 of receiving a request to initiate a payment transaction. For example, act 402 involves receiving, from a client device associated with a user account, a request to initiate a payment transaction with a merchant. To illustrate, act 402 can involve receiving the request to initiate the payment transaction in connection with a purchase order for a product or service provided by the merchant via a social networking system.)
accessing a user profile associated with the client device from within a database in response to the first gesture; the user profile comprising a plurality of payment methods and corresponding payment credentials stored in association with each individual of the plurality of payment methods; (Subbarayan Col 13 lines 65-67 & col 14 lines 1-6, The purchase interface 314 includes purchase information including payment transaction information. In particular, the purchase information includes product details 316, (including the quantity of the product), a purchase price 318, shipping details, and a payment method for completing the payment transaction. Although FIG. 3B illustrates a set of details associated with the shopping cart, the purchase interface 314 may include additional or alternative details that allow the user to verify and enter purchase information. Subbarayan col 16 lines 4-20, The method 400 also includes an act 404 of identifying a payment authorization number. For example, act 404 involves identifying a payment authorization number associated with the user account. Act 404 can involve identifying the payment authorization number from a user input from the client device 104 associated with the user account. Additionally, act 404 can involve identifying additional payment transaction information and payment credential information associated with the payment transaction with the merchant. Subbarayan col 21 lines 34-39, For example, the client application 502 can allow a consumer to input and save various payment methods and/or identify a default payment method, default currency, and otherwise specify other user preferences related to sending and/or receiving a payment. Subbarayan Col 24 lines 52-63, Upon the consumer and/or merchant registering a deposit account or other payment credential, the user profile database 536 can maintain the payment credential for the consumer/merchant. After the payment manager 540 receives the payment information for a payment transaction from a consumer, the payment manager 540 can identify the merchant. The payment manager 540 can lookup the merchant in the user profile database 536 to determine if the merchant has registered a payment credential. At this point, the payment manager 540 can initiate the transaction using the payment credential information associated with the consumer and merchant. Subbarayan Col 25 lines 10-22, As mentioned, the user profile database 536 stores user profile information for consumers and merchants. In one or more embodiments, user profile information includes payment credentials (i.e., a payment token representing a payment authorization number, as described previously) for a credit card, a debit card, a deposit account or other bank accounts, gift card accounts, store credit accounts, etc. The user profile database 536 can also store additional information associated with the payment credentials, such as expiration dates, security codes, address information, and/or other information. User profile information can also include one or more default payment method for payment transactions for one or more merchants or co-users.)
receiving a second input comprising a second gesture that selects the second icon to authenticate the request; (Subbarayan Col 14 lines 58-62, In response to a selection of the pay option 340, or in response to a selection of the option to add the payment credential, the consumer client-device 300 sends payment credentials to the payment system 108, as previously described.)
accessing a payment credential associated with the selected payment method from among the corresponding payment credentials from within the database responsive to the second gesture, the payment credential corresponding to the selected payment method; (Subbarayan col 27-46, For example, the consumer can access one or more user interfaces that allow the consumer to select an option to purchase a product or service from the merchant. To illustrate, selecting the option to purchase the product or service from the merchant causes the consumer client-device 104 to generate a payment message that includes payment information for a payment transaction between the consumer and the merchant. For example, the payment message can include a consumer identifier, a merchant identifier, a payment amount, product details, a payment authorization number, and/or other information that allows the payment system 108 to begin the payment transaction process. According to various examples, the consumer client-device 104 can obtain payment information for the payment message from interactions between the consumer and merchant, a data manager on the consumer client-device 104, and/or from user input. The consumer client-device 104 then sends 202 the payment message 202 to the payment system 108. Subbarayan col 7 lines 40-45, According to various examples, the consumer client-device 104 can obtain payment information for the payment message from interactions between the consumer and merchant, a data manager on the consumer client-device 104, and/or from user input. Subbarayan col 14 lines 19-24, The purchase interface can also include an option 324 to place the order for the product identified in the purchase interface 314. Specifically, if the consumer has previously added a payment credential, the option 324 to place the order uses the selected payment credential to process the order for the payment amount. Subbarayan col 21 lines 11-39, In one or more embodiments, the payment request generator 518 can create a data package that includes the payment amount, one or more consumer identifiers, one or more merchant identifiers, one or more payment methods or sender account information (e.g., the payment authorization number), authorization information, currency information, a message or payment description, and/or any other data that may be helpful to facilitating a payment form the sender to the recipient. Alternatively, a payment request can identify a merchant, an amount of a payment, and an offline reference that allows the consumer client-device to resolve inconsistencies in data sent and received. The payment request generator 518 can pass the payment request (e.g., the data package that includes the payment information) to the message handler 512 to send to the network application and/or payment system 108. The payment request generator 518 can also obtain payment information from various sources. For example, the payment request generator 518 can obtain payment information directly from the sender via the user input detector 510. Additionally, or alternatively, the payment request generator 518 can gain access to payment information maintained on the client device by the data manager 520. For example, the client application 502 can allow a consumer to input and save various payment methods and/or identify a default payment method, default currency, and otherwise specify other user preferences related to sending and/or receiving a payment. Subbarayan col 24 lines 41-55, To complete a transaction, the payment manager 540 can access or obtain payment credentials for the consumer and the merchant. Specifically, the payment manager 540 identifies a payment credential (e.g., a payment authorization number or a payment token) for the consumer in connection with a payment account of the consumer. Additionally, the payment manager 540 identifies a payment credential of the merchant in connection with a payment account of the merchant. The payment manager 540 can register one or more payment accounts or other payment credentials for the consumer and/or merchant with the network application. Upon the consumer and/or merchant registering a deposit account or other payment credential, the user profile database 536 can maintain the payment credential for the consumer/merchant. Subbarayan col 25 lines 10-22, As mentioned, the user profile database 536 stores user profile information for consumers and merchants. In one or more embodiments, user profile information includes payment credentials (i.e., a payment token representing a payment authorization number, as described previously) for a credit card, a debit card, a deposit account or other bank accounts, gift card accounts, store credit accounts, etc. The user profile database 536 can also store additional information associated with the payment credentials, such as expiration dates, security codes, address information, and/or other information. User profile information can also include one or more default payment method for payment transactions for one or more merchants or co-users.)
authorizing the payment to the merchant based on the payment credential; and (Subbarayan Col 6 lines 66-67 & col 7 lines 1-2, The card network system 118 uses the network payment token to determine the corresponding payment authorization number and authorizes the payment transaction based on the cryptogram. Subbarayan Col 15 lines 27-36, After the consumer provides payment credentials to the payment system 108, and after the payment system 108 obtain the network payment token and single-use cryptogram for the payment transaction from the card network system 118, the payment system 108 sends the network payment token and the cryptogram, along with additional payment transaction information to the merchant commerce platform 106, allowing the merchant to begin processing the payment transaction to complete the purchase of goods/services. Subbarayan Col 16 lines 21-55, The method 400 further includes an act 406 of generating a payment token request. For example, act 406 involves generating a payment token request that includes the payment authorization number. Act 406 can also involve generating the payment token request to include a token requestor identifier associated with the one or more servers. For example, the token requestor identifier can be associated with a trust relationship between the one or more servers and the card network system associated with the payment authorization number. Additionally, the method 400 includes an act 408 of sending the payment token request to a card network system 118. For example, act 408 involves sending the payment token request to a card network system associated with the payment authorization number. Act 408 can involve identifying the card network system associated with the payment authorization number based on one or more characteristics of the payment authorization number. To illustrate, act 408 can involve identifying card network system associated with the payment authorization number based on a combination of digits in the payment authorization number. The method 400 also includes an act 410 of receiving a network payment token. For example, act 410 involves receiving, from the card network system associated with the payment authorization number, a network payment token representing the payment authorization number and a single-use cryptogram corresponding to the payment transaction. For example, the single-use cryptogram can tie the network payment token to the payment transaction. Act 410 can involve associating the network payment token with the user account, and storing the network payment token on the one or more servers. Act 410 can also involve removing the payment authorization number from the one or more servers in response to storing the network payment token on the one or more servers.)
passing a payment token to the merchant responsive to the authorizing the payment to the merchant within the application, the payment token comprising a validation. (Subbarayan Col 6 lines 42-57, Once the card network system 118 provides the network payment token to the payment system 108, the payment system 108 then sends the network payment token to the merchant commerce platform 106 to initiate the payment transaction and process the consumer's purchase. Additionally, the card network system 118 can send a cryptogram associated with the payment transaction to the payment system 108. As used herein the term "cryptogram" refers to a code that the card network system 118 assigns to the payment transaction for use in authorizing use of the network payment token for the payment transaction. For example, a cryptogram can be a numeric code or other value that allows the payment system 108 to validate the use of the network payment token for the corresponding payment transaction. The payment system 108 also sends the cryptogram token to the merchant commerce platform 106. Subbarayan Col 16 lines 56-67 & col 17 lines 1-4, The method 400 includes an act 412 of generating a payment transaction initiation message. For example, act 412 involves generating a payment transaction initiation message comprising the network payment token and the single-use cryptogram. Act 412 can involve generating the payment transaction initiation message to include the network payment token, the single-use cryptogram, and payment transaction information for processing the payment transaction. The method 400 also includes an act 414 of sending the payment transaction initiation message to the merchant. For example, act 414 involves sending the payment transaction initiation message to the merchant for processing the payment transaction. To illustrate, act 414 can involve sending the payment initiation message to a merchant client device associated with the merchant.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Badal-Badalian’s teaching with Subbarayan’s teaching. One of ordinary skills in the art would have been motivated in order to facilitate more efficient and secured payment transactions as well as a more user-friendly GUI that authenticates the 8user and verify payments with intuitive inputs. The combination yields a unified system that enhances the efficiency, security and convenience of merchant payments.
Regarding claim 2, Badal-Badalian and Subbarayan disclose each and every element of claim 1 above. Badal-Badalian further discloses:
the accessing the user profile associated with the client device in response to the input that selects the icon further comprises: accessing the database that includes the user profile data responsive to the input that selects the icon from the client device. (Badal-Badalian ¶0148-0149, The payment server 110 can store multiple user account profiles in a repository that can be accessed in order to determine the mobile wallet application 104 associated with a particular handle. [0149] Upon receiving the handle, the merchant website 106 sends the handle to the payment server 110, which looks up the associated mobile device 114 (and the mobile wallet application 104) using the repository of user account profiles.)
Regarding claim 3, Badal-Badalian and Subbarayan disclose each and every element of claim 2 above. Badal-Badalian further discloses:
the database includes a third-party database. (Badal-Badalian ¶0148-0149, The payment server 110 can store multiple user account profiles in a repository that can be accessed in order to determine the mobile wallet application 104 associated with a particular handle. [0149] Upon receiving the handle, the merchant website 106 sends the handle to the payment server 110, which looks up the associated mobile device 114 (and the mobile wallet application 104) using the repository of user account profiles.)
Regarding claim 6, Badal-Badalian and Subbarayan disclose each and every element of claim 1 above.
Badal-Badalian further discloses:
receiving, at the client device, a confirmation of the payment based on the validation; and causing display of a presentation of the confirmation at the client device. (Badal-Badalian ¶0004 Claim 1, The system can have the electronic wallet application having non-transitory computer-readable storage medium with computer-executable instructions for causing a processor of the mobile device to: authorize a user account of the electronic wallet application; trigger the display of a confirmation request on a display of the mobile device; provide a payment confirmation.)
Regarding claim 7, Badal-Badalian and Subbarayan disclose each and every element of claim 1 above.
Badal-Badalian further discloses:
the user profile data associated with the user profile includes a plurality of payment methods associated with the user profile, and the generating the payment credential based on the user profile data from the user profile includes: causing display of a presentation of the plurality of payment methods associated with the user profile at the client device; (Badal-Badalian ¶0146, A message with a confirmation request can be displayed at the mobile device 114 to confirm the purchase and select a method of payment (e.g. credit card, bank card, value card).)
receiving a selection of a payment method from the presentation of the plurality of payment methods; and generating the payment credential based on the payment method. (Badal-Badalian ¶0146, Upon confirming the selection, the mobile device 114 sends data to the associated financial institution payment server 110 in the form of tokenized data representing the selected payment method.)
Regarding claims 8 and 15 , Badal-Badalian discloses:
executing an application at a client device, the application associated with a merchant; (Badal-Badalian ¶0198, FIG. 6 is a diagram of an example system for e-commerce transactions using mobile devices. The ecommerce application 506 can include the merchant website 106 in some embodiments.)
causing display of a presentation of the plurality of payment methods; receiving a selection of a payment method from among the plurality of payment methods associated with the user profile; (Badal-Badalian ¶0201, The user can select a payment option for purchasing the products and/or services using the mobile wallet application 104. The payment options may include different payment card options, for example. Badal-Badalian ¶0232, FIG. 15 is a screenshot of an interface of the wallet application 104 with visual representations of one or more payment accounts such as bank account, credit card account, and so on. The wallet application 104 enables selection of a payment account for a particular transaction. The wallet application 104 enables the addition of additional payment options for transactions. The wallet application 104 enables the removal of payment options. Accordingly, the wallet application 104 enables users to add, remove, and update payment options for transactions. As noted herein, the interface with different payment accounts can be used to link or associate a handle with a particular payment account.)
Badal-Badalian further discloses:
a memory; and at least one hardware processor coupled to the memory and comprising instructions that causes the system to perform operations (Badal-Badalian ¶0272, The embodiments described herein are implemented by physical computer hardware, including computing devices, servers, receivers, transmitters, processors, memory, displays, and networks.)
A non-transitory machine-readable storage medium (Badal-Badalian ¶0271, The software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM), a USB flash disk, or a removable hard disk.)
Badal-Badalian does not disclose, however Subbarayan teaches:
presenting a graphical user interface (GUI) associated with the application at the client device, the GUI including a first icon to initiate a request for a payment to the merchant associated with the application and a second icon to authenticate the request for the payment to the merchant associated with the application; (Subbarayan Col 12 lines 64-67 & col 13 lines 1-8, For example, FIGS. 3A-3F illustrate various views of GUis provided by a client application to facilitate electronic messaging and sending and receiving payments. FIGS. 3A-3F illustrate a consumer client-device 300 that can allow a user (e.g., a consumer) to interact with a merchant via the client application. Specifically, the client application allows the consumer to view information associated with goods and services provided by the merchant and to enter into a payment transaction with the merchant. As described in more detail below, the consumer and the merchant can communicate with each other via the client applications on the respective client devices.)
receiving a first input that comprises a first gesture that selects the first icon to initiate the request (Subbarayan Col 13 lines 53-62, The merchant product interface 302 can also display a purchase option 312 for a product on the merchant page for the product. Selecting the purchase option 312 can cause the client application to add the product to a virtual shopping cart and/or display a purchase interface. FIG. 3B illustrates a purchase interface 314 to purchase the product illustrated in FIG. 3A. When the consumer selects the purchase option 312, the client application adds the selected product to a virtual shopping cart and displays the purchase interface 314 with the contents of the shopping cart. Fig. 3A, 312. Subbarayan col 15 lines 63-67 & col 16 lines 1-3, The method 400 includes an act 402 of receiving a request to initiate a payment transaction. For example, act 402 involves receiving, from a client device associated with a user account, a request to initiate a payment transaction with a merchant. To illustrate, act 402 can involve receiving the request to initiate the payment transaction in connection with a purchase order for a product or service provided by the merchant via a social networking system.)
accessing a user profile associated with the client device from within a database in response to the first gesture; the user profile comprising a plurality of payment methods and corresponding payment credentials associated with each of the plurality of payment methods; (Subbarayan Col 13 lines 65-67 & col 14 lines 1-6, The purchase interface 314 includes purchase information including payment transaction information. In particular, the purchase information includes product details 316, (including the quantity of the product), a purchase price 318, shipping details, and a payment method for completing the payment transaction. Although FIG. 3B illustrates a set of details associated with the shopping cart, the purchase interface 314 may include additional or alternative details that allow the user to verify and enter purchase information. Subbarayan col 16 lines 4-20, The method 400 also includes an act 404 of identifying a payment authorization number. For example, act 404 involves identifying a payment authorization number associated with the user account. Act 404 can involve identifying the payment authorization number from a user input from the client device 104 associated with the user account. Additionally, act 404 can involve identifying additional payment transaction information and payment credential information associated with the payment transaction with the merchant. Subbarayan col 21 lines 34-39, For example, the client application 502 can allow a consumer to input and save various payment methods and/or identify a default payment method, default currency, and otherwise specify other user preferences related to sending and/or receiving a payment. Subbarayan Col 24 lines 52-63, Upon the consumer and/or merchant registering a deposit account or other payment credential, the user profile database 536 can maintain the payment credential for the consumer/merchant. After the payment manager 540 receives the payment information for a payment transaction from a consumer, the payment manager 540 can identify the merchant. The payment manager 540 can lookup the merchant in the user profile database 536 to determine if the merchant has registered a payment credential. At this point, the payment manager 540 can initiate the transaction using the payment credential information associated with the consumer and merchant. Subbarayan Col 25 lines 10-22, As mentioned, the user profile database 536 stores user profile information for consumers and merchants. In one or more embodiments, user profile information includes payment credentials (i.e., a payment token representing a payment authorization number, as described previously) for a credit card, a debit card, a deposit account or other bank accounts, gift card accounts, store credit accounts, etc. The user profile database 536 can also store additional information associated with the payment credentials, such as expiration dates, security codes, address information, and/or other information. User profile information can also include one or more default payment method for payment transactions for one or more merchants or co-users.)
receiving a second input comprising a second gesture that selects the second icon to authenticate the request; (Subbarayan Col 14 lines 58-62, In response to a selection of the pay option 340, or in response to a selection of the option to add the payment credential, the consumer client-device 300 sends payment credentials to the payment system 108, as previously described.)
accessing a payment credential associated with the selected payment method from among the corresponding payment credentials from within the database responsive to the second gesture; (Subbarayan col 27-46, For example, the consumer can access one or more user interfaces that allow the consumer to select an option to purchase a product or service from the merchant. To illustrate, selecting the option to purchase the product or service from the merchant causes the consumer client-device 104 to generate a payment message that includes payment information for a payment transaction between the consumer and the merchant. For example, the payment message can include a consumer identifier, a merchant identifier, a payment amount, product details, a payment authorization number, and/or other information that allows the payment system 108 to begin the payment transaction process. According to various examples, the consumer client-device 104 can obtain payment information for the payment message from interactions between the consumer and merchant, a data manager on the consumer client-device 104, and/or from user input. The consumer client-device 104 then sends 202 the payment message 202 to the payment system 108. Subbarayan col 7 lines 40-45, According to various examples, the consumer client-device 104 can obtain payment information for the payment message from interactions between the consumer and merchant, a data manager on the consumer client-device 104, and/or from user input. Subbarayan col 14 lines 19-24, The purchase interface can also include an option 324 to place the order for the product identified in the purchase interface 314. Specifically, if the consumer has previously added a payment credential, the option 324 to place the order uses the selected payment credential to process the order for the payment amount. Subbarayan col 21 lines 11-39, In one or more embodiments, the payment request generator 518 can create a data package that includes the payment amount, one or more consumer identifiers, one or more merchant identifiers, one or more payment methods or sender account information (e.g., the payment authorization number), authorization information, currency information, a message or payment description, and/or any other data that may be helpful to facilitating a payment form the sender to the recipient. Alternatively, a payment request can identify a merchant, an amount of a payment, and an offline reference that allows the consumer client-device to resolve inconsistencies in data sent and received. The payment request generator 518 can pass the payment request (e.g., the data package that includes the payment information) to the message handler 512 to send to the network application and/or payment system 108. The payment request generator 518 can also obtain payment information from various sources. For example, the payment request generator 518 can obtain payment information directly from the sender via the user input detector 510. Additionally, or alternatively, the payment request generator 518 can gain access to payment information maintained on the client device by the data manager 520. For example, the client application 502 can allow a consumer to input and save various payment methods and/or identify a default payment method, default currency, and otherwise specify other user preferences related to sending and/or receiving a payment. Subbarayan col 24 lines 41-55, To complete a transaction, the payment manager 540 can access or obtain payment credentials for the consumer and the merchant. Specifically, the payment manager 540 identifies a payment credential (e.g., a payment authorization number or a payment token) for the consumer in connection with a payment account of the consumer. Additionally, the payment manager 540 identifies a payment credential of the merchant in connection with a payment account of the merchant. The payment manager 540 can register one or more payment accounts or other payment credentials for the consumer and/or merchant with the network application. Upon the consumer and/or merchant registering a deposit account or other payment credential, the user profile database 536 can maintain the payment credential for the consumer/merchant. Subbarayan col 25 lines 10-22, As mentioned, the user profile database 536 stores user profile information for consumers and merchants. In one or more embodiments, user profile information includes payment credentials (i.e., a payment token representing a payment authorization number, as described previously) for a credit card, a debit card, a deposit account or other bank accounts, gift card accounts, store credit accounts, etc. The user profile database 536 can also store additional information associated with the payment credentials, such as expiration dates, security codes, address information, and/or other information. User profile information can also include one or more default payment method for payment transactions for one or more merchants or co-users.)
authorizing the payment to the merchant based on the payment credential; and (Subbarayan Col 6 lines 66-67 & col 7 lines 1-2, The card network system 118 uses the network payment token to determine the corresponding payment authorization number and authorizes the payment transaction based on the cryptogram. Subbarayan Col 15 lines 27-36, After the consumer provides payment credentials to the payment system 108, and after the payment system 108 obtain the network payment token and single-use cryptogram for the payment transaction from the card network system 118, the payment system 108 sends the network payment token and the cryptogram, along with additional payment transaction information to the merchant commerce platform 106, allowing the merchant to begin processing the payment transaction to complete the purchase of goods/services. Subbarayan Col 16 lines 21-55, The method 400 further includes an act 406 of generating a payment token request. For example, act 406 involves generating a payment token request that includes the payment authorization number. Act 406 can also involve generating the payment token request to include a token requestor identifier associated with the one or more servers. For example, the token requestor identifier can be associated with a trust relationship between the one or more servers and the card network system associated with the payment authorization number. Additionally, the method 400 includes an act 408 of sending the payment token request to a card network system 118. For example, act 408 involves sending the payment token request to a card network system associated with the payment authorization number. Act 408 can involve identifying the card network system associated with the payment authorization number based on one or more characteristics of the payment authorization number. To illustrate, act 408 can involve identifying card network system associated with the payment authorization number based on a combination of digits in the payment authorization number. The method 400 also includes an act 410 of receiving a network payment token. For example, act 410 involves receiving, from the card network system associated with the payment authorization number, a network payment token representing the payment authorization number and a single-use cryptogram corresponding to the payment transaction. For example, the single-use cryptogram can tie the network payment token to the payment transaction. Act 410 can involve associating the network payment token with the user account, and storing the network payment token on the one or more servers. Act 410 can also involve removing the payment authorization number from the one or more servers in response to storing the network payment token on the one or more servers.)
passing a payment token to the merchant responsive to the authorizing the payment to the merchant within the application, the payment token comprising a validation. (Subbarayan Col 6 lines 42-57, Once the card network system 118 provides the network payment token to the payment system 108, the payment system 108 then sends the network payment token to the merchant commerce platform 106 to initiate the payment transaction and process the consumer's purchase. Additionally, the card network system 118 can send a cryptogram associated with the payment transaction to the payment system 108. As used herein the term "cryptogram" refers to a code that the card network system 118 assigns to the payment transaction for use in authorizing use of the network payment token for the payment transaction. For example, a cryptogram can be a numeric code or other value that allows the payment system 108 to validate the use of the network payment token for the corresponding payment transaction. The payment system 108 also sends the cryptogram token to the merchant commerce platform 106. Subbarayan Col 16 lines 56-67 & col 17 lines 1-4, The method 400 includes an act 412 of generating a payment transaction initiation message. For example, act 412 involves generating a payment transaction initiation message comprising the network payment token and the single-use cryptogram. Act 412 can involve generating the payment transaction initiation message to include the network payment token, the single-use cryptogram, and payment transaction information for processing the payment transaction. The method 400 also includes an act 414 of sending the payment transaction initiation message to the merchant. For example, act 414 involves sending the payment transaction initiation message to the merchant for processing the payment transaction. To illustrate, act 414 can involve sending the payment initiation message to a merchant client device associated with the merchant.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Badal-Badalian’s teaching with Subbarayan’s teaching. One of ordinary skills in the art would have been motivated in order to facilitate more efficient and secured payment transactions as well as a more user-friendly GUI that authenticates the 8user and verify payments with intuitive inputs. The combination yields a unified system that enhances the efficiency, security and convenience of merchant payments.
Regarding claims 9 and 16, Badal-Badalian and Subbarayan disclose each and every element of claims 8 and 15 above. Badal-Badalian further discloses:
the accessing the user profile associated with the client device in response to the input that selects the icon further comprises: accessing the database that includes the user profile data responsive to the input that selects the icon from the client device. (Badal-Badalian ¶0148-0149, The payment server 110 can store multiple user account profiles in a repository that can be accessed in order to determine the mobile wallet application 104 associated with a particular handle. [0149] Upon receiving the handle, the merchant website 106 sends the handle to the payment server 110, which looks up the associated mobile device 114 (and the mobile wallet application 104) using the repository of user account profiles.)
Regarding claims 10 and 17, Badal-Badalian and Subbarayan disclose each and every element of 9 and 16 above. Badal-Badalian further discloses:
the database includes a third-party database. (Badal-Badalian ¶0148-0149, The payment server 110 can store multiple user account profiles in a repository that can be accessed in order to determine the mobile wallet application 104 associated with a particular handle. [0149] Upon receiving the handle, the merchant website 106 sends the handle to the payment server 110, which looks up the associated mobile device 114 (and the mobile wallet application 104) using the repository of user account profiles.)
Regarding claims 13 and 20, Badal-Badalian and Subbarayan disclose each and every element of claims 8 and 15 above.
Badal-Badalian further discloses:
receiving, at the client device, a confirmation of the payment based on the validation; and causing display of a presentation of the confirmation at the client device. (Badal-Badalian ¶0004 Claim 1, The system can have the electronic wallet application having non-transitory computer-readable storage medium with computer-executable instructions for causing a processor of the mobile device to: authorize a user account of the electronic wallet application; trigger the display of a confirmation request on a display of the mobile device; provide a payment confirmation.)
Regarding claim 13, Badal-Badalian and Subbarayan disclose each and every element of claim 8 above.
Badal-Badalian further discloses:
the user profile data associated with the user profile includes a plurality of payment methods associated with the user profile, and the generating the payment credential based on the user profile data from the user profile includes: causing display of a presentation of the plurality of payment methods associated with the user profile at the client device; (Badal-Badalian ¶0146, A message with a confirmation request can be displayed at the mobile device 114 to confirm the purchase and select a method of payment (e.g. credit card, bank card, value card).)
receiving a selection of a payment method from the presentation of the plurality of payment methods; and generating the payment credential based on the payment method. (Badal-Badalian ¶0146, Upon confirming the selection, the mobile device 114 sends data to the associated financial institution payment server 110 in the form of tokenized data representing the selected payment method.)
Response to Arguments
Claim Objections
Claim objections in the previous final action dated 01/29/2026 are withdrawn in light of the claim amendments.
Claim Rejections – 35 U.S.C. § 101
The applicant asserts that the amended claim integrates the abstract idea into a practical application and presents several assertions/arguments in regards to this. The basis for these assertions are found on pages 7-10.
First, the applicant asserts that “the Simultaneous Dual-Icon GUI Provides Specific Technical Improvement”. The examiner finds this assertion not persuasive and respectfully disagrees. The simultaneous display of a first icon to initiate a transaction and a second icon to authorize a transaction does not constitute a technical improvement to computer GUI or any other additional elements in the claim. Improving usability by presenting different icons related to different functions to the user simultaneously, merely makes information easier for the user to access, which is just a benefit to the user and not an improvement to the underlying computer technology. (i.e. client device , database, GUI). This display does not change how the processor works, how the data is stored or how the transactions are processed. Therefore, the dual icon display represents just a design choice and not a technological improvement.
Second, the applicant asserts “the claims now recite a particular data structure” that is not “routine database storage and retrieval” as asserted by the examiner on the previous office action. The applicant further assert that “the claims require a specific structured association where each individual payment method has its own corresponding payment credentials stored in association therewith, and the system must access the specific payment credential that corresponds to the selected payment method from among the plurality of corresponding payment credentials. This structured one-to-one association between individual payment methods and their corresponding credentials, combined with selective retrieval of the specific corresponding credential, represents a particular database architecture designed to support the dual-icon gesture- based authentication workflow.” The examiner finds these assertions not persuasive and respectfully disagrees. The amended claim does not recite a particular data structure. The recitation of “corresponding payment credentials stored in association with each individual of the plurality of payment methods” teaches that each payment credential is linked to their respective payment method, which is an expected way of storing related data records in a database or table (i.e. relational database). As mentioned in the previous office action, there is no recitation of any particular database schema or storage technique that alters the technical operation of the database. Accordingly, the claim as amended merely recites the use of a generic database to store payment methods and associated credentials.
Finally, the applicant asserts that “the combination of the simultaneous dual-icon GUI presentation with the structured payment method-credential association database, accessed through coordinated gesture inputs, provides a specific technical solution to the problem of secure and efficient in-application payment processing.” and “it represents a particular technological approach that improves upon conventional payment processing systems by integrating authentication controls directly into the GUI presentation while maintaining structured credential management through the database architecture”. The examiner also finds these assertions not persuasive and respectfully disagrees. The combination of dual icon display along with the alleged structured database and coordinated gestures are merely a combination of conventional user interface interactions with routine back data storage use to process known payment transactions. As previously mentioned, the dual display of icons as well as the coordinated gestures inputs are just a design choice directed to improve user experience and usability but do not constitute an improvement upon the technology. Similarly, the alleged “structured database” merely amounts to storing payment methods and their corresponding payment credentials. Further, the integration of authentication controls directly into the GUI presentation does not represent a security improvement. Providing authentication controls in a form of icons to the user merely offers a user trigger for already established authentication processes. The claim as amended does not recite any new protocol or mechanism that can improve the security of the system (i.e. cryptographic technique, authentication process). Therefore, the amended claim does not improve the functioning of the computer, the database or the network but instead uses generic database storage techniques, user interface elements and gesture based inputs to implement the abstract idea.
As such the claims remain within an abstract idea and rejection is maintained based on the newly amended claims.
Claim Rejections – 35 U.S.C. § 103
First, the applicant asserts that Subbarayan fails to teach "…corresponding payment credentials stored in association with each individual associated with each of the plurality of payment methods;” as now recited in the amended claims and that Subbarayan “fails to disclose a data structure wherein each individual payment method has its own distinct set of payment credentials stored in association therewith”. The amended claim, under the broadest reasonable interpretation, does not require any particular data structure. Rather the limitation reasonably involves storing credentials that correspond to their respective payment methods in such a way that the system can identify and use credentials for a selected method. Subbarayan teaches user profile information that includes credentials for multiple payment methods (i.e. credit card, debit cards, deposit accounts). One in ordinary skill in the art would understand that for the system to maintain multiple payment methods, the credentials for each payment method must be stored in a manner that is associated with their respective payment method so the system can distinguish among them and process the transaction using the correct payment credentials for the selected payment method. For example credit card credentials will correspond to the credit card method and deposit account credentials will correspond to the deposit account method. Applicant’s argument improperly demands an express disclosure of the precise words of “stored in association with each individual of the plurality of payment methods”, however is not require the recitation of the same words/terms when determining obviousness or anticipation. Here, it is obvious that the different payment methods are stored in association with their respective credentials, otherwise it would be impossible for the system to determine which credential belong to the selected payment method and would not be able to accurately process the transaction/payment.
Moreover, the applicant asserts that while Subbarayan “describes payment credentials generally associated with account types (credit card, debit card, deposit account) but does not teach that the user profile comprises a plurality of specific payment methods where corresponding payment credentials are stored in association with each individual payment method.” Applicant’s assertion is not persuasive and the examiner respectfully disagree. Subbarayan explicitly teaches that the user can register more than one payment method/account (col 21 lines 34-37, col 24 lines 49-55 & col 25 lines 10-22), therefore the user profile “comprises a plurality of specific payment methods…” as recited on the amended claim.
Further, the applicant asserts “that Subbarayan contemplates selecting among payment methods based on defaults or preferences, not accessing payment credentials that are stored in association with each individual payment method as now claimed.” Applicant’s assertion is not persuasive and the examiner respectfully disagree. The teaching of “one or more default payment method” does not merely contemplates selecting among payment methods based on defaults or preferences. A default payment method is a designation applied to one or more store payment methods having corresponding credentials, a default payment method still an actual payment method stored in the database. Further, the disclosure is not limited to default payment methods. Rather it states that user profile can include one or more default payment methods indicating that default payment methods are one example of payment methods stored in the user profile database. Therefore, “obtaining credentials for a default payment method” reads on “accessing payment credentials that are stored in association with each individual payment method as now claimed”.
Furthermore, the applicant asserts that the cited portions of Subbarayan col 14 lines 58-67 and col 15 lines 1-6 and col. 24, lines 52-63 fail to disclose “accessing a payment credential associated with the selected payment method from among the corresponding payment credentials from within the database responsive to the second gesture, the payment credential corresponding to the selected payment method”. The examiner finds this assertion persuasive and agrees with the applicant that the specified portions cited in the reference do not teach “accessing a payment credential stored in a database”. Therefore, the examiner has amended the cited portion of the rejection to disclose relevant portions of Subbarayan that do disclose “accessing a payment credential associated with the selected payment method from among the corresponding payment credentials from within the database responsive to the second gesture, the payment credential corresponding to the selected payment method”.
Finally, the applicant states that “Subbarayan does not teach accessing a specific payment credential that corresponds to a selected payment method from among a plurality of corresponding payment credentials stored in association with each individual payment method within a database, where such accessing occurs responsive to a specific gesture (the second gesture that authenticates the request).” Applicant’s assertion is not persuasive and the examiner respectfully disagrees. Subbarayan reasonably teaches or suggest accessing payment credentials from stored payment credentials in a database. Under the broadest reasonable interpretation a payment credential refers to any data used to identify, authenticate or authorize a payment method in a transaction. Further, a network token is “a payment credential specific to a card-merchant pair and used as a substitute for a card's primary account number (PAN), the 15- or 16-digit number found on every credit or debit card.”(PayPal) Therefore, Subbarayan clearly implies accessing stored payment credentials (i.e. a network payment token, credit card number, debit card number) from the user database.
As such the claim rejection is maintained over Badal-Badalian in view of Subbarayan.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2012/0095852 A1 to Bauer et al. discloses: A mobile payment method, system and graphical user interface are described that facilitate efficient and secured payment transactions from an electronic wallet on a user portable electronic device with a merchant point of sale terminal over a contactless communications link. In one aspect, the electronic wallet includes a flag indicating whether input of the passcode is required to access the electronic wallet, which flag can be set by a remote device. In another aspect, a shortcut is provided to directly execute the payment features of the electronic wallet application software.
US 10776763 B2 to Nair discloses: Aspects of the present disclosure involve systems, methods, devices, and the like for processing a transaction. In one embodiment, a system is introduced that enables a communication between applications. The communication occurs through the use of one or more gestures that enable the request for information, funds, items for purchase and the like. In another embodiment, a system if introduced that enables a unified multi-marketplace communication. The communication includes the use of gestures for the transfer of information, funds, items for purchase, discounts, etc., using a unifying entity. The unifying entity can be a financial institution, payment provider, or the like that may be used to carry a transaction between applications allowing for a single checkout.
US 2021/0303112 A1 to Harrison et al. discloses: An interactive sticker system to perform operations that include: causing display of a presentation of media at a client device, the presentation of the media including a display of an icon within the presentation of the media; receiving an input that selects the icon from the client device, the input comprising an input attribute; generating a menu element based on the icon and the input attribute in response to the input that selects the icon; and presenting the menu element at a position within the presentation of the media at the client device. 37. US 10,776,763 B2 to Nair discloses: Aspects of the present disclosure involve systems, methods, devices, and the like for processing a transaction. In one embodiment, a system is introduced that enables a communication between applications. The communication occurs through the use of one or more gestures that enable the request for information, funds, items for purchase and the like. In another embodiment, a system if introduced that enables a unified multi-marketplace communication. The communication includes the use of gestures for the transfer of information, funds, items for purchase, discounts, etc., using a unifying entity. The unifying entity can be a financial institution, payment provider, or the like that may be used to carry a transaction between applications allowing for a single checkout.
US 2016/0253665 A1 to Van Os et al. The present disclosure relates to making payments with a mobile device. In one example process, the mobile device receives and stores information for one or more payment accounts on the mobile device. The mobile device is used to make payments using the payment accounts. In some examples, authorization to proceed with a payment is performed before each purchase made by the user. The authorization process can include receiving a verification of the user, such as a fingerprint scan or passcode. In some examples, a payment account is selected from among available payment accounts. In some examples, an indication is displayed of a digital item associated with a purchased item. In some examples, a payment transaction is initiated with participants of an ongoing communication. In some examples, an application of a retailer is invoked based on the availability of the application. In some examples, a purchase recommendation is provided.
US 2014/0229339 A1 to Massiere et al. discloses: A user device configured to connect to a mobile telephony network and associated with an identification number in the mobile telephony network. The user device selects a method of paying for the shopping basket on a first page of the merchant server; upon selection, the user device sends a payment request to a payment validation module, which is enriched with identification data of the user device; the user device receives a local authentication request message from the payment validation module over the mobile telephony network; on receiving the local authentication request message, the user device triggers execution of an operation of locally authenticating a user of the user device; the user device sends a local authentication response message to the payment validation module; and the user device is redirected by the payment validation module to a second page of the merchant server giving the result of the payment transaction.
US 2016/0203475 A1 to Venugopalan et al. discloses: A method and system are presented for making a secure payment transaction using a payment card associated with a consumer which has been registered with a digital wallet. A secure server is arranged, in response to a request from a merchant server in relation to the consumer, to extract from the digital wallet payment credentials for the payment card. The secure server uses the payment credentials and the identity of the merchant server to generate a token. The token is provided to the merchant. To effect a payment transaction, the merchant server returns the token to the secure server with details of the desired payment transaction, and the secure server arranges for the payment transaction to occur, and notifies the merchant server. The merchant server does not receive the payment credentials of the payment card during this process,
so even if its security is compromised, the payment credentials are not at risk.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JANICE LOZA whose telephone number is (571)270-3979. The examiner can normally be reached Monday - Friday 7:30am - 5:00pm.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/J.L./Examiner, Art Unit 3698
/STEVEN S KIM/Primary Examiner, Art Unit 3698
Prosecution Insights