DETAILED ACTION
The present application is being examined under the first inventor to file provisions of the AIA . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This Office Action is in response Applicant communication filed on 5/11/2026.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 5/11/2026 has been entered.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. Applicant has not complied with one or more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 119(e) as follows:
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994).
The disclosure of the prior-filed applications, Application No. 62/121,526, 62/107,191, and 62/087,155, fail to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. Applications 62/121,526, 62/107,191, and 62/087,155 fail to disclose “providing, by a provider of a mobile device that is at least one of a manufacturer of a hardware of the mobile device or a developer of an operating system of the mobile device, a proprietary token for use on the mobile device of a customer, the proprietary token being proprietary to the mobile device based on at least one of the hardware or the operating system of the mobile device and stored on the mobile device prior to a request to pay” as well as other limitations within the independent claims. Therefore the earliest priority date of this instant application is 12/02/2015 of application 14/957,062.
Claims
Claims 1 and 14 have been amended.
Claims 1-20 are currently pending in the application.
Information Disclosure Statements
The Information Disclosure Statement (IDS) that was filed on 5/11/2026 has been considered.
Response to Arguments
103
In Applicant’s arguments with respect to claim 1 have been considered but are moot because new references have been added as necessitated by the applicant’s amendments to the claims.
Rejections under 35 § U.S.C. 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 of this title, 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.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20130110658 A1 (“Lyman”) and US 2017/0344981 A1 (“Jain”) and US 20100327054 A1 (“Hammad”) and US 20150199689 A1 (“Kumnick”).
Per claim 1, Lyman discloses:
providing… a proprietary token for use on a mobile device of a customer, the proprietary token… stored on the mobile device prior to the request to pay (e.g. The method 300 then proceeds to block 310, where the mobile device 108 receives and stores the token. In some embodiments, the token may be received directly from the mobile wallet registry system 100. In some embodiments, the token may be transmitted by the mobile wallet registry system 100 to the configuration portal server 102, and the configuration portal server 102 may transmit the token to the mobile device 108. In some embodiments, the mobile device 108 may also receive and store policy setting information, such as a time-to-live value for the token and/or the like, for future purchases. The token and associated policy setting information (where applicable) may be stored within the general memory of the mobile device 108, within a secure hardware element on the mobile device 108, or may be stored within the service application 107 or sponsor application 106) (Section [0023], [0025], and [0046]-[0049]);
receiving, by the provider, a request for a determination as to whether the proprietary token is valid (e.g. At block 408, the payment gateway module 112 detects the token as being a token for use with the mobile wallet registry system 100 instead of for direct transmission to a payment processor 116, and transmits a validation request including the token to a mobile token validation module 122) (Section [0052] and [0053]);
making, by the provider, the determination as to whether the proprietary token is valid (e.g. In some embodiments, the configuration portal server 102 may be operated by the party issuing the payment service to the consumer (i.e., a card issuer, a bank, an alternative payment service provider such as PayPal, and/or the like). An exemplary one of these embodiments is illustrated in FIG. 5. In such embodiments, the merchant point-of-sale device 110 may route an authorization request containing a payment token directly to the mobile wallet registry system 100 without using the payment gateway module 112. If there is a payment gateway module 112 present in this scenario, it may be transparent, or the authorization request may include information that indicates to the payment gateway module 112 that it should relay the authorization request to the mobile wallet registry system 100 rather than suspend the authorization request and send a token validation request to the mobile wallet registry system 100. The mobile wallet registry system 100 validates the token and, if successful, resolves the wallet ID associated with the token) (Section [0038], [0052], [0053], and [0056]).
Note: the limitation “a provider that is at least one of a manufacturer of a hardware of the mobile device or a developer of an operating system of the mobile device” does not distinguish over the prior art because it is describing the token provider and is not positively recited as a step of the method. The description of the provider does not affect the rest of the positively recited steps in the method.
Although Lyman discloses a provider providing a proprietary token to a mobile device and determining whether the token is valid during a payment transaction at a merchant, Lyman does not specifically disclose:
…by a provider of a mobile device that is at least one of a manufacturer of a hardware of the mobile device or a developer of an operating system of the mobile device,… the proprietary token being proprietary to the mobile device based on at least one of the hardware or the operating system of the mobile device…;
establish a wireless connection between a mobile device of a customer and a client computer used by the customer to perform the electronic commerce transaction using an internet browser;
receive, after the proprietary token has been provided by the provider, a retrieval request from the client computer via the wireless connection to provide the proprietary token of the mobile device that enables payment for the electronic commerce transaction;
transfer, the proprietary token from the mobile device to the client computer over the wireless connection to facilitate at least one electronic commerce transaction that includes the electronic commerce transaction.
However Jain, in analogous art of mobile wallet tokenized transactions, discloses:
…by a provider of a mobile device that is at least one of a manufacturer of a hardware of the mobile device or a developer of an operating system of the mobile device,… the proprietary token being proprietary to the mobile device based on at least one of the hardware or the operating system of the mobile device… (e.g. The mobile app may then send the user selection of the destination digital wallet to the system, for example Apple Pay, which may then requests the system to initiate the fund distribution process as described in FIG. 3. In this case, the system may prepare a virtual card token to be provisioned inside the user's Apple Pay account. For example, the system may connect to the issuing bank and/or the payment network to prepare and validate, for example, a token. Once the token for the virtual card is issued, it may be sent to the token provisioning system, for example, Apple Pay, to download the token to the user's digital wallet) (Section [0043]).
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 payment token of Lyman to include an apple pay token, as taught by Jain, in order to achieve the predictable result of increasing security and convenience for the user.
Note: applicant’s specification in section [0041] discloses that the proprietary token is a mobile device-based token that is provided by a provider associated with the mobile device. Examples of such proprietary tokens include, but are not limited to, an Apple Pay token, a Samsung Pay token, a Google Wallet token, and/or the like. Further, one of ordinary skill in the art before the effective filing date of the claimed invention would know that Apple manufacturers mobile devices and the mobile device operating system that uses Apple Pay to perform payment transactions using tokens. Therefore the provisioning of the Apple Pay token in Jain discloses the proprietary token being provided by a provider of the mobile device.
Although Lyman/Jain discloses a mobile device provider providing a proprietary token to a mobile device and then the provider of the proprietary token validating whether the proprietary token is valid, Lyman/Jain do not specifically disclose:
establish a wireless connection between a mobile device of a customer and a client computer used by the customer to perform the electronic commerce transaction using an internet browser;
receive, after the proprietary token has been provided by the provider, a retrieval request from the client computer via the wireless connection to provide the proprietary token of the mobile device that enables payment for the electronic commerce transaction;
transfer, the proprietary token from the mobile device to the client computer over the wireless connection to facilitate at least one electronic commerce transaction that includes the electronic commerce transaction.
However Hammad, in analogous art of wireless payments, discloses:
establish a wireless connection between a mobile device of a customer and a client computer used by the customer to perform the electronic commerce transaction using an internet browser (e.g. Action 151 comprises coupling a verification token, such as token 40, to a computer, such as computer 10, using a peripheral interface of the computer. Action 152 comprises displaying a merchant web page on the computer's display using an Internet browser, the merchant web page preferably being a checkout page for a transaction between the user and the merchant. Action 153 comprises presenting a portable consumer device 5 to the reader of the verification token to send identification information contained in device 5 to a merchant via validation entity 80. If device 5 has a magnetic stripe, action 153 may comprise swiping the magnetic stripe through a magnetic stripe reader of the verification token. If device 5 comprises a wireless communications interface, action 153 may comprise waving device 5 near the reader of verification token) (Section [0015]-[0016] and [0067]).
Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself that is in the substitution of the “client computer for online shopping” of Hammad for the “merchant POS computer for in person shopping” of Lyman/Jain. Both the client device of Hammad and the merchant POS device of Lyman are computing devices that are connected to a network and both devices receive wireless payment information when a user performs a transaction with a merchant. Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious.
Note: the limitation “used by the customer to perform an electronic commerce transaction using an internet browser” does not distinguish over the prior art because it is describing how the user is using the client computer and is not positively recited as a step of the method.
Although Lyman/Jain/Hammad discloses establishing a wireless connection between a user’s client computer and a user’s mobile device so that the user can send token information to perform a payment on the client computer, Hammad does not specifically disclose:
receive, after the proprietary token has been provided by the provider, a retrieval request from the client computer via the wireless connection to provide the proprietary token of the mobile device that enables payment for the electronic commerce transaction;
transfer, the proprietary token from the mobile device to the client computer over the wireless connection to facilitate at least one electronic commerce transaction that includes the electronic commerce transaction.
However Kumnick, in analogous art of payment tokens, discloses:
receive, after the proprietary token has been provided by the provider, a retrieval request from the client computer via the wireless connection to provide the proprietary token of the mobile device that enables payment for the electronic commerce transaction (e.g. The merchant 130 may then request that the consumer 120 provide payment information to conduct the purchase. Instead of providing a credit card number to the merchant 130, the consumer 120 can use a token to conduct the payment transaction. The consumer 120 may cause the token requestor 115 to request a token to conduct the transaction. In this example, the token requestor 115 may be the consumer's mobile phone or may be a digital wallet that is associated with the consumer's mobile phone) (Section [0079]);
transfer, the proprietary token from the mobile device to the client computer over the wireless connection to facilitate at least one electronic commerce transaction that includes the electronic commerce transaction (e.g. The token requestor 115 may provide the information to the consumer 120 (i.e., a payment device operated by the consumer 120), which may then provide the token and non-transactable payment account identifier to the merchant 130) (Section [0088] and [0089]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the token transaction system of Lyman/Jain/Hammad to include the retrieval request from the client computer, as taught by Kumnick, in order to achieve the predictable result of providing convenience to the user by informing them that a token can be sent to perform the payment.
Per claim 8, Lyman discloses:
a processor (e.g. Each of the servers, systems, and devices described above may be a physical computing device configured to provide the specified features. For example, in one embodiment, the configuration portal server 102 and/or the mobile wallet registry system 100 may be a server computer having a processor, a memory, a network controller, and a tangible computer readable storage medium) (Section [0027] and [0041]);
an operating system configured to operate on the processor… (e.g. In other embodiments, one or both of these components may be any other suitable computing device, such as a desktop computer, an embedded computing device, a cloud computing service executing on one or more server computers, a laptop computer, and/or the like. In one embodiment, each of the modules described herein includes computer executable instructions stored on a tangible computer readable medium that, in response to execution by a processor of a computing device, cause the computing device to perform the actions described as associated with the module) (Section [0027] and [0041]);
a secure storage (e.g. The token and associated policy setting information (where applicable) may be stored within the general memory of the mobile device 108, within a secure hardware element on the mobile device 108, or may be stored within the service application 107 or sponsor application 106) (Section [0049]);
a proprietary token of the provider stored on the secure storage… the proprietary token… provided for use on the mobile device by the provider… prior to the request to pay (e.g. The method 300 then proceeds to block 310, where the mobile device 108 receives and stores the token. In some embodiments, the token may be received directly from the mobile wallet registry system 100. In some embodiments, the token may be transmitted by the mobile wallet registry system 100 to the configuration portal server 102, and the configuration portal server 102 may transmit the token to the mobile device 108. In some embodiments, the mobile device 108 may also receive and store policy setting information, such as a time-to-live value for the token and/or the like, for future purchases. The token and associated policy setting information (where applicable) may be stored within the general memory of the mobile device 108, within a secure hardware element on the mobile device 108, or may be stored within the service application 107 or sponsor application 106) (Section [0023] and [0046]-[0049]);
…the proprietary token being stored on the mobile device prior to an initiation of the electronic commerce transaction (e.g. The method 300 then proceeds to block 310, where the mobile device 108 receives and stores the token. In some embodiments, the token may be received directly from the mobile wallet registry system 100. In some embodiments, the token may be transmitted by the mobile wallet registry system 100 to the configuration portal server 102, and the configuration portal server 102 may transmit the token to the mobile device 108. In some embodiments, the mobile device 108 may also receive and store policy setting information, such as a time-to-live value for the token and/or the like, for future purchases. The token and associated policy setting information (where applicable) may be stored within the general memory of the mobile device 108, within a secure hardware element on the mobile device 108, or may be stored within the service application 107 or sponsor application 106) (Section [0023] and [0046]-[0049]).
Although Lyman discloses a provider providing a proprietary token to a mobile device and determining whether the token is valid during a payment transaction at a merchant, Lyman does not specifically disclose:
…wherein at least one of the processor is manufactured by a provider or the operating system is developed by the provider;
the proprietary token being proprietary to the mobile device based on at least one of the hardware or the operating system of the mobile device and provided for use on the mobile device by the provider of the mobile device…;
a short-range wireless connection interface, the short-range wireless connection interface being configured to: establish a wireless connection between the mobile device of a customer and a client computer used by the customer to perform the electronic commerce transaction using an internet browser
receive a retrieval request from the client computer via the wireless connection to provide the proprietary token of the mobile device that enables payment for the electronic commerce transaction…;
transfer the proprietary token from the mobile device to the client computer over the wireless connection to facilitate at least one electronic commerce transaction that includes the electronic commerce transaction
However Jain, in analogous art of mobile wallet tokenized transactions, discloses:
…wherein at least one of the processor is manufactured by a provider or the operating system is developed by the provider (e.g. The mobile app may then send the user selection of the destination digital wallet to the system, for example Apple Pay, which may then requests the system to initiate the fund distribution process as described in FIG. 3. In this case, the system may prepare a virtual card token to be provisioned inside the user's Apple Pay account. For example, the system may connect to the issuing bank and/or the payment network to prepare and validate, for example, a token. Once the token for the virtual card is issued, it may be sent to the token provisioning system, for example, Apple Pay, to download the token to the user's digital wallet) (Section [0043]); Note: the limitation “wherein at least one of the processor is manufactured by a provider or the operating system is developed by the provider” does not distinguish over the prior art because it is describing the provider as being the manufacturer of the processor or the developer of the operating system. This does not affect the mobile device and its claimed functionality.
…by a provider of a mobile device that is at least one of a manufacturer of a hardware of the mobile device or a developer of an operating system of the mobile device,… the proprietary token being proprietary to the mobile device based on at least one of the hardware or the operating system of the mobile device… (e.g. The mobile app may then send the user selection of the destination digital wallet to the system, for example Apple Pay, which may then requests the system to initiate the fund distribution process as described in FIG. 3. In this case, the system may prepare a virtual card token to be provisioned inside the user's Apple Pay account. For example, the system may connect to the issuing bank and/or the payment network to prepare and validate, for example, a token. Once the token for the virtual card is issued, it may be sent to the token provisioning system, for example, Apple Pay, to download the token to the user's digital wallet) (Section [0043]).
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 payment token of Lyman to include an apple pay token, as taught by Jain, in order to achieve the predictable result of increasing security and convenience for the user.
Note: applicant’s specification in section [0041] discloses that the proprietary token is a mobile device-based token that is provided by a provider associated with the mobile device. Examples of such proprietary tokens include, but are not limited to, an Apple Pay token, a Samsung Pay token, a Google Wallet token, and/or the like. Further, one of ordinary skill in the art before the effective filing date of the claimed invention would know that Apple manufacturers mobile devices and the mobile device operating system that uses Apple Pay to perform payment transactions using tokens. Therefore the provisioning of the Apple Pay token in Jain discloses the proprietary token being provided by a provider of the mobile device.
Although Lyman/Jain discloses a mobile device provider providing a proprietary token to a mobile device and then the provider of the proprietary token validating whether the proprietary token is valid, Lyman/Jain do not specifically disclose:
a short-range wireless connection interface, the short-range wireless connection interface being configured to: establish a wireless connection between the mobile device of a customer and a client computer used by the customer to perform the electronic commerce transaction using an internet browser
receive a retrieval request from the client computer via the wireless connection to provide the proprietary token of the mobile device that enables payment for the electronic commerce transaction…;
transfer the proprietary token from the mobile device to the client computer over the wireless connection to facilitate at least one electronic commerce transaction that includes the electronic commerce transaction.
However Hammad, in analogous art of wireless payments, discloses:
a short-range wireless connection interface, the short-range wireless connection interface being configured to: establish a wireless connection between the mobile device of a customer and a client computer used by the customer to perform the electronic commerce transaction using an internet browser (e.g. Action 151 comprises coupling a verification token, such as token 40, to a computer, such as computer 10, using a peripheral interface of the computer. Action 152 comprises displaying a merchant web page on the computer's display using an Internet browser, the merchant web page preferably being a checkout page for a transaction between the user and the merchant. Action 153 comprises presenting a portable consumer device 5 to the reader of the verification token to send identification information contained in device 5 to a merchant via validation entity 80. If device 5 has a magnetic stripe, action 153 may comprise swiping the magnetic stripe through a magnetic stripe reader of the verification token. If device 5 comprises a wireless communications interface, action 153 may comprise waving device 5 near the reader of verification token) (Section [0015]-[0016] and [0067]).
Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself that is in the substitution of the “client computer for online shopping” of Hammad for the “merchant POS computer for in person shopping” of Lyman/Jain. Both the client device of Hammad and the merchant POS device of Lyman are computing devices that are connected to a network and both devices receive wireless payment information when a user performs a transaction with a merchant. Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious.
Note: the limitation “used by the customer to perform an electronic commerce transaction using an internet browser” does not distinguish over the prior art because it is describing how the user is using the client computer and is not positively recited as a function of the mobile device.
Although Lyman/Jain/Hammad discloses establishing a wireless connection between a user’s client computer and a user’s mobile device so that the user can send token information to perform a payment on the client computer, Lyman/Jain/Hammad does not specifically disclose:
receive a retrieval request from the client computer via the wireless connection to provide the proprietary token of the mobile device that enables payment for the electronic commerce transaction…;
transfer the proprietary token from the mobile device to the client computer over the wireless connection to facilitate at least one electronic commerce transaction that includes the electronic commerce transaction.
However Kumnick, in analogous art of payment tokens, discloses:
receive a retrieval request from the client computer via the wireless connection to provide the proprietary token of the mobile device that enables payment for the electronic commerce transaction… (e.g. The merchant 130 may then request that the consumer 120 provide payment information to conduct the purchase. Instead of providing a credit card number to the merchant 130, the consumer 120 can use a token to conduct the payment transaction. The consumer 120 may cause the token requestor 115 to request a token to conduct the transaction. In this example, the token requestor 115 may be the consumer's mobile phone or may be a digital wallet that is associated with the consumer's mobile phone) (Section [0079]);
transfer the proprietary token from the mobile device to the client computer over the wireless connection to facilitate at least one electronic commerce transaction that includes the electronic commerce transaction (e.g. The token requestor 115 may provide the information to the consumer 120 (i.e., a payment device operated by the consumer 120), which may then provide the token and non-transactable payment account identifier to the merchant 130) (Section [0088] and [0089]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the token transaction system of Lyman/Jain/Hammad to include the retrieval request from the client computer, as taught by Kumnick, in order to achieve the predictable result of providing convenience to the user by informing them that a token can be sent to perform the payment.
Per claim 14, Lyman discloses:
receive a proprietary token for use on the mobile device prior to an imitation of an e-commerce transaction… (e.g. The method 300 then proceeds to block 310, where the mobile device 108 receives and stores the token. In some embodiments, the token may be received directly from the mobile wallet registry system 100. In some embodiments, the token may be transmitted by the mobile wallet registry system 100 to the configuration portal server 102, and the configuration portal server 102 may transmit the token to the mobile device 108. In some embodiments, the mobile device 108 may also receive and store policy setting information, such as a time-to-live value for the token and/or the like, for future purchases. The token and associated policy setting information (where applicable) may be stored within the general memory of the mobile device 108, within a secure hardware element on the mobile device 108, or may be stored within the service application 107 or sponsor application 106) (Section [0023] and [0046]-[0049]).
Although Lyman discloses a provider providing a proprietary token to a mobile device and determining whether the token is valid during a payment transaction at a merchant, Lyman does not specifically disclose:
…provided by a provider that is at least one of a manufacturer of a hardware of the mobile device or a developer of an operating system of the mobile device, the proprietary token being proprietary to the mobile device based on at least one of the hardware or the operating system of the mobile device
establish a wireless connection between the mobile device of a customer and a client computer used by the customer to perform the electronic commerce transaction using an internet browser;
receive a retrieval request from the client computer via the wireless connection to provide the proprietary token of the mobile device that enables payment for the electronic commerce transaction;
transfer the proprietary token from the mobile device to the client computer over the wireless connection to facilitate at least one electronic commerce transaction that includes the electronic commerce transaction.
However Jain, in analogous art of mobile wallet tokenized transactions, discloses:
…provided by a provider that is at least one of a manufacturer of a hardware of the mobile device or a developer of an operating system of the mobile device, the proprietary token being proprietary to the mobile device based on at least one of the hardware or the operating system of the mobile device (e.g. The mobile app may then send the user selection of the destination digital wallet to the system, for example Apple Pay, which may then requests the system to initiate the fund distribution process as described in FIG. 3. In this case, the system may prepare a virtual card token to be provisioned inside the user's Apple Pay account. For example, the system may connect to the issuing bank and/or the payment network to prepare and validate, for example, a token. Once the token for the virtual card is issued, it may be sent to the token provisioning system, for example, Apple Pay, to download the token to the user's digital wallet) (Section [0043]). Note: the limitation “provider that is at least one of a manufacturer of a hardware of the mobile device or a developer of an operating system of the mobile device” does not distinguish over the prior art because it is describing the provider as being the manufacturer hardware or the developer of the operating system. This does not affect the mobile device and its claimed functionality.
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 payment token of Lyman to include an apple pay token, as taught by Jain, in order to achieve the predictable result of increasing security and convenience for the user.
Note: applicant’s specification in section [0041] discloses that the proprietary token is a mobile device-based token that is provided by a provider associated with the mobile device. Examples of such proprietary tokens include, but are not limited to, an Apple Pay token, a Samsung Pay token, a Google Wallet token, and/or the like. Further, one of ordinary skill in the art before the effective filing date of the claimed invention would know that Apple manufacturers mobile devices and the mobile device operating system that uses Apple Pay to perform payment transactions using tokens. Therefore the provisioning of the Apple Pay token in Jain discloses the proprietary token being provided by a provider of the mobile device.
Although Lyman/Jain discloses a mobile device provider providing a proprietary token to a mobile device and then the provider of the proprietary token validating whether the proprietary token is valid, Lyman/Jain do not specifically disclose:
establish a wireless connection between the mobile device of a customer and a client computer used by the customer to perform the electronic commerce transaction using an internet browser;
receive a retrieval request from the client computer via the wireless connection to provide the proprietary token of the mobile device that enables payment for the electronic commerce transaction;
transfer the proprietary token from the mobile device to the client computer over the wireless connection to facilitate at least one electronic commerce transaction that includes the electronic commerce transaction.
However Hammad, in analogous art of wireless payments, discloses:
establish a wireless connection between the mobile device of a customer and a client computer used by the customer to perform the electronic commerce transaction using an internet browser (e.g. Action 151 comprises coupling a verification token, such as token 40, to a computer, such as computer 10, using a peripheral interface of the computer. Action 152 comprises displaying a merchant web page on the computer's display using an Internet browser, the merchant web page preferably being a checkout page for a transaction between the user and the merchant. Action 153 comprises presenting a portable consumer device 5 to the reader of the verification token to send identification information contained in device 5 to a merchant via validation entity 80. If device 5 has a magnetic stripe, action 153 may comprise swiping the magnetic stripe through a magnetic stripe reader of the verification token. If device 5 comprises a wireless communications interface, action 153 may comprise waving device 5 near the reader of verification token) (Section [0015]-[0016] and [0067]).
Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself that is in the substitution of the “client computer for online shopping” of Hammad for the “merchant POS computer for in person shopping” of Lyman/Jain. Both the client device of Hammad and the merchant POS device of Lyman are computing devices that are connected to a network and both devices receive wireless payment information when a user performs a transaction with a merchant. Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious.
Note: the limitation “used by the customer to perform an electronic commerce transaction using an internet browser” does not distinguish over the prior art because it is describing how the user is using the client computer and is not positively recited as a function of the mobile device.
Although Lyman/Jain/Hammad discloses establishing a wireless connection between a user’s client computer and a user’s mobile device so that the user can send token information to perform a payment on the client computer, Lyman/Jain/Hammad does not specifically disclose:
receive a retrieval request from the client computer via the wireless connection to provide the proprietary token of the mobile device that enables payment for the electronic commerce transaction;
transfer the proprietary token from the mobile device to the client computer over the wireless connection to facilitate at least one electronic commerce transaction that includes the electronic commerce transaction.
However Kumnick, in analogous art of payment tokens, discloses:
receive a retrieval request from the client computer via the wireless connection to provide the proprietary token of the mobile device that enables payment for the electronic commerce transaction (e.g. The merchant 130 may then request that the consumer 120 provide payment information to conduct the purchase. Instead of providing a credit card number to the merchant 130, the consumer 120 can use a token to conduct the payment transaction. The consumer 120 may cause the token requestor 115 to request a token to conduct the transaction. In this example, the token requestor 115 may be the consumer's mobile phone or may be a digital wallet that is associated with the consumer's mobile phone) (Section [0079]);
transfer the proprietary token from the mobile device to the client computer over the wireless connection to facilitate at least one electronic commerce transaction that includes the electronic commerce transaction (e.g. The token requestor 115 may provide the information to the consumer 120 (i.e., a payment device operated by the consumer 120), which may then provide the token and non-transactable payment account identifier to the merchant 130) (Section [0088] and [0089]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the token transaction system of Lyman/Jain/Hammad to include the retrieval request from the client computer, as taught by Kumnick, in order to achieve the predictable result of providing convenience to the user by informing them that a token can be sent to perform the payment.
Per claims 2 and 15, Lyman/Jain/Hammad/Kumnick discloses all the limitations of claims 1 and 14 above. Lyman further discloses:
saving, by the provider, the proprietary token in a secure storage on the mobile device (e.g. The token and associated policy setting information (where applicable) may be stored within the general memory of the mobile device 108, within a secure hardware element on the mobile device 108, or may be stored within the service application 107 or sponsor application 106) (Section [0049]).
Per claims 3, 9, and 16, Lyman/Jain/Hammad/Kumnick discloses all the limitations of claims 1, 8, and 14 above. Kumnick further discloses:
wherein the transferring is performed in response to the receiving of the retrieval request associated with the transaction (e.g. The token requestor 115 may provide the information to the consumer 120 (i.e., a payment device operated by the consumer 120), which may then provide the token and non-transactable payment account identifier to the merchant 130) (Section [0079], [0088], and [0089]).
The motivation to combine Kumnick with Lyman/Jain/Hammad is disclosed above with reference to claims 1, 8, and 14.
Per claims 4, 10, and 17, Lyman/Jain/Hammad/Kumnick discloses all the limitations of claims 1, 8, and 14 above. Lyman further discloses:
receive the proprietary token provided by the provider at the mobile device (e.g. As before, the communication link between the mobile device 108 and the mobile wallet registry system or the configuration portal server 102 may be over any suitable communication medium, including a wireless communication network) (e.g. the method 300 then proceeds to block 310, where the mobile device 108 receives and stores the token. In some embodiments, the token may be received directly from the mobile wallet registry system 100. In some embodiments, the token may be transmitted by the mobile wallet registry system 100 to the configuration portal server 102, and the configuration portal server 102 may transmit the token to the mobile device 108) (Section [0047]-[0049])
wherein the wireless connection is a point to point connection that uses at least one of a Bluetooth protocol or Wi-Fi (e.g. At the merchant point-of-sale device 110, a token associated with a specific wallet ID and an enabled payment type stored in a sponsor wallet 104 is passed from the mobile device 108 to the merchant point-of-sale device 110 by any suitable method, such as via near-field communication methods (e.g., standard NFC or RFID), barcode scan, QR code scan, Bluetooth, WiFi, acoustic frequency tones, manual entry into an interface presented by the merchant point-of-sale device 110, internal communication between a shopping interface and an API provided by the merchant point-of-sale device 110, and/or the like) (Section [0035]).
Per claims 5, 11, and 18, Lyman/Jain/Hammad/Kumnick discloses all the limitations of claims 1, 8, and 14 above. Hammad further discloses:
wherein the propriety token contains encrypted information that enables the provider to retrieve credit card information associated with the customer (e.g. validation entity 80 may obtain a dynamic device verification value for the portable consumer device 5 as part of validating the device's identification information. For the sake of clarity, and without loss of generality, this device verification value is referred to as a "dCVV2" value, so as to distinguish it from the following: (1) the "CVC3" or "dCVV" values generated by smartcards (described above), (2) the printed CVV values found on the backs of credit cards, and (3) the CVV field found on the merchant's checkout page. The dCVV2 value comprises a variable datum (e.g., a multi-digit number), and can be used to complete the purchase transaction. Validation entity 80 may obtain the dCVV2 value by generating it from pre-stored data, or by receiving it from payment processing network 70 or issuing bank 60 in response to a request for it. If it did not receive the dCCV2 value from processing network 70, validation entity 80 provides the dCVV2 value to payment processing network 70, along with the identification information of device 5 so that network 70 can correlate the dCVV2 value to the user's account. Validation entity 80 also provides the dCVV2 value to one or both of merchant 20 and verification token 20) (Section [0048]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the proprietary token of Lyman/Jain/Kumnick to include encrypted information, as taught by Hammad, in order to achieve the predictable result of increasing the security of the payment transactions.
Per claims 6, 12, and 19, Lyman/Jain/Hammad/Kumnick discloses all the limitations of claims 1, 8, and 14 above. Jain further discloses:
wherein the proprietary token is at least one of an Apple Pay token, a Samsung Pay token, or a Google Wallet token (e.g. The mobile app may then send the user selection of the destination digital wallet to the system, for example Apple Pay, which may then requests the system to initiate the fund distribution process as described in FIG. 3. In this case, the system may prepare a virtual card token to be provisioned inside the user's Apple Pay account. For example, the system may connect to the issuing bank and/or the payment network to prepare and validate, for example, a token. Once the token for the virtual card is issued, it may be sent to the token provisioning system, for example, Apple Pay, to download the token to the user's digital wallet) (Section [0043]).
The motivation to combine Jain with Lyman/Hammad/Kumnick is disclosed above with reference to claims 1, 8, and 14.
Per claims 7, 13, and 20, Lyman/Jain/Hammad/Kumnick discloses all the limitations of claims 1, 8, and 14 above. Lyman further discloses:
transferring the proprietary token over the wireless connection to complete a subsequent electronic commerce transaction (e.g. Next, at block 404, the mobile device 108 presents the stored token and an indication of an associated payment type to a merchant point-of-sale device 110. In one embodiment, the token and indication of the associated payment type are presented via proximity-based communication, such as via a barcode displayed by the mobile device 108, a near-field communication method, and/or the like) (Section [0049] and [0051]).
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US Publication Number 20150154634 A1 to Chiu teaches a system and method that uses E-wallets such as Google Wallet and Apple Pay to perform payment transactions using NFC.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TIMOTHY P SAX whose telephone number is (571) 272-2935. The examiner can normally be reached on M-F 8-4:30.
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.
/TIMOTHY PAUL SAX/Examiner, Art Unit 3698
Prosecution Insights