DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on December 19, 2025 has been entered.
Response to Amendment
Applicant amended claims 1, 2, 4, 12, and 18.
Applicant cancelled claims 3 and 14.
Applicant added claims 21 and 22.
Claims 1, 2, 4-13, and 15-21 are pending and have been examined.
Response to Arguments
Applicant's arguments filed December 19, 2025 have been fully considered but they are not persuasive.
Regarding 101 Rejections
Examiner initially rejected claims 1-20 under 35 USC 101 as being directed to non-statutory subject matter.
Applicant argued that the claims do not recite an abstract idea because there are technical features. Examiner does not find this argument persuasive. Applicant merely alleges the claims do not recite an abstract idea and provides no analysis as to why the claims are not directed to Certain Methods of Organizing Human Activity. Merely having a different opinion as to how to describe the thrust of the claims does not change what the claims actually recite. Examiner identified the limitations which define the abstract idea and how they are directed to a commercial/legal interaction. Since they are a commercial/legal interaction the claims fall into the grouping of Certain Methods of Organizing Human Activity and therefore constitute an abstract idea (and thus a judicial exception). Furthermore, Applicant’s claims do not actually address a technical problem. Applicant is claiming an abstract idea of determining merchant identifiers/information and all that remains is the computer implementation of that idea. Having a computer implement the abstract idea does not change the abstract nature of the claims. Furthermore the basis of Examiner’s rejection is that the claims are directed to Certain Methods of Organizing Human Activity and recite commercial activity. The issue of whether this can be performed in the mind is not relevant to this rejection (as opposed to the basis being the claims recite a mental process). Applicant is using existing technology for its intended purpose.
Examiner maintains this rejection.
Regarding Prior Art Rejections
Examiner initially rejected claims 1-20 under 35 USC 103 as being unpatentable over the prior art.
Applicant argued that the cited art does not teach the limitations
“obtaining collection code information of the registered merchant;
converting the collection code information into a character string;
encrypting the character string to obtain encrypted character string information;
and storing the encrypted character string information as a device identifier of the registered merchant.”
formerly claim 3. Examiner does not find this argument persuasive. The cited portions of Philips does teach these limitations. Philips teaches reading a QR code and based on that QR code, displaying information related to a merchant. That information is reflective of collection code information of the registered merchant. Since that information is in the QR code, it must have been obtained and converted into a character string. Since that information is in the form of a QR code (as opposed to just being the information itself) it was encrypted into the form of a QR code. Finally, since the QR code is stored and acts as a device identifier of the registered merchant. The teachings of Philips teach these limitations.
Examiner maintains this rejection.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite the abstract idea which may be summarized as determining merchant identification information.
Step 1 Analysis
Applicants claims are directed to a process (claims 1-11), machine (claims 12-17), and manufacture/product (claims 18-20).
Step 2A, Prong 1 Analysis
Claims 1, 12 and 18 recite the abstract idea/limitations of:
registering a[n]… identifier of a registered merchant based on collection code information of a merchant,
the device identifier related to merchant identification information of the merchant;
obtaining at least one… identifier;
wherein the at least one… identifier has been automatically searched and found;
determining merchant identification information of at least one merchant corresponding to the at least one… identifier;
and sending the merchant identification information to a payment merchant selection interface
and causing the merchant identification information of the at least one merchant to be displayed on the payment merchant selection interface,
wherein the payment merchant selection interface enables a user of the user terminal to select a merchant of the at least one merchant for conducting a transaction
wherein the registering the… identifier of the registered merchant includes:
obtaining collection code information of the registered merchant;
converting the collection code information into a character string;
encrypting the character string to obtain encrypted character string information;
and storing the encrypted character string information as a[n]… identifier of the registered merchant.
As drafted these limitations are a process that falls within the “Certain Methods of Organizing Human Activity grouping of abstract ideas; but for the recitation of generic computer components. If a claim limitation, under its broadest reasonable interpretation, recites performance of the limitation as commercial/legal interactions then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. By reciting/claiming a certain method of organizing human activity, Applicant’s claims recite an abstract idea.
Step 2A, Prong 2 Analysis
This judicial exception is not integrated into a practical application because the claims only recites system components for implementing the abstract idea and extra-solution activity. The claims recite the additional limitations of a short-range communication channel, a user terminal, interface, a device, a non-transitory storage medium, computer executable instructions, one or more processors, a computer system, one or more storage devices, payment merchant selection interface, a short range communication; and they are recited at a high level of generality. These system components amount to no more than mere instructions to apply the exception using a generic computer. These limitations generally link the use of the judicial exception to a technological environment and are not indicative of integration into a practical application. The limitations of:
sending the merchant identification information
and causing the merchant identification information of the at least one merchant to be displayed
amount to insignificant extra-solution activity. These steps are mere sending and receiving of data, which courts have recognized as insignificant extra-solution activities see MPEP 2106.05(d)(II)(i). These additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims as a whole do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea without a practical application.
Step 2B Analysis
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of a short-range communication channel, a user terminal, interface, a device, a non-transitory storage medium, computer executable instructions, one or more processors, a computer system, one or more storage devices, payment merchant selection interface, a short range communication; amount to no more than mere components to implement the judicial exception using a generic computer components. For the same reason these elements are not sufficient to provide an inventive concept. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The limitations of:
sending the merchant identification information
and causing the merchant identification information of the at least one merchant to be displayed
amount to the sending and receiving data between devices, claimed at a high level of generality. These insignificant extra-solution activities are also well-understood, routine, and conventional as recognized by the federal courts See MPEP 2106.05(d)(II)(i). See also, Applicant’s specification paragraphs [0031], [0100-0114] about implementation of the abstract idea using general purpose or special purpose computing devices; and MPEP 2106.05(f) where applying a computer as a tool is not indicative of significantly more. Accordingly, these additional elements, when considered separately and as an ordered combination, do not amount to significantly more than the abstract idea because they do not impose any meaningful limits on practicing the abstract idea. Thus Applicant’s claims are not patent eligible.
Dependent Claims Analysis
As for dependent claims 4, 6-9, 11, 15, and 16 these claims recite limitations that further define the same abstract idea noted in independent claims 1 and 12. Therefore, claims 4, 6-9, 11, 15, and 16 are considered ineligible subject matter for the reasons given above.
As for dependent claims 2, 3, 5, 10, 13, 14, 17, 19, and 20 these claims recite limitations that further define the same abstract idea noted in independent claims 1, 12, and 18. In addition, the recite the additional elements of
sending a resource corresponding to the payment amount to an account corresponding to the collection account information
storing the encrypted character string information as [an]… identifier of the merchant
sending the name information of the merchant and the distance information of the merchant
sending sorted merchant identification information
sending a Bluetooth search enabling instruction
This is considered insignificant extra-solution activity, because as drafted the limitations are mere data gathering and storing of information. These limitations do not qualify as a practical application of the judicial exception or significantly more. See MPEP 2106.05(g). Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself. Therefore, claims 2, 3, 5, 10, 13, 14, 17, 19, and 20 are considered ineligible subject matter.
Thus, the dependent claims 2-11, 13-17, 19, and 20 are not patent-eligible either.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 USC 112(a) or 35 USC 112 first paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under pre-AIA 35 U.S.C. 103(a) are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 2, 4, 8-13, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Phillips, US Patent Application Publication No. 2014/0101036 in view of Proctor, US Patent Application Publication No. 2010/0063889.
Regarding claims 1, 12, and 18;
Phillips teaches
(Claim 1) An information display method, comprising:
registering a device identifier of a registered merchant based on collection code information of a merchant, the device identifier related to merchant identification information of the merchant;
See Phillips [0065] The user selects one or more items to purchase and the merchant website displays a code (such as a QR code or other identifier). At step "2" the user interacts with their mobile device 302 and launches a mobile application on the mobile device, and interacts with the mobile application to scan the QR code 334 or other identifier from the merchant website. The user may also be prompted to select a payment card or payment account for use in the transaction.
[0031] A first interaction (labeled as item "1") occurs between the merchant 206 and the mobile device 202 in which the merchant 206 provides the mobile device 202 with a transaction payload (with details of the transaction to be conducted). The transaction payload information may be provided in a number of different ways (including, for example, via a QR code, as HTML data, or the like). The transaction payload may include a number of data elements including, for example, a version identifier (identifying the implemented version of the transaction payload), a merchant identifier (assigned by the payment gateway to uniquely identify the merchant), a merchant name (a human readable name usable to display to the user), a payment gateway identifier (to uniquely identify the payment gateway associated with the merchant), a basket identifier (which may be a dynamic value or a static value in the case of a sticker or poster), and a security seal (which may be, for example, a result of a cryptographic computation using a key or information shared between the merchant and the payment gateway).
obtaining at least one device identifier of at least one device from a user terminal,
See Phillips [0065] At step "1" of FIG. 3, a consumer or user browses a merchant website 304 using a device other than the user's mobile device 302. The user selects one or more items to purchase and the merchant website displays a code (such as a QR code or other identifier). At step "2" the user interacts with their mobile device 302 and launches a mobile application on the mobile device, and interacts with the mobile application to scan the QR code 334 or other identifier from the merchant website. The user may also be prompted to select a payment card or payment account for use in the transaction.
[0101] While QR codes are described herein as mechanisms for transmitting transaction payload data from a merchant (or printed item, or the like) to a mobile device, embodiments may be used with similarly desirable results where the transaction payload data is provided to the mobile device in some other form, such as, for example, as data communicated over a near field communication ("NFC") interface. For example, the transaction payload may be encoded in an NFC tag or otherwise transmitted to the mobile device as an NFC message.
determining merchant identification information of at least one merchant corresponding to the at least one device identifier; and
See Phillips [0066] By capturing or reading the QR code 334 or other identifier, the mobile application is able to obtain merchant and transaction information in a transaction payload from the merchant website. For example, the transaction payload may include a merchant ID, a merchant name, a payment gateway ID, and a basket ID used to identify the user's item(s) to be purchased.
sending the merchant identification information to a payment merchant selection interface of the user terminal
See Phillips [0067] At step "3", the mobile application causes the mobile device 302 to establish a secure connection with the payment gateway identified by the payment gateway ID obtained in the transaction payload.
wherein the registering the device identifier of the registered merchant includes:
obtaining collection code information of the registered merchant; converting the collection code information into a character string; encrypting the character string to obtain encrypted character string information; and storing the encrypted character string information as a device identifier of the registered merchant.
See Phillips [0065] The user selects one or more items to purchase and the merchant website displays a code (such as a QR code or other identifier). At step "2" the user interacts with their mobile device 302 and launches a mobile application on the mobile device, and interacts with the mobile application to scan the QR code 334 or other identifier from the merchant website. The user may also be prompted to select a payment card or payment account for use in the transaction.
[0031] A first interaction (labeled as item "1") occurs between the merchant 206 and the mobile device 202 in which the merchant 206 provides the mobile device 202 with a transaction payload (with details of the transaction to be conducted). The transaction payload information may be provided in a number of different ways (including, for example, via a QR code, as HTML data, or the like). The transaction payload may include a number of data elements including, for example, a version identifier (identifying the implemented version of the transaction payload), a merchant identifier (assigned by the payment gateway to uniquely identify the merchant), a merchant name (a human readable name usable to display to the user), a payment gateway identifier (to uniquely identify the payment gateway associated with the merchant), a basket identifier (which may be a dynamic value or a static value in the case of a sticker or poster), and a security seal (which may be, for example, a result of a cryptographic computation using a key or information shared between the merchant and the payment gateway).
Phillips does not teach
wherein the at least one device identifier has been automatically searched through a short range communication channel and found as within a short range communication search range of the user terminal;
and causing the merchant identification information of the at least one merchant to be displayed on the payment merchant selection interface of the user terminal,
wherein the payment merchant selection interface enables a user of the user terminal to select a merchant of the at least one merchant for conducting a transaction.
Proctor teaches
wherein the at least one device identifier has been automatically searched through a short range communication channel and found as within a short range communication search range of the user terminal;
See Proctor [0068] Using the present invention, the club member would have a wireless device that serves as the "Consumer device" (Device 1) and the ZipCar vehicle would be equipped with a wireless device serving as the "Merchant" device (Device 2). The consumer would walk up to an available ZipCar vehicle and, using their wireless device, start an initial exchange of identifiers with the desired Merchant device, for example, using the short range local wireless network. The Consumer device and/or Merchant device would send a message to an application running on the Server requesting that a person associated with an account for the Consumer be granted access to a specific vehicle (e.g., an "object") that is in the vicinity of and associated with the Merchant device. A set of confirmatory messages (such as to exchange access codes, to confirm the location of the vehicle, the per-use fee due, and payment for the same, etc.), are then typically also exchanged between the Consumer and the Merchant device with the assistance of the Server and the long range wireless network. Upon confirmation of the necessary transaction information, the Server sends a message to the Merchant device to unlock the vehicle requested (which may be sent over the second long range wireless network or a yet another network, such as a satellite network).
[0063] In this case the input selection would be "search for merchants." The customer's device would then send a message (809) to the central server directing the server to perform a one time search for merchants, despite the current account settings. In one embodiment, the server would then direct the consumer's device 802 to initiate another search (809). Other embodiments may not include the server commanding Device 1 (802) to perform the search, but rather the search may be performed automatically, or use results from a recent search.
and causing the merchant identification information of the at least one merchant to be displayed on the payment merchant selection interface of the user terminal,
See Proctor [0063] The server then sends a message 814 to Device 1 (802) stating merchant services are available in proximity with a list of available merchant's information including information related to the entity (EI2). The user of device 1, Entity 1 (EI1) then provides input in step 815, (pressing a soft key on a touch screen for instance), selecting the specific merchant EI2 to engage with in a transaction.
wherein the payment merchant selection interface enables a user of the user terminal to select a merchant of the at least one merchant for conducting a transaction.
See Proctor [0063] The server then sends a message 814 to Device 1 (802) stating merchant services are available in proximity with a list of available merchant's information including information related to the entity (EI2). The user of device 1, Entity 1 (EI1) then provides input in step 815, (pressing a soft key on a touch screen for instance), selecting the specific merchant EI2 to engage with in a transaction.
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the merchant information of the primary reference, the ability to automatically search for the information and display the selectable merchants as taught by Proctor since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes automatically searching for merchants and displaying them allows for an easier selection.
Regarding claims 2, 13, and 19;
(Claim 2) The method according to claim 1, further comprising:
after the sending the merchant identification information to the payment merchant selection interface of the user terminal for display,
See Phillips [0066] By capturing or reading the QR code 334 or other identifier, the mobile application is able to obtain merchant and transaction information in a transaction payload from the merchant website. For example, the transaction payload may include a merchant ID, a merchant name, a payment gateway ID, and a basket ID used to identify the user's item(s) to be purchased.
[0067] At step "3", the mobile application causes the mobile device 302 to establish a secure connection with the payment gateway identified by the payment gateway ID obtained in the transaction payload.
obtaining merchant identification information of a target merchant from the user terminal, wherein the target merchant is a merchant corresponding to merchant identification information displayed in the payment merchant selection interface of the user terminal and selected to make a payment;
See Phillips [0067] At step "3", the mobile application causes the mobile device 302 to establish a secure connection with the payment gateway identified by the payment gateway ID obtained in the transaction payload. In the secure connection, the mobile application provides the payment gateway with the basket ID and information associated with the mobile application. The payment gateway 310 then establishes communication with the merchant 306 and obtains item details from the basket associated with the basket ID. The item(s) from the basket from the merchant website 306 may be displayed on a display of the mobile device 302 at step "4" for the user to view.
determining collection account information corresponding to the merchant identification information of the target merchant based on the merchant identification information of the target merchant;
See Phillips [0031] Reference is now made to FIG. 2B, where a further block diagram is provided which shows the transfer of data in a transaction 250 involving a number of communication paths or interactions pursuant to the present invention. A first interaction (labeled as item "1") occurs between the merchant 206 and the mobile device 202 in which the merchant 206 provides the mobile device 202 with a transaction payload (with details of the transaction to be conducted). The transaction payload information may be provided in a number of different ways (including, for example, via a QR code, as HTML data, or the like). The transaction payload may include a number of data elements including, for example, a version identifier (identifying the implemented version of the transaction payload), a merchant identifier (assigned by the payment gateway to uniquely identify the merchant), a merchant name (a human readable name usable to display to the user), a payment gateway identifier (to uniquely identify the payment gateway associated with the merchant), a basket identifier (which may be a dynamic value or a static value in the case of a sticker or poster), and a security seal (which may be, for example, a result of a cryptographic computation using a key or information shared between the merchant and the payment gateway). In some embodiments, a static flag may also be used. The static flag may be a merchant's unique static product(s)/service(s) identifier for use in static QR codes such as, for example, posters, flyers or other materials. The transaction payload may also include other optional data elements including, for example, a timestamp, one or more extensions or the like. This transaction payload information is used to deliver certain transaction details to other participants in a transaction as will be described further herein.
obtaining payment information from the user terminal, wherein the payment information includes a payment amount; and
See Phillips [0034] A fourth interaction (labeled as item "4") occurs between the merchant 206 and the payment gateway 210, where the merchant 206 validates the basket ID received in message or interaction "3", and uses the basket ID to lookup details of the transaction. The transaction details are then returned to the payment gateway 210 and may include, for example, the basket ID, a transaction amount, the relevant currency, etc
sending a resource corresponding to the payment amount to an account corresponding to the collection account information.
See Phillips [0068] At step "5", the merchant 306 provides the payment gateway 310 and the mobile application on the mobile device 302 with a request to select a shipping address (if the item(s) in the basket require shipping). In some embodiments, the user may configure one or more default or stored shipping preferences, and those stored shipping preferences may be displayed to the user on the display screen of the mobile device for confirmation. The user may also be provided with the option to enter a new or different shipping address by interacting with the mobile application on the mobile device 302. The shipping selection (if required) is then provided to the payment gateway 310 for use in the transaction. At "6", the user may be prompted to select a payment source. In some embodiments, a secure element of the mobile device 302 may be personalized or configured with payment credentials (including PAN, expiry, CVV or the like) for one or more payment accounts, and at "6", the user may be presented with an option to select which of the available payment accounts to use in the transaction. At "7" the mobile application may prompt the user to enter cardholder verification data (such as a PIN or password) if the selected payment account requires such cardholder verification. The user then submits the transaction for approval processing by the payment gateway. At "8", the mobile application of the mobile device 302 may receive a confirmation of the completion of the transaction. At "9", the merchant website may receive an update of the confirmation of the transaction. In this manner, embodiments allow secure payment transactions to be completed in online transactions using a mobile payment device storing payment credentials of a user. In some embodiments, the payment may be performed using in accordance with the EMV standards or other payment standards, allowing secure "card present" types of transactions to be conducted. In some embodiments, depending on the merchant implementation, such transactions may be used to allow a single click style of purchase of an individual product. Embodiments provide a clean separation of authentication and payment such that embodiments may support remote authentication. Further, the payment might be completed separately using some other means, such as a through the use of cloud-based payment credentials.
Regarding claim 20;
(Claim 3) The method according to claim 1, wherein the at least one device identifier is obtained through conversion based on a collection two-dimensional code of a merchant; and
See Phillips [0065] The user selects one or more items to purchase and the merchant website displays a code (such as a QR code or other identifier). At step "2" the user interacts with their mobile device 302 and launches a mobile application on the mobile device, and interacts with the mobile application to scan the QR code 334 or other identifier from the merchant website. The user may also be prompted to select a payment card or payment account for use in the transaction.
before the obtaining the at least one device identifier through the short-range communication from the user terminal, the method further comprises:
obtaining collection code information of the merchant; converting the collection code information into a character string; encrypting the character string to obtain encrypted character string information; and storing the encrypted character string information as a device identifier of the merchant.
See Phillips [0065] The user selects one or more items to purchase and the merchant website displays a code (such as a QR code or other identifier). At step "2" the user interacts with their mobile device 302 and launches a mobile application on the mobile device, and interacts with the mobile application to scan the QR code 334 or other identifier from the merchant website. The user may also be prompted to select a payment card or payment account for use in the transaction.
[0031] A first interaction (labeled as item "1") occurs between the merchant 206 and the mobile device 202 in which the merchant 206 provides the mobile device 202 with a transaction payload (with details of the transaction to be conducted). The transaction payload information may be provided in a number of different ways (including, for example, via a QR code, as HTML data, or the like). The transaction payload may include a number of data elements including, for example, a version identifier (identifying the implemented version of the transaction payload), a merchant identifier (assigned by the payment gateway to uniquely identify the merchant), a merchant name (a human readable name usable to display to the user), a payment gateway identifier (to uniquely identify the payment gateway associated with the merchant), a basket identifier (which may be a dynamic value or a static value in the case of a sticker or poster), and a security seal (which may be, for example, a result of a cryptographic computation using a key or information shared between the merchant and the payment gateway).
Regarding claim 4;
The method according to claim 1, further comprising:
for a merchant that has completed a merchant registration service, obtaining a short range communication payment enabling operation performed by the merchant; and
See Phillips [0101] While QR codes are described herein as mechanisms for transmitting transaction payload data from a merchant (or printed item, or the like) to a mobile device, embodiments may be used with similarly desirable results where the transaction payload data is provided to the mobile device in some other form, such as, for example, as data communicated over a near field communication ("NFC") interface. For example, the transaction payload may be encoded in an NFC tag or otherwise transmitted to the mobile device as an NFC message.
enabling a short range communication payment service for the merchant based on the short range communication payment enabling operation.
See Phillips [0101] While QR codes are described herein as mechanisms for transmitting transaction payload data from a merchant (or printed item, or the like) to a mobile device, embodiments may be used with similarly desirable results where the transaction payload data is provided to the mobile device in some other form, such as, for example, as data communicated over a near field communication ("NFC") interface. For example, the transaction payload may be encoded in an NFC tag or otherwise transmitted to the mobile device as an NFC message.
[0065] At step "1" of FIG. 3, a consumer or user browses a merchant website 304 using a device other than the user's mobile device 302. The user selects one or more items to purchase and the merchant website displays a code (such as a QR code or other identifier). At step "2" the user interacts with their mobile device 302 and launches a mobile application on the mobile device, and interacts with the mobile application to scan the QR code 334 or other identifier from the merchant website. The user may also be prompted to select a payment card or payment account for use in the transaction.
Regarding claims 8 and 15;
(Claim 8) The method according to claim 1, wherein the determining the merchant identification information corresponding to the at least one device identifier includes:
obtaining a pre-stored correspondence between a device identifier and merchant identification information; and
See Phillips [0065] The user selects one or more items to purchase and the merchant website displays a code (such as a QR code or other identifier). At step "2" the user interacts with their mobile device 302 and launches a mobile application on the mobile device, and interacts with the mobile application to scan the QR code 334 or other identifier from the merchant website. The user may also be prompted to select a payment card or payment account for use in the transaction.
[0031] A first interaction (labeled as item "1") occurs between the merchant 206 and the mobile device 202 in which the merchant 206 provides the mobile device 202 with a transaction payload (with details of the transaction to be conducted). The transaction payload information may be provided in a number of different ways (including, for example, via a QR code, as HTML data, or the like). The transaction payload may include a number of data elements including, for example, a version identifier (identifying the implemented version of the transaction payload), a merchant identifier (assigned by the payment gateway to uniquely identify the merchant), a merchant name (a human readable name usable to display to the user), a payment gateway identifier (to uniquely identify the payment gateway associated with the merchant), a basket identifier (which may be a dynamic value or a static value in the case of a sticker or poster), and a security seal (which may be, for example, a result of a cryptographic computation using a key or information shared between the merchant and the payment gateway).
determining the merchant identification information corresponding to the at least one device identifier based on the pre-stored correspondence.
See Phillips See Phillips [0066] By capturing or reading the QR code 334 or other identifier, the mobile application is able to obtain merchant and transaction information in a transaction payload from the merchant website. For example, the transaction payload may include a merchant ID, a merchant name, a payment gateway ID, and a basket ID used to identify the user's item(s) to be purchased.
[0065] The user selects one or more items to purchase and the merchant website displays a code (such as a QR code or other identifier). At step "2" the user interacts with their mobile device 302 and launches a mobile application on the mobile device, and interacts with the mobile application to scan the QR code 334 or other identifier from the merchant website. The user may also be prompted to select a payment card or payment account for use in the transaction.
Regarding claims 9 and 16;
(Claim 9) The method according to claim 1, wherein the determining the merchant identification information corresponding to the at least one device identifier includes:
parsing a character string corresponding to a device identifier of the at least one device identifier to determine merchant identification information included in the character string.
See Phillips See Phillips [0066] By capturing or reading the QR code 334 or other identifier, the mobile application is able to obtain merchant and transaction information in a transaction payload from the merchant website. For example, the transaction payload may include a merchant ID, a merchant name, a payment gateway ID, and a basket ID used to identify the user's item(s) to be purchased.
[0065] The user selects one or more items to purchase and the merchant website displays a code (such as a QR code or other identifier). At step "2" the user interacts with their mobile device 302 and launches a mobile application on the mobile device, and interacts with the mobile application to scan the QR code 334 or other identifier from the merchant website. The user may also be prompted to select a payment card or payment account for use in the transaction.
Regarding claims 10 and 17;
(Claim 10) The method according to claim 1, further comprising:
obtaining access information of the user terminal for a target application; and
sending a short range communication search enabling instruction to the user terminal based on the access information.
See Phillips [0065] At step "1" of FIG. 3, a consumer or user browses a merchant website 304 using a device other than the user's mobile device 302. The user selects one or more items to purchase and the merchant website displays a code (such as a QR code or other identifier). At step "2" the user interacts with their mobile device 302 and launches a mobile application on the mobile device, and interacts with the mobile application to scan the QR code 334 or other identifier from the merchant website. The user may also be prompted to select a payment card or payment account for use in the transaction.
[0101] While QR codes are described herein as mechanisms for transmitting transaction payload data from a merchant (or printed item, or the like) to a mobile device, embodiments may be used with similarly desirable results where the transaction payload data is provided to the mobile device in some other form, such as, for example, as data communicated over a near field communication ("NFC") interface. For example, the transaction payload may be encoded in an NFC tag or otherwise transmitted to the mobile device as an NFC message.
Regarding claim 11;
The method according to claim 1, wherein the payment merchant selection interface is configured to display the merchant identification information for a user selection with respect to a payment.
See Phillips [0066] By capturing or reading the QR code 334 or other identifier, the mobile application is able to obtain merchant and transaction information in a transaction payload from the merchant website. For example, the transaction payload may include a merchant ID, a merchant name, a payment gateway ID, and a basket ID used to identify the user's item(s) to be purchased.
[0067] At step "3", the mobile application causes the mobile device 302 to establish a secure connection with the payment gateway identified by the payment gateway ID obtained in the transaction payload. In the secure connection, the mobile application provides the payment gateway with the basket ID and information associated with the mobile application. The payment gateway 310 then establishes communication with the merchant 306 and obtains item details from the basket associated with the basket ID. The item(s) from the basket from the merchant website 306 may be displayed on a display of the mobile device 302 at step "4" for the user to view.
Claims 5-7, 21 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Phillips in view of Proctor as applied to claims 1-4 and 8-20 above, and further in view of Chen, US Patent Application Publication No 2014/0330628.
Regarding claim 5 and 21;
Phillips teaches
(Claim 5) The method according to claim 1, wherein the merchant identification information includes name information of a merchant…;
See Phillips [0031] The transaction payload may include a number of data elements including, for example, a version identifier (identifying the implemented version of the transaction payload), a merchant identifier (assigned by the payment gateway to uniquely identify the merchant), a merchant name (a human readable name usable to display to the user), a payment gateway identifier (to uniquely identify the payment gateway associated with the merchant), a basket identifier (which may be a dynamic value or a static value in the case of a sticker or poster), and a security seal (which may be, for example, a result of a cryptographic computation using a key or information shared between the merchant and the payment gateway).
and the sending the merchant identification information to the user terminal for display includes:
sending the name information of the merchant… to the user terminal for display.
See Phillips [0067] At step "3", the mobile application causes the mobile device 302 to establish a secure connection with the payment gateway identified by the payment gateway ID obtained in the transaction payload. In the secure connection, the mobile application provides the payment gateway with the basket ID and information associated with the mobile application. The payment gateway 310 then establishes communication with the merchant 306 and obtains item details from the basket associated with the basket ID. The item(s) from the basket from the merchant website 306 may be displayed on a display of the mobile device 302 at step "4" for the user to view.
Phillips does not teach
The method according to claim 1, wherein the merchant identification information includes… distance information of the merchant;
sending… the distance information of the merchant to the user terminal for display.
Chen teaches
The method according to claim 1, wherein the merchant identification information includes… distance information of the merchant; and sending… the distance information of the merchant to the user terminal for display.
See Chen [0045] The graphical user interface 300 shows at least one promotional offer 302, and preferably a list of promotional offers 302. Each promotional offer 302 includes one or more of the following: name of business, picture (such as logo or product view), address, type of business, price range, ranking, distance between current buyer's location and the seller's location, available promotional offers on specific date, etc. The graphical user interface 300 may also include clickable targets 304 to buyer's settings, previously selected promotional offers, other promotional offers, map, data changing, and any other features.
[0040] A seller, with the help of the seller's user device 106, may upload information regarding promotional offers to the database 204 via the web server 202. The seller may also establish new promotional offers, manage, and cancel existing promotional offers, determine rewarding methods and other criteria. The seller may also register and establish a personal account (profile) at the database 204, which may include such information as name of business, type of business, address, contact information, available promotional offers, ratings, rankings, commentary of users, etc.
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the merchant information of the primary reference, the ability to include location data as taught by Chen since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes including location data allow for location based services to be provided.
Regarding claim 6 and 22;
Phillips does not teach the claim
Chen teaches
(Claim 6) The method according to claim 5, wherein the sending the name information of the merchant and the distance information of the merchant to the user terminal for display includes: sorting merchant identification information based on the distance information; and
sending sorted merchant identification information to the user terminal for display.
See Chen (Claim 5). The method of claim 4, wherein the plurality of promotional offers comprises a second promotional offer, the method further comprising: determining a location of the mobile device; determining a first location of a first merchant associated with the first promotional offer; determining a second location of a second merchant associated with the second promotional offer; determining a first distance between the mobile device and the first merchant based on the location of the mobile device and the first location of the first merchant; and determining a second distance between the mobile device and the second merchant based on the location of the mobile device and the second location of the second merchant, wherein the sorting is based at least in part on the first distance and the second distance.
[0046] According to the exemplary embodiment, the graphical user interface 300 shows a list of promotional offers 302 available on current date and sorted by distance between the buyer and corresponding seller (displaying the nearest seller first). In other embodiments, the graphical user interface 300 shows first featured promotional offers 302.
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the merchant information of the primary reference, the ability to include location data as taught by Chen since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes including location data allow for location based services to be provided.
Regarding claim 7;
Phillips does not teach the claim
Chen teaches
The method according to claim 5, wherein the distance information of the merchant indicates a distance between the merchant and the user terminal;
See Chen [0043] According to the exemplary embodiment, distance between the current location of the buyer's user device 104 and the seller's address can be calculated based on location information determined through the GPS receiver, or data received from the base stations of the cellular network, or IP address obtained from the access point providing cable or wireless connection to the user device 104, or a combination thereof. Those who are skilled in the art can readily understand that any other appropriate way of determining current location of the buyer's user device 104 can be used.
and before the sending the name information of the merchant and the distance information of the merchant to the user terminal for display, the method further comprises:
obtaining first location coordinate information of the user terminal that is uploaded by the user terminal; obtaining second location coordinate information of the merchant that is uploaded by the merchant; and calculating the distance between the merchant and the user terminal based on the first location coordinate information and the second location coordinate information, to obtain the distance information of the merchant.
See Chen [0043] According to the exemplary embodiment, distance between the current location of the buyer's user device 104 and the seller's address can be calculated based on location information determined through the GPS receiver, or data received from the base stations of the cellular network, or IP address obtained from the access point providing cable or wireless connection to the user device 104, or a combination thereof. Those who are skilled in the art can readily understand that any other appropriate way of determining current location of the buyer's user device 104 can be used
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the merchant information of the primary reference, the ability to include location data as taught by Chen since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes including location data allow for location based services to be provided.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J WARDEN whose telephone number is (571)272-9602. The examiner can normally be reached M-F; 9-6 CDT.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett M Sigmond can be reached at 303-297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL J. WARDEN/
Examiner
Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694