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 8/27/2025.
Claims
Claims 1, 8, 10, and 14 have been amended.
Claims 1-20 are currently pending in the application.
Response to Arguments
103
The applicant argues that the combination of Hammad/Kumnick/Lyman fails to teach or suggest “providing, 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, a proprietary token for use on a 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 the request to pay”, “receiving, by the provider, a request for a determination as to whether the proprietary token is valid”, and “making, by the provider, the determination as to whether the proprietary token is valid” of claim 1. Further the applicant argues that description of the provider and the proprietary token should be given patentable weight. (see applicant’s arguments/remarks pages 11-13).
The examiner respectfully disagrees. 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” is describing the provider and the limitation “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”. The description of the provider and the token does not affect the steps in the claim (e.g. providing a proprietary token, establish a wireless connection, receive a retrieval request, transfer the proprietary token, receiving a request, and making the determination) and therefore does not distinguish over the prior art. The claims recite that the provider provides a token to the mobile device prior to the request to pay and then the same provider receives a request to determine whether the token is valid. This is taught by Lyman. Lyman in sections [0023] and [0046]-[0049] discloses that the mobile wallet registry system (e.g. provider) provides a token to the mobile device, prior to the request to pay, and the mobile device stores the token for future purchases. Lyman further teaches in sections [0052]-[0053] that the mobile wallet registry system validates the token that it provided to the mobile device when the mobile device is performing a payment with the token. Therefore Lyman teaches these limitation as written.
Further, the applicant argues that the limitation “used by a customer to perform an electronic commerce transaction using an internet browser” of claim 1 should be given patentable weight. (see applicant’s arguments/remarks pages 13-14).
The examiner respectfully disagrees. The limitation “establish a wireless connection between a mobile device of a customer and a client computer used by the customer to perform an electronic commerce transaction using an internet browser” positively recites that a wireless connection between a mobile device of a customer and a client computer is established. The limitation “used by a customer to perform an electronic commerce transaction using an internet browser” is describing how the user is using the client computer and is not positively recited as a step of the method. Even assuming that the description of the user using the client computer does hold patentable weight, Hammad teaches this in sections [0015]-[0016] and [0067]. Here Hammad discloses a computer that displays an internet browser that the user uses to checkout on a merchant web page. A user’s portable consumer device is then used to wirelessly communicate transaction information to the computer so that the user can pay for the items on the website.
Furthermore, the applicant argues that the combination of Hammad/Kumnick/Lyman fails to teach or suggest “a proprietary token of the provider stored on the secure storage, 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 prior to the request to pay” of claim 8. (See applicant’s arguments/remarks pages 14-15).
The examiner respectfully disagrees for the same reasons discussed above in response to the arguments of claim 1.
Furthermore, the applicant argues that the combination of Hammad/Kumnick/Lyman fails to teach or suggest “receive a proprietary token for use on the mobile device prior to an initiation of an e-commerce transaction provided by the 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” of claim 14. (See applicant’s arguments/remarks page 15).
The examiner respectfully disagrees for the same reasons discussed above in response to the arguments of claim 1.
Furthermore, the applicant argues that the combination of Hammad/Kumnick/Lyman/Chiu fails to teach or suggest “wherein the proprietary token is at least one of an Apple Pay token, a Samsung Pay token, or a Google Wallet token” of claims 6, 12, and 19. (See applicant’s arguments/remarks pages 16-17).
The examiner respectfully disagrees. Hammad in sections [0015]-[0016] and [0067 discloses that a user device can wirelessly send token information for a transaction to a user’s client device when the user is performing a transaction on a website using their client device. Chiu is used to disclose that the payment information for the wireless payment transaction can be payment information using Google Wallet or Apple Pay (see Chiu in section [0035]). One of ordinary skill in the art at the time the application was filed understands that both Google Wallet and Apple Pay use tokenization for secure payment transactions. This is supported by applicant’s own specification in section [0041] which recites “Examples of such proprietary token 86 include, but are not limited to, an Apple Pay® token (Apple Pay is a registered trademark of Apple Computer, Inc.), a Samsung Pay® token (Samsung Pay is a registered trademark of Samsung, Inc.), a Google Wallet® token (Goggle Wallet is a registered trademark of Google, Inc.), and/or the like)”.
The examiner has considered all of the applicant’s arguments but maintains the 103 rejection.
112
The previous 112(b) rejections have been withdrawn due to the claim amendments.
Claim Objections
Claims 6, 12, and 19 are objected to because of the following informalities:
In claims 6, 12, and 19, “propriety” should read “proprietary”.
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 10 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(s) 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 pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 10 recites “the short-range wireless connection interface being configured to: receive the proprietary token provided by the provider at the mobile device”. The specification fails to disclose the algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed function in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor invented the claimed subject matter. As such, there is no description as to how this is achieved. See Ariad Pharmaceuticals Inc. v. Eli Lilly & Co., 94 USPQ2d 1161 (Fed. Cir. 2010).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention. In this instant case,
Claim 1 recites “providing, 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, a proprietary token for use on a 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 the request to pay, wherein the mobile device is configured to:” (emphasis added). There is a lack of antecedent basis for “the mobile device” in the claim. Further, there is a lack of antecedent basis for “the request to pay” in the claim.
Further, claims 2-7 are rejected as being dependent on claim 1 above.
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-5, 7-11, 13-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20130110658 A1 (“Lyman”) and US 20100327054 A1 (“Hammad”) and US 20150199689 A1 (“Kumnick”).
Per claim 1, Lyman discloses:
providing, 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, a proprietary token for use on a 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 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.
Note: the limitation “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” does not distinguish over the prior art because it is describing the proprietary token and is not positively recited as a step of the method. The description of the proprietary token 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:
establish a wireless connection between a mobile device of a customer and a client computer used by the customer to perform an 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 an 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. 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/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/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, wherein at least one of the processor is manufactured by a provider or the operating system is developed by the provider (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 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 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]).
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.
Note: the limitation “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” does not distinguish over the prior art because it is describing the proprietary token and the actions being performed by the provider which is outside the scope of the claim that is directed to a mobile device. The description of the proprietary token does not affect the claimed mobile device or its functionality.
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:
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. 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/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/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/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 provided by the 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 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]);
Note: the limitation “the 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 of the processor or the developer of the operating system. This does not affect the mobile device and its claimed functionality.
Note: the limitation “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” does not distinguish over the prior art because it is describing the proprietary token. The description of the proprietary token does not affect the claimed mobile device or its functionality.
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:
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. 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/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/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/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/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/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/Hammad is disclosed above with reference to claims 1, 8, and 14.
Per claims 4, 10, and 17, Lyman/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/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/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 7, 13, and 20, Lyman/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]).
Claims 6, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lyman/Hammad/Kumnick, as applied to claims 1, 8, and 14 above, in further view of US 20150154634 A1 (“Chiu”).
Per claims 6, 12, and 19, Although Lyman/Hammad/Kumnick disclose the use of tokens to perform payment transactions between a user device and client when using a web browser to purchase items on a client website, Lyman/Hammad/Kumnick do not specifically disclose:
wherein the proprietary token is at least one of an Apple Pay token, a Samsung Pay token, or a Google Wallet token.
However Chiu, in analogous art of mobile wallet payments, 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. In one embodiment, the NFC device may read mobile payment information from a mobile device that is equipped with NFC technology. For example, NFC device may process payment transactions using Google Wallet, Square Wallet, and/or payment accounts such as PayPal and/or Alipay on the mobile terminal of the customer) (Section [0035]).
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 payment token of Lyman/Hammad/Kumnick to be that of Apple Pay, Samsung Pay, or Google Wallet, as taught by Chiu, in order to achieve the predictable result of providing convenience to the user by allowing the tokens to be used with more vendors who are already compatible with the payment systems of Apple, Samsung, and Google.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 extension fee 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 date of this final action.
Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to TIMOTHY SAX whose telephone number is 571-272-2935. The Examiner can normally be reached on M-F 8-4:30. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575.
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.
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.
/TS/
Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698