DETAILED ACTION
This action is responsive to Request for Continued Examination filed on August 21, 2026.
Amendments filed on August 21, 2026, have been acknowledged and considered.
Claims 1, 3, 9-11, 15 and 21 have been amended. Claims 6 and 16 were previously canceled.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 August 21, 2026, has been entered.
Response to Amendment
Applicant’s Remarks, filed August 21, 2026, has been fully considered and entered. Accordingly, Claims 1, 3, 9-11, 15 and 21 have been amended. Claim 6 and 16 were previously canceled. Claims 1, 10 and 15 are independent claim. Claims 1-5, 7-15 and 17-22 are pending in this application.
Response to Arguments
Applicant’s arguments, see pages 9-16, filed August 21, 2026, with respect to the
rejection of claims 1, 10 and 15 have been fully considered, but they are not persuasive.
Argument 1: Applicant argues on the Applicant Arguments and Remarks on pages 11-13: “the combination of references fails to teach or suggest features to “receive input data” including “an indication that the non-transacting remote device chooses not to perform the data transaction” and “a request to complete the data transaction with the service provider, on behalf of the non-transacting remote device, using the digital image”, as recited in amended claim 1.”
Response to Argument 1: Examiner respectfully disagree. Regarding to “an indication that the non-transacting remote device chooses not to perform the data transaction”, Makhdumi alone teaches this limitation, and it is applied on Makhdumi alone in the rejection below. As indicated in the prior Office Action (page 21) and in the Final Rejection, the broadest reasonable interpretation (BRI) of the limitation “detect that the computing device/remote client device is unable to participate in the data transaction with the service provider” is just a determination made by a user that it won’t complete the transaction by himself/herself. The same BRI applies equally to the present amendment “chooses not to perform.” The amendment from “is not configured to perform” to “chooses not to perform” recites, in affirmative form, the very determination the Examiner previously identified, and therefore narrows nothing relative to the mapping already of record.
Makhdumi paragraphs [0036-0037] and Fig. 1B describe that a user 131a captures a snapshot 132 of merchant QR pay code 134 generated at the POS terminal 133. Rather than completing the merchant’s payment transaction directly, user 131a generates a “split-tender” QR code 135 and forwards it to users 131b-c, who then make direct payments to merchant via the split tender QR code. As explicitly stated in paragraph [0036] “when the user 131a took a snapshot of the merchant’s QR code, no payment processing occurred immediately.” Thus, for each split-tender data transaction performed by users 131b-c, the user 131a device is a non-transacting remote device, and the act of generating and forwarding the split-tender QR code, which itself represents “information on the amounts that the tender has been split into”, instead of completing the payment directly to the merchant, is an indication carried in the transmitted data that the user 131a’s device will not perform [i.e. chooses not to perform] the data transaction.
With respect to Applicant’s argument that “no payment processing occurred immediately” concerns only the timing of payment processing, Examiner respectfully disagree. Makhdumi sets out two options in [0036] where users 131b-c “may be reimbursing the user 131a for payment of the original QR code”, or users 131b-c “may be making direct payments via the split tender QR code to the merchant”, where in that option the capturing device never pays the merchant at all.
Regarding to “a request to complete the data transaction with the service provider, on behalf of the non-transacting remote device, using the digital image,” the rejection below has been modified to rely on the Dang (US 20150067781 A1) publication for this limitation specifically. Dang [0025] describes that “when the user purchases a product from a shopping website, the user submits an order through a PC, chooses a payment method of the order, and initiates the data processing request for payment”, and that a two-dimensional code is generated from that request carrying “an order number, a product name, a total amount of the order, information of a payment receiving party.” Dang [0026-0030] describes that information relating to that request is obtained by scanning the code with a second communication device, that “the server of data processing generates a user interface for payment based on the received order information. Such user interface is used to finally complete processing payment data”, and that the payment is confirmed by “a user who has payment authorization and is willing to confirm the payment”, where “The user may be the user at 102 that initiates the data processing request or another user.” Dang [0041-0045] further establishes that the account used is obtained from the second device, and [0057-0058] that “the data processing completion information is forwarded to the first communication device”, whereupon the first device “displays a result of payment data processing of this transaction to the user.”
Thus, Dang teaches a first communication device that originates a transaction with a service provider and does not itself pay it, a second communication device that receives that transaction information, and completion of the first device’s transaction using the second device’s own payment account (i.e. completion of the data transaction with the service provider on behalf of the originating device) with the completion status returned to the originating device.
Applicant addresses the references individually. One cannot show non-obviousness by attacking references individually where the rejection is based on a combination of references. In re Keller, 642 F.2d 413 (CCPA 1981); In re Merck & Co., 800 F.2d 1091 (Fed. Cir. 1986). See MPEP 2145.
Therefore, the Examiner has determined that this argument is not persuasive.
Argument 2: Applicant argues on the Applicant Arguments and Remarks on pages 15-15 “The combination of references also fails to teach or suggest features to “generate, responsive to identification of the location of the non-transacting remote device and completion of the data transaction by the computing device with the service provider using the digital image, an association that identifies the location of the non-transacting remote device as a transaction performance location and identifies the location of the computing device as a transaction authorization location” and “store the association between the transaction performance location and the transaction authorization location in a record of the data transaction at a storage device.”“
Response to Argument 2: Examiner respectfully disagree. As an initial matter, the previously rejected claim already required an association indicating “that a transaction location of the data transaction is the location of the non-transacting remote device and is different from a location of the computing device.” The present amendment requires the same two location values, now given the names “transaction performance location” and “transaction authorization location.” The claim does not require that those names be stored, it requires that the association identify which location is which.
Regarding to a transaction being completed by a device at a location different from that of the originating device, Makhdumi [0033] disclose that a code may be conveyed to a remote device by “sending the QR code by email, social network message, tweet, etc.,” whereupon “The first user may take a snapshot of the QR code using the first user’s mobile phone… and utilize… the first user’s virtual wallet… to generate a purchase transaction request for processing by the payment network” and that “Upon completion of the transaction, the payment network may provide transaction notification receipts to the users who are parties to the transaction.” Makhdumi [0039] also describes a code placed on a first user’s public profile page that “A second user may capture… using a mobile device” and then submit “to a payment network for transaction processing.” Makhdumi [0190-0191] teaches determining the position of each such device. Makhdumi therefore teaches completion of a transaction by a device that is not co-located with the device that originated the code, with each device’s location determined.
Regarding the identifying one location as the performance location and the other as the authorization location, Akin [0033] disclose that “the payment provider can assess the validity of the purchase transaction by comparing the two pieces of GPS information, one, embedded in a geotagged image telling the location of a payment instrument at the time of capture and geotagging, and the other, telling the location of the transmitting device at the time of transmission.” Akin [0020] identifies the first value as “the location of the point of sale (POS),” (i.e. where the purchase transaction is performed). Akin [0037] identifies the transmission event associated with the second value as the authorization requesting event “When the geotagged image of a payment instrument is wirelessly transmitted to the payment provider, such transmission constitutes a request to the payment provider for processing the payment.” Akin therefore differentiates a performance location from an authorization-request location both by field and by function, and Akin [0031, 0035] explicitly address the case in which the two values are not the same.
Regarding the extraction of the location from image metadata, Akin [0020] disclose that “the metadata for the geotag information are embedded therein in an exchangeable image file format (EXIF)… read and written by special programs such as the cross-platform open source ExifTool” and Akin [0047] further disclose that the verification application assesses “by comparing the GPS information and time information, derived respectively from the geotagged images and transmissions from the user device 310”.
Regarding the storage in a record of the data transaction, Akin [0048] discloses that “a transaction processing application 375, configured to process the payment request from the user device 310 upon the verification of the claimed purchase transaction… and store the transaction in a payment database 377”, where the stored transaction is the same transaction whose “transaction information” comprises both identified GPS values (Akin [0024, 0047], claim 1). Makhdumi [0075] teaches generating a “transaction data record” and storing “the details of the transaction and authorization relating to the transaction in a transactions database.” See rejection below.
Therefore, the Examiner has determined that this argument is not persuasive.
Claim Objections
Claims 10-11 and 15 objected to because of the following informalities:
Claim 10 recites “store an association that identifies the location of the additional computing device as a transaction authorization location” while the indefinite recitation “a location of the additional computing device” appears later in the same clause. The order of recitations should be corrected.
Claim 10 also recites “detect that the computing device chooses not to participate in the data transaction with the service provider”. A computing device does not “choose”. Examiner suggests reciting the detection in terms of a determination, by the content control module, that the data transaction will not be performed at the computing device.
Claim 11 recites “a quick response code (a QR code).” The parenthetical is redundant of the preceding phrase. Examiner suggests “a quick response (QR) code.”
In claim 15 “the location of the non-transacting remote device associated with the service provider and is different from a location of the user device.” The phrase is grammatically incomplete. Examiner suggests “the location of the non-transacting remote device being associated with the service provider and being different from a location of the user device.”
Appropriate correction is required.
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-5, 7-15 and 17-22 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites “identifies the location of the computing device as a transaction location”. Claim 1 does not previously recite any location of the computing device, the only location previously recited is “a location associated with a data transaction with a service provider”, which claim 1 attributes to the non-transacting remote device. The limitation “the location of the computing device” lacks antecedent basis. For examination purposes, “the location of the computing device” in claim 1 is interpreted as a location of the computing device at the time it completes the data transaction with the service provider, consistent with the specification [0012, 0047] “a location where the payment transaction is authorized, initiated, and/or completed”.
Claim 9 recites “wherein the association differentiates between the transaction authorization location and the location of the computing device during completion of the data transaction.”, but claim 1 (from which claim 9 depends) recites “an association that… identifies the location of the computing device as a transaction authorization location.” Claim 9 therefore requires the association to differentiate a value from itself, and its metes and bounds cannot be determined. For examination purposes, claim 9 is interpreted as reciting “wherein the association differentiates between the transaction performance location and the location of the computing device during completion of the data transaction”, consistent with the Specification at [0012, 0057].
Claim 10 recites “store an association that identifies the location of the additional computing device as a transaction authorization location and identifies the location of the computing device as a transaction performance location”. Claim 10 does not previously recite any location of the computing device, “the location of the computing device” lacks antecedent basis. For examination purposes “the location of the computing device” is interpreted as the location at which the computing device captured the digital image, consistent with the specification [0051, 0056] “the sender device 102 embeds the sender location 208 within metadata 310 of the digital image… transaction location 420, which in this example corresponds to the sender location 208 at the time of the data transaction”.
Dependent claims 2-5, 7-15 and 17-22 are rejected for depending on the above rejected claims.
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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 4, 7-15, 17 and 22are rejected under 35 U.S.C. 103 as being unpatentable over Makhdumi (US Patent Application Publication No. US 20150248664 A1 - hereinafter Reference1), in view of Dang (US Patent Application Publication No. US 20150067781 A1), in view of Akin (US Patent Application Publication No. US 20140279096 A1 - hereinafter Reference3).
Regarding claim 1, Reference1 teaches computing device, comprising: a content control module implemented at least partially in hardware and configured to: receive input data from a non-transacting remote device at a location associated with a data transaction with a service provider, (See Reference1 [0036], Fig. 1B “one of the users 131 a [e.g. the non-transacting remote device] may obtain a snapshot, e.g., 132, of a QR pay code, e.g., 134, generated at a POS terminal (or, e.g., presented on paper such as a dining bill), e.g., 133 [Thus, at a location associated with a data transaction with a service provider (e.g. the merchant’s point of sale where the tender was generated)]… The user 131 a may present the split tender QR code 135 to the other users 131 b-c [Thus, receive input data from the non-transacting remote device], who may obtain snapshots of the split tender QR code, e.g., 136… the users 131 b-c may be making direct payments via the split tender QR code to the merchant [e.g. the service provider] (e.g., when the user 131 a took a snapshot of the merchant’s QR code, no payment processing occurred immediately [Thus, that device is non-transacting]).” See also Reference1 [0033] “The second user may display the QR code generated to the first user (e.g.,… sending the QR code by email, social network message, tweet, etc.)… the two users may share the data encoded in the QR code via methods alternate to the QR code, including but not limited to: near-field communications (NFC), Wi-Fi™, Bluetooth™, cellular network, SMS, email, text messages and/or the other communication protocols [Thus, the input data is transmitted from, and received from, the originating device].”
Examiner notes that based on the Specification paragraphs [0012, 0020] (“a payment transaction represents a data transaction”), the term “data transaction” is interpreted as payment transaction.)
PNG
media_image1.png
314
731
media_image1.png
Greyscale
the input data including: an indication that the non-transacting remote device chooses not to perform the data transaction; (See Reference1 [0036] “The user may in turn generate a QR split pay code, embodying information on the amounts that the tender has been split into [Thus, the indication]… the users 131 b-c may be making direct payments via the split tender QR code to the merchant (e.g., when the user 131 a took a snapshot of the merchant’s QR code, no payment processing occurred immediately [Thus, the sending device chooses not to perform the transaction it captured]” See also Reference1 [0066] “the QR code and messages sent to/from the QR-code capturing device may include the source ID (e.g., identifier of the device generating the QR code), session ID, merchant ID, item ID (e.g., model number), the charge amount, and/or transacting device ID (e.g., the user’s smartphone device).”)
a digital image captured by the non-transacting remote device at the location associated with the data transaction that includes a code for performing the data transaction; and (See Reference1 [0036] “one of the users 131 a may obtain a snapshot, e.g., 132 [Thus, a digital image captured by the non-transacting remote device], of a QR pay code, e.g., 134 [Thus, a code for performing the data transaction], generated at a POS terminal… e.g., 133 [Thus, captured at the location associated with the data transaction].” See also Reference1 [0120] “A user may use his or her mobile phone to take a picture of a QR code 1115… the user may initiate code capture using the mobile device camera (see 1120).” See also Reference1 [0124] “a user may snap a QR code of a transaction that is not yet complete. The QR code may be displayed at a merchant POS terminal… and may be encoded with information identifying items for purchase, merchant details and other relevant information.”)
a request to complete the data transaction with the service provider, on behalf of the non-transacting remote device, using the digital image; (See Reference1 [0036] “The user 131 a may present the split tender QR code 135 to the other users 131 b-c… the users 131 b-c may be making direct payments via the split tender QR code to the merchant (e.g., when the user 131 a took a snapshot of the merchant’s QR code, no payment processing occurred immediately).”)
Reference1 does not explicitly disclose that what is received is a request to complete the data transaction on behalf of the non-transacting remote device.
However, Dang teaches a request to complete the data transaction with the service provider, on behalf of the non-transacting remote device, using the digital image. (See Dang [0025-0027] “when the user purchases a product from a shopping website, the user submits an order through a PC, chooses a payment method of the order, and initiates the data processing request for payment [e.g. the non-transacting remote device originates the data transaction with the service provider]… The information of the data processing request for payment may include data including an order number, a product name, a total amount of the order, information of a payment receiving party… At 104, information relating to the data processing request, which is obtained through scanning the two-dimensional code by a second communication device, is received from the second communication device… the second communication device scans the two-dimensional code [Thus, the originating device’s transaction information reaches the second device by way of the code image].” See also Dang [0029-0030] “the server of data processing generates a user interface for payment based on the received order information. Such user interface is used to finally complete processing payment data… the user interface is used to inform the user of the information relating to the data processing of the payment and receive a payment confirmation from the user. If the user confirms the payment, the data processing of the payment completes. The user refers to a user who has payment authorization and is willing to confirm the payment. The user may be the user at 102 that initiates the data processing request or another user [Thus, the party completing the originating device’s transaction may be a different party entirely (i.e. it is completed on the originating device’s behalf)].” See also Dang [0045] “At 210, a user interface for data processing is generated at the second communication device according to the information relating to the data processing request and the information of the data processing account” See also Dang [0041-0042] “information of a data processing account is obtained from a second communication device… the second communication device may be required to submit information of a valid data processing account [Thus, the originating device’s order is handled from the second device’s account]… the server of data processing may obtain information of the data processing account that is already logged in through the client software.” See also Dang [0056-0058] “when the user who has the payment authorization of the data processing account inputs information that approves the payment at the user interface for payment… the server of processing payment data completes the payment [Thus, completion of the data transaction with the service provider]… When the methods of the present disclosure are applied to processing the payment data, the tedious operations that log into the client of processing payment data at the first communication device are prevented… At 214, the data processing completion information is forwarded to the first communication device… the first communication device, according to contents included in the information, displays a result of payment data processing of this transaction to the user [Thus, the transaction so completed was the originating device’s own transaction].”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Reference1; which forwards a captured pay code to another user’s device that pays the merchant, to incorporate the teachings of Dang of handling the forwarded order from an account supplied by the receiving device (i.e. an account for which that device has already completed the log in), with the outcome returned to the originating device. Each reference carries out code-based payment through a payment server operating and order data encoded in the code, the combination of known elements performing the same respective functions, yielding predictable results.
One would be motivated to do so to complete the transaction without requiring the originating device to hold or transmit payment credentials of its own (Dang [0041-0045])
Reference1 in view of Dang, [hereinafter Reference1-Dang] additionally disclose identify the location of the non-transacting remote device by extracting the location from metadata of the digital image;
Reference1 teaches that the location of the capturing device is associated with the captured code and determined by that device. (See Reference1 [0120] “the virtual wallet application may optionally apply a Global Positioning System tag (see 1118) to the QR code… before storing it, or utilizing it in a transaction.” See also Reference1 [0190] “the geolocation module 1514 may determine a set of coordinates or an address associated with the position of the mobile device 1510.”)
Reference1 does not explicitly disclose that the location value so associated resides in the metadata of the digital image.
However, Reference3 teaches identify the location of the capturing device by extracting the location from metadata of the digital image. (See Reference3 [0020] “the image is geotagged at the time of capture by the merchant or buyer device. Geotagging is a process of adding geographical identification metadata representing a particular position or location to various media such as a geotagged photograph or video, websites, SMS messages, QR Codes or RSS feeds… the GPS data geotagged into the image presents the location of the point of sale (POS) [e.g. the location of the capturing device]… if photos or scanned images are stored in JPEG file format, the typical the metadata for the geotag information are embedded therein in an exchangeable image file format (EXIF) or an extensible metadata platform (XMP) format. These data are not visible in the picture itself but are read and written by special programs such as the cross-platform open source ExifTool [Thus, the location resides in the image’s metadata and is read out of it].” See also Reference3 [0026] “the geotagged image may include first global positioning system (GPS) information of the location of the payment instrument… when the image was captured.” See also Reference3 [0030] “the payment provider assesses the validity of the purchase transaction via a match between the GPS information included in the geotagged image and the second GPS information received at step 202 [Thus, the receiving entity necessarily extracts that value out of the received image to evaluate it].” See also Reference3 [0047] “the purchase transaction verification application 395, on receipt of the geotagged images… assesses, by comparing the GPS information and time information, derived respectively from the geotagged images and transmissions from the user device 310 [Thus, the location information is extracted from the image captured by the other device].”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Reference1 in view of Dang; in which Reference1 applies a Global Positioning System tag to a captured pay code before the code is used in a transaction and already stores a transaction data record upon completion, to incorporate the geotag metadata location handling of Reference3 including both extraction of the capture location from the image metadata and retention of that location together with the location of the device requesting payment processing for use in transaction verification.
One would be motivated to do so to allow location information recorded for each transaction is obtained for checking validity of purchase transaction, ensuring the validity of a claimed purchase transaction and preventing a potential fraud against the payment provider (Reference3 [0033]).
Reference1-Dang in view of Reference3, [hereinafter Reference1-Dang-Reference3] additionally disclose generate, responsive to identification of the location of the non- transacting remote device and completion of the data transaction by the computing device with the service provider using the digital image, an association that identifies the location of the non-transacting remote device as a transaction performance location and identifies the location of the computing device as a transaction authorization location; (See Reference1 [0045] “upon obtaining a snapshot of the merchant-product QR code, the user’s smartphone may extract the product and merchant data stored within the QR code, and utilize an account for the user’s virtual wallet linked to the user’s smartphone to create a purchase transaction request, and submit the request to a payment network [Thus, the receiving device completes the transaction with the service provider by operating on the received image].” See also Reference1 [0036] “the users 131 b-c may be making direct payments via the split tender QR code to the merchant.” See also Reference1 [0075] “Upon determining that the user possesses sufficient funds for the transaction, the pay network server may generate a transaction data record, e.g., 432, from the authorization request and/or authorization response [Thus, the record is generated responsive to completion of the data transaction].”)
Reference1-Dang does not explicitly disclose an association that holds two separately identified location values for one transaction and identifies one of them as the location at which the transaction was performed and the other as the location at which the transaction was authorized.
However, Reference3 teaches an association that identifies the location of the non-transacting remote device as a transaction performance location and identifies the location of the computing device as a transaction authorization location; (See Reference3 [0020] “the GPS data geotagged into the image presents the location of the point of sale (POS), or equivalently, the location of the payment instrument at the time it is being captured [i.e. the transaction performance location].” See also Reference3 [0024] “at step 202, the payment provider receives transaction information from the user through the user device for a purchase transaction… The transaction information includes a geotagged image of a payment instrument… The transaction information further includes a second, separate GPS information of the location of the user device at the time of transmitting the transaction information [Thus, a second, separately identified location value held within the same transaction information].” See also Reference3 [0037] “When the geotagged image of a payment instrument is wirelessly transmitted to the payment provider, such transmission constitutes a request to the payment provider for processing the payment [Thus, confirming that the second value is the location from which the transaction is authorized (e.g. the transaction authorization location)].” See also Reference3 [0033] “the payment provider can assess the validity of the purchase transaction by comparing the two pieces of GPS information, one, embedded in a geotagged image telling the location of a payment instrument at the time of capture and geotagging, and the other, telling the location of the transmitting device at the time of transmission [Thus, the association identifies which value is which].” See also Reference3 claim 1 “the transaction information comprising: an image of a payment instrument captured at the POS, a location of the payment instrument at a time of capture; and a location of the user device at a time of receipt of the transaction information.” See also Reference3 [0029-0030, 0037] “After receiving the transaction information and the second GPS information transmitted from the user device, then at step 204, the payment provider determines the validity of the payment instrument… now at step 206, the payment provider assesses the validity of the purchase transaction via a match between the two values… Lastly, at step 210, the payment provider may process a payment to the merchant’s account on a positive determination on the validity of the purchase transaction at step 208. [Thus, responsive to identification of the location and completion of the data transaction]”)
store the association between the transaction performance location and the transaction authorization location in a record of the data transaction at a storage device. (See Reference1 [0075] “the pay network server may generate a transaction data record, e.g., 432, from the authorization request and/or authorization response, and store the details of the transaction and authorization relating to the transaction in a transactions database [Thus, a record of the data transaction at a storage device].” See also Reference1 [0078] “The pay network server may store the transaction data, e.g., 446, for each transaction in a database, e.g., pay network database 407.” See also Reference3 [0048] “a transaction processing application 375, configured to process the payment request from the user device 310 upon the verification of the claimed purchase transaction via the purchase transaction verification application 395 and store the transaction in a payment database 377.” See also Reference3 [0047] “assesses, by comparing the GPS information and time information, derived respectively from the geotagged images and transmissions from the user device 310 [Thus, both values are maintained in association as that transaction’s information].”)
Regarding claim 2, Reference1-Dang-Reference3 teaches all limitations and motivations of claim 1, wherein the input data includes a text message and the digital image depicts a transaction link to initiate the data transaction. (See Reference1 [0029] “the POS terminal may communicate the information required for submitting a purchase transaction request to a payment network to user device via Bluetooth™, Wi-Fi, SMS, text message, electronic mail, and/or other communication methods.” See also Reference1 [0033] “the two users may share the data encoded in the QR code via methods alternate to the QR code, including but not limited to:… SMS, email, text messages.” See also Reference1 [0124] “The QR code may be displayed at a merchant POS terminal, a web site, or a web application and may be encoded with information identifying items for purchase, merchant details and other relevant information. When the user snaps such as a QR code, the snap mode may decode the information in the QR code… The user may now have an option to… pay with a default payment account 1134 or pay with wallet 1135 [Thus, the depicted code is the link by which the transaction is initiated].”
Examiner notes that based on the Specification paragraph [0044] “the input data 210 includes a digital image of a transaction link such as a QR code”, the transaction link can be a QR code.)
Regarding claim 4, Reference1-Dang-Reference3 teaches all limitations and motivations of claim 1, wherein the content control module is further configured to generate one or more data transaction insights for display in a user interface of the computing device based in part on the association. (See Reference1 [0115] “a user may select the history mode 1010 to view a history of prior purchases and perform various actions on those prior purchases [Thus, based in part on the stored associations]… The wallet application may query the storage areas in the mobile device or elsewhere (e.g., one or more databases and/or tables remote from the mobile device) for transactions matching the search keywords… The user interface may then display the results of the query such as transaction 1015. The user interface may also identify the date 1012 of the transaction, the merchants and items 1013 relating to the transaction [e.g. generate one or more data transaction insights for display in a user interface displayed in a user interface].” See also Reference1 [0116] “the user may add the transaction to a group such as company expense, home expense, travel expense… Such grouping may facilitate year-end accounting of expenses, submission of work expense reports, submission for value added tax (VAT) refunds.” See also Reference1 [0117] “The history mode… may offer facilities for obtaining and displaying ratings 1019 of the items in the transaction.”)
Regarding claim 7, Reference1-Dang-Reference3 teaches all limitations and motivations of claim 1, wherein identification of the location includes extraction of the location from exchangeable image file format (“EXIF”) metadata of the digital image. (See Reference3 [0020] “if photos or scanned images are stored in JPEG file format, the typical the metadata for the geotag information are embedded therein in an exchangeable image file format (EXIF) or an extensible metadata platform (XMP) format. These data are not visible in the picture itself but are read and written by special programs such as the cross-platform open source ExifTool [Thus, the location value is extracted from the EXIF metadata of the image].” See also Reference3 [0047] “assesses, by comparing the GPS information… derived respectively from the geotagged images and transmissions from the user device 310.”)
Regarding claim 8, Reference1-Dang-Reference3 teaches all limitations and motivations of claim 1, wherein identification of the location includes validation of the location against an address of a party to the data transaction. (See Reference1 [0191] “the geolocation module 1514 may be able to determine if the consumer and mobile device 1510 are within or near a merchant 1520 location. For example, the geolocation module 1514 may store information about one or more merchant 1520 locations, such as one or more sets of coordinates or addresses associated with one or more merchant 1520 locations [e.g. an address of a party to the data transaction]. The geolocation module 1514 may determine the position of the mobile device 1510, and then compare the position of the mobile device 1510 with the information about one or more merchant 1520 locations [Thus, validation of the identified location against that address]. If the mobile device 1510 has the same position as a merchant 1520 location, or if it is within a predetermined distance of a merchant 1520 location (e.g. within 10, 20, 50, or 100 feet), then the geolocation module 1514 may determine that the consumer and mobile device are within or near the merchant 1520 location [Thus, the validation result].”)
Regarding claim 9, Reference1-Dang-Reference3 teaches all limitations and motivations of claim 1, wherein the association differentiates between the transaction authorization location and the location of the computing device during completion of the data transaction. (See Reference3 [0020] “the GPS data geotagged into the image presents the location of the point of sale (POS) [e.g. the transaction performance location].” See also Reference3 [0024] “The transaction information further includes a second, separate GPS information of the location of the user device at the time of transmitting the transaction information [e.g. the location of the computing device during completion of the data transaction].” See also Reference3 [0030] “the payment provider assesses the validity of the purchase transaction via a match between the GPS information included in the geotagged image and the second GPS information received at step 202 [Thus, the association differentiates between the two by evaluating them as distinct values].” See also Reference3 [0033] “comparing the two pieces of GPS information, one, embedded in a geotagged image telling the location of a payment instrument at the time of capture and geotagging, and the other, telling the location of the transmitting device at the time of transmission.” Reference3 distinguishes the transmitting device’s location at the time of transmission (Reference3 [0024]) from the time of capture location carried by that device’s geotagged image (Reference3 [0020]), and compares them (Reference3 [0030, 0033]). See claim interpretation in the 112(b) rejection above.)
Regarding claim 10, Reference1-Dang-Reference3 teaches the elements of claim 10 corresponding to those of claim 1, claim 10 reciting the device that captures and forwards the digital image rather than the device that received it and completes the data transaction. The supporting rationale and motivation of the rejection to claim 1 applies equally as well to those elements. Each limitation of claim 10 is separately addressed below.
Reference1-Dang-Reference3 teaches a computing device, comprising: an image capture device; and a content control module implemented in hardware configured to: capture, using the image capture device, a digital image that includes a request to complete a data transaction with a service provider, (See Reference1 [0188] “The mobile device 1510 can include a processor, and memory, input devices, and output devices, operatively coupled to the processor.” See also Reference1 [0120] “the user may initiate code capture using the mobile device camera (see 1120). In another implementation, the snap mode may automatically snap the code using the mobile device camera (see 1119) [Thus, the image capture device].” See also Reference1 [0047] “the client device may have a camera via which the app may acquire images, video data, streaming live video, and/or the like, e.g., 303.” See also Reference1 [0124] “a user may snap a QR code of a transaction that is not yet complete. The QR code may be displayed at a merchant POS terminal… and may be encoded with information identifying items for purchase, merchant details and other relevant information [Thus, the captured image contains the merchant’s request for payment].” See also Reference1 [0036] “one of the users 131 a may obtain a snapshot, e.g., 132, of a QR pay code, e.g., 134.”)
the digital image captured at a location associated with the service provider; (See Reference1 [0036] “a QR pay code, e.g., 134, generated at a POS terminal (or, e.g., presented on paper such as a dining bill), e.g., 133 [Thus, the image is captured where the merchant presented the tender].” See also Reference1 [0102] “the mobile application may further identify when the user in a store based on the user’s location… position icon 819 d may be displayed next to a store (e.g., Walgreens) when the user is in close proximity to the store.”)
detect that the computing device chooses not to participate in the data transaction with the service provider; (See Reference1 [0036], Fig. 1B “the users 131 b-c may be making direct payments via the split tender QR code to the merchant (e.g., when the user 131 a took a snapshot of the merchant’s QR code, no payment processing occurred immediately [Thus, the capturing device determines it will not process the captured merchant transaction]). The user may in turn generate a QR split pay code, embodying information on the amounts that the tender has been split into [Thus, chooses not participate].”
Examiner notes that based on the Specification paragraphs [0013-0014], the broadest reasonable interpretation of a device that “chooses not to participate” is just a determination made by a user that it won’t complete the transaction by himself/herself.)
communicate data to an additional computing device that is identified to participate in the data transaction, (See Reference1 [0036] “The user 131 a may present the split tender QR code 135 to the other users 131 b-c [Thus, identified recipient devices], who may obtain snapshots of the split tender QR code, e.g., 136… the users 131 b-c may be making direct payments via the split tender QR code to the merchant [Thus, the devices so identified are the devices that participate in the data transaction].” See also Reference1 [0033] “the two users may share the data encoded in the QR code via methods alternate to the QR code, including but not limited to:… SMS, email, text messages [Thus, the data is directed to the identified recipient].”)
the data including: an indication that the computing device chooses not to participate in the data transaction; (See Reference1 [0036] “The user may in turn generate a QR split pay code, embodying information on the amounts that the tender has been split into [i.e. the indication]… (e.g., when the user 131 a took a snapshot of the merchant’s QR code, no payment processing occurred immediately).” See also Reference1 [0066] “the QR code and messages sent to/from the QR-code capturing device may include the source ID (e.g., identifier of the device generating the QR code), session ID, merchant ID, item ID (e.g., model number), the charge amount, and/or transacting device ID (e.g., the user’s smartphone device).”)
the digital image for performing the data transaction; and (See Reference1 [0036] “The user 131 a may present the split tender QR code 135 to the other users 131 b-c, who may obtain snapshots of the split tender QR code, e.g., 136… the users 131 b-c may be making direct payments via the split tender QR code to the merchant [Thus, the digital image for performing the data transaction].”)
a request to participate in the data transaction with the service provider, on behalf of the computing device, using the digital image. (See Dang [0036] “At 204, the two-dimensional code is presented through the first communication device… through a display of the first communication device [e.g. the originating device makes the code image available to the other device].” See also Dang [0029-0030] “the server of data processing generates a user interface for payment based on the received order information. Such user interface is used to finally complete processing payment data… The user may be the user at 102 that initiates the data processing request or another user.” See also Dang [0045] “a user interface for data processing is generated at the second communication device according to the information relating to the data processing request and the information of the data processing account,” that account being obtained from the second device per Dang [0041]. See also Dang [0056] “the server of processing payment data completes the payment.” See also Dang [0057-0058] “the data processing completion information is forwarded to the first communication device… the first communication device… displays a result of payment data processing of this transaction to the user [Thus, the transaction completed by the second device was the originating device’s transaction].”)
store an association that identifies the location of the additional computing device as a transaction authorization location and identifies the location of the computing device as a transaction performance location, (See Reference3 [0020] “the GPS data geotagged into the image presents the location of the point of sale (POS), or equivalently, the location of the payment instrument at the time it is being captured [Thus, the location at which the capturing device captured the image, identified as where the transaction is performed].” See also Reference3 [0024] “The transaction information further includes a second, separate GPS information of the location of the user device at the time of transmitting the transaction information [e.g. the transaction authorization location].” See also Reference3 [0037] “such transmission constitutes a request to the payment provider for processing the payment.” See also Reference3 [0048] “store the transaction in a payment database 377 [Thus, store the association].” See also Reference1 [0075] “the pay network server may generate a transaction data record… and store the details of the transaction and authorization relating to the transaction in a transactions database.”)
in response to receiving an indication of a transaction status based on the additional computing device participating in the data transaction using the digital image (See Reference1 [0033] “Upon completion of the transaction, the payment network may provide transaction notification receipts to the users who are parties to the transaction [Thus, the status indication is returned to the capturing device as a party].” See also Reference1 [0032] “Upon completion of the purchase transaction, the payment network may provide a purchase receipt directly to the user mobile device, the POS terminal in the store and/or the secure display… as confirmation of completion of transaction processing.” See also Reference1 [0077] “the server may also generate a purchase receipt, e.g., 434, and provide the purchase receipt to the client… the user device 405 may also provide a notification of successful authorization to the user.” See also Dang [0054] “At 212, data processing completion information is received from the second communication device.” See also Dang [0056] “when the user… inputs information that rejects the payment at the user interface for payment… the server of processing payment data rejects the payment. The data processing is also completed.” See also Dang [0057] “At 214, the data processing completion information is forwarded to the first communication device.”)
and identification of a location of the additional computing device that is different from the location associated with the service provider. (See Reference1 [0033] “The second user may display the QR code generated to the first user (e.g.,… sending the QR code by email, social network message, tweet, etc.). The first user may take a snapshot of the QR code using the first user’s mobile phone, e.g., 123, and utilize… the first user’s virtual wallet linked to the first user’s mobile phone, to generate a purchase transaction request for processing by the payment network [Thus, the device that participates in the transaction receives the code over a network and is not co-located with the device or place from which the code originated, and the transaction is nevertheless completed]. Upon completion of the transaction, the payment network may provide transaction notification receipts to the users who are parties to the transaction.” See also Reference1 [0039] “a first user having a public profile page, e.g., 151, may place an image of a QR code in the public profile, e.g., 152… A second user may capture a snapshot of the QR pay code using a mobile device, and may set an amount that the second user would like to pay… The second user’s mobile device may provide the information encoded within the QR code along with the second-user-chosen payment amount to a payment network for transaction processing [Thus, the participating device is remote from the place at which the code was made available].” See also Reference1 [0190] “the geolocation module 1514 may determine a set of coordinates or an address associated with the position of the mobile device 1510 [Thus, the location of the participating device is identified].” See also Reference1 [0191] “the geolocation module 1514 may be able to determine if the consumer and mobile device 1510 are within or near a merchant 1520 location… the geolocation module 1514 may determine the position of the mobile device 1510, and then compare the position of the mobile device 1510 with the information about one or more merchant 1520 locations [Thus, an identification of whether the participating device’s location is or is not the merchant’s location].” See also Reference3 [0031] “any difference in the GPS information (i.e., in location)… would result… when the image… captured and geotagged at the POS with the smart phone, is somehow transmitted to the payment provider at a later time from a different place that is far enough from the POS to have different GPS data.”)
Regarding claim 11, Reference1-Dang-Reference3 teaches all limitations and motivations of claim 10, wherein the digital image depicts a quick response (QR) code (See Reference1 [0120] “A user may use his or her mobile phone to take a picture of a QR code 1115… When the code 1116 is completely framed by the snap frame 1115, the bar message may be updated to, for example, “snap found.”“)
and the content control module is configured to detect that the digital image includes the request to complete the data transaction by decoding the QR code. (See Reference1 [0064] “the user device may determine whether an image it has captured depicts a QR code. Depending on whether or not a QR code has been captured, and also (optionally) depending on contents of the QR code, the user device may redirect the user.” See also Reference1 [0124] “When the user snaps such as a QR code, the snap mode may decode the information in the QR code and may use the decoded information to generate a receipt 1132. Once the QR code is identified, the navigation bar 1131 may indicate that the pay code is identified [Thus, detecting, by decoding, that the image includes a request to complete a data transaction].” See also Reference1 [0130] “the virtual wallet application may decode the QR code, and extract data from the QR code.”)
Regarding claim 12, Reference1-Dang-Reference3 teaches all limitations and motivations of claim 10, wherein the content control module is configured to identify a current location of the computing device (See Reference1 [0190] “the geolocation module 1514 may determine a set of coordinates or an address associated with the position of the mobile device 1510… the geolocation module 1514 may locate or communicate with one or more satellites in a GPS network.” See also Reference1 [0120] “the virtual wallet application may optionally apply a Global Positioning System tag (see 1118) to the QR code.” See also Reference1 [0120] “When the code 1116 is completely framed by the snap frame 1115, the bar message may be updated to, for example, ‘snap found.’ Upon finding the code [Thus, responsive to detection of the request within the image], in one implementation, the user may initiate code capture using the mobile device camera (see 1120)… the virtual wallet application may optionally apply a Global Positioning System tag (see 1118) to the QR code before storing it, or utilizing it in a transaction.”)
embed the current location within metadata of the digital image. (See Reference3 [0020] “the image is geotagged at the time of capture by the merchant or buyer device. Geotagging is a process of adding geographical identification metadata representing a particular position or location to various media such as a geotagged photograph or video, websites, SMS messages, QR Codes or RSS feeds… the metadata for the geotag information are embedded therein in an exchangeable image file format (EXIF) or an extensible metadata platform (XMP) format [Thus, the capturing device’s current location is written into the metadata of the captured image at the time of capture].” See also Reference3 [0026] “the geotagged image may include first global positioning system (GPS) information of the location of the payment instrument… when the image was captured.”)
Regarding claim 13, Reference1-Dang-Reference3 teaches all limitations and motivations of claim 10, wherein the content control module is further configured to receive an indication that the data transaction has been completed by the additional computing device; (See Reference1 [0033] “Upon completion of the transaction, the payment network may provide transaction notification receipts to the users who are parties to the transaction.” See also Reference1 [0032] “Upon completion of the purchase transaction, the payment network may provide a purchase receipt directly to the user mobile device, the POS terminal in the store and/or the secure display… as confirmation of completion of transaction processing.” See also Dang [0057-0058] “the data processing completion information is forwarded to the first communication device… the first communication device… displays a result of payment data processing of this transaction to the user.”)
generate a transaction receipt that includes an association between the location associated with the service provider and the data transaction. (See Reference1 [0124] “When the user snaps such as a QR code, the snap mode may decode the information in the QR code and may use the decoded information to generate a receipt 1132 [Thus, generate a transaction receipt].” See also Reference1 [0125] “Upon completion of the transaction, a receipt may be automatically generated for proof of purchase.” See Reference1 Fig. 11C disclosing a generated receipt of a completed transaction which includes an address 1136 [e.g. the location associated with the service provider] together with the details of the transaction. See also Reference1 [0115] “The user interface may also identify the date 1012 of the transaction, the merchants and items 1013 relating to the transaction, a barcode of the receipt confirming that a transaction was made, the amount of the transaction and any other relevant information.”)
Regarding claim 14, Reference1-Dang-Reference3 teaches all limitations and motivations of claim 10, wherein the content control module is configured to validate the location associated with the service provider against an address associated with a party to the data transaction. (See Reference1 [0190-0191] “the geolocation module 1514 may determine a set of coordinates or an address associated with the position of the mobile device 1510… the geolocation module 1514 may be able to determine if the consumer and mobile device 1510 are within or near [Thus, validate] a merchant 1520 location. For example, the geolocation module 1514 may store information about one or more merchant 1520 locations, such as one or more sets of coordinates or addresses associated with one or more merchant 1520 locations [e.g. an address associated with a party to the data transaction]. The geolocation module 1514 may determine the position of the mobile device 1510, and then compare the position of the mobile device 1510 with the information about one or more merchant 1520 locations.” See also Reference1 [0197] “the mobile wallet application 1512 may store information about one or more merchant 1520 locations, receive information about the current mobile device 1510 location from the geolocation module 1514, and then may determine a merchant 1520 associated with that the mobile device 1510 location.”)
Regarding claim 15, Reference1-Dang-Reference3 teaches all of the elements of claim 15 corresponding to those of claims 1 and 10. The supporting rationale of the rejection to claims 1 and 10 applies equally as well to those elements of claim 15. Claim 15 further recites that the location of the non-transacting remote device is different from a location of the user device, and that the location id extracted from the input data rather than from metadata of the digital image.
Reference1-Dang-Reference3 additionally disclose determining, responsive to detection of the request, a location of the non-transacting remote device by extracting the location from the input data, (See Reference3 [0020] “the GPS data geotagged into the image presents the location of the point of sale (POS)… the metadata for the geotag information are embedded therein in an exchangeable image file format (EXIF)… read and written by special programs such as the cross-platform open source ExifTool.” See also Reference3 [0029] “After receiving the transaction information and the second GPS information transmitted from the user device, then at step 204, the payment provider determines the validity of the payment instrument [Thus, the determination follows receipt and detection of the request].” See also Reference3 [0047] “assesses, by comparing the GPS information and time information, derived respectively from the geotagged images and transmissions from the user device 310 [Thus, the location is determined by extraction from the received data].”)
the location of the non-transacting remote device associated with the service provider and is different from a location of the user device; (See Reference1 [0033] “The second user may display the QR code generated to the first user (e.g.,… sending the QR code by email, social network message, tweet, etc.). The first user may take a snapshot of the QR code using the first user’s mobile phone, e.g., 123, and utilize… the first user’s virtual wallet… to generate a purchase transaction request for processing by the payment network [Thus, the code is conveyed over a network to a device that is not co-located with the originating device, and the transaction is nevertheless executed]. Upon completion of the transaction, the payment network may provide transaction notification receipts to the users who are parties to the transaction.” See also Reference1 [0039] “a first user having a public profile page… may place an image of a QR code in the public profile… A second user may capture a snapshot of the QR pay code using a mobile device… The second user’s mobile device may provide the information encoded within the QR code… to a payment network for transaction processing [Thus, the executing device is remote from the originating device].” See also Reference1 [0190] “the geolocation module 1514 may determine a set of coordinates or an address associated with the position of the mobile device 1510 [Thus, each device’s location is determined].”)
Regarding claim 17, Reference1-Dang-Reference3 teaches all limitations and motivations of claim 15, wherein the input data includes a text message (See Reference1 [0029] “the POS terminal may communicate the information required for submitting a purchase transaction request to a payment network to user device via Bluetooth™, Wi-Fi, SMS, text message, electronic mail, and/or other communication methods.” See also Reference1 [0033] “the two users may share the data encoded in the QR code via methods alternate to the QR code, including but not limited to:… SMS, email, text messages.”)
and detecting the request includes detecting one or more key words or phrases from the text message that indicate the request to initiate the data transaction. (See Reference1 [0066] “the QR code and messages sent to/from the QR-code capturing device may include the source ID (e.g., identifier of the device generating the QR code), session ID, merchant ID, item ID (e.g., model number), the charge amount, and/or transacting device ID [e.g. the terms carried within the message that indicate a transaction is being requested and identify its merchant and amount].” See also Reference1 [0130] “the virtual wallet application may decode the QR code, and extract data from the QR code. If the virtual wallet application is unable to detect a QR code (605, option ‘No’), the virtual wallet application may attempt to perform Optical Character Recognition on the image… Thus, the virtual wallet application may obtain the data encoded into the image, and may continue if the data can be processed [Thus, the receiving device parses the received content for the terms that indicate the transaction request].” See also Reference1 [0100] “the SMS 817 q Joe received indicates that Joe can redeem the $5 obtained via SMS by replying to the SMS and entering the hash tag value ‘#1234’.”)
Regarding claim 22, Reference1-Dang-Reference3 teaches all limitations and motivations of claim 1, wherein the digital image is generated based on text instructions to complete the data transaction. (See Reference1 [0057-0059] “the merchant server may generate in real-time, a custom, user-specific merchant-product XML data structure having a time-limited validity period, such as the example ‘QR_data’ XML data structure provided below [e.g. the text instructions]: <QR_data><order_ID>4NFU4RG94</order_ID> <timestamp>2011-02-22 15:22:43</timestamp> <transaction_cost>$34.78</transaction_cost>… <merchant_id>3FBCR4INC</merchant_id>… </QR_data>… In some implementations, the merchant may generate a QR code using the XML data… the merchant server may issue PHP commands similar to the example commands provided below: …// Create QR code image using data stored in $data variable QRcode::png($data, ‘qrcodeimg.png’); [Thus, the digital image is generated based on text instructions to complete the data transaction].” See also Reference1 [0056] “the QR code may include at least information required by the user device capturing the QR code to generate a purchase transaction processing request, such as a merchant identifier… and a session identifier.”)
Claims 3 and 18-21 are rejected under 35 U.S.C. 103 as being unpatentable over Reference1-Dang-Reference3 in view of the Tavares (US Patent Application Publication No. US 20120084117 A1).
Regarding claim 3, Reference1-Dang-Reference3 teaches all limitations and motivations of claim 1, wherein the content control module is further configured to display a map in a user interface of the computing device that depicts the transaction performance location as the location of the non-transacting remote device.
Reference1-Dang-Reference3 teaches displaying, in a user interface of the computing device, a map on which the location of another, remote device is depicted. (See Reference1 [0103] “the local proximity option 819 may include a store map and a real time map features among others… the user may launch an aisle map 819 l which displays a map 819 m showing the organization of the store and the position of the user (indicated by a yellow circle)… In one implementation, the user may easily configure the map to add one or more other users (e.g., user’s kids) to share each other’s location [Thus, the displayed map plots the location of a different, remote device].” See also Reference1 [0102] “position icon 819 d may be displayed next to a store (e.g., Walgreens) when the user is in close proximity to the store.”)
Reference1-Dang-Reference3 does not explicitly disclose that the map displayed is populated with the locations at which transactions were performed, drawn from the stored transaction data.
However, Tavares teaches displaying a map that depicts the location at which a transaction was performed. (See Tavares [0019] “The given market could also comprise one or more geographical regions, and the market dataset may be identified by determining a geographical region where the POS terminals are located [e.g. the locations at which the transactions were performed]… This numeric display may be superimposed over a map of the geographic region [Thus, a map on which transaction performance locations and their transaction data are displayed].” See also Tavares [0196] “the computer system generates a report from the POS data and renders a graphical display on a display screen 1214… Display screen 1214 shows map 1202 along with an enhanced view of the geographical region 1216 of interest. A report 1218 displays growth and other information… the dollar volume growth, the transaction growth, the average ticket growth.” See also Tavares [0201] “a merchant may be able to enter a request to see a graphical depiction of all similarly situation merchants within the region… and to have this information visually depicted on a map. In this way, the merchant can quickly see where the competing grocery stores are location.” See also Reference3 [0020] identifies the geotagged capture location as “the location of the point of sale (POS)” [e.g. the location at which the transaction was performed].)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Reference1-Dang-Reference3; in which Reference1’s wallet already renders maps within its user interface and plots on them the position of the user’s device and of other devices whose locations are shared, and queries the stored transaction records for display, to incorporate the teachings of Tavares which populate the map using the transaction location data.
One would be motivated to do so to effectively visualize and recognize the location at which a transaction was performed to be recognized from its position on the map.
Regarding claim 18, Reference1-Dang-Reference3 teaches all limitations and motivations of claim 17, further comprising: accessing the storage device to obtain a plurality of associations between locations and data transactions; and displaying, in a user interface of the user device, a view of a map that includes the plurality of associations between the locations and the data transactions. (See Reference1 [0115] “The wallet application may query the storage areas in the mobile device or elsewhere (e.g., one or more databases and/or tables remote from the mobile device) for transactions matching the search keywords… The user interface may then display the results of the query such as transaction 1015. The user interface may also identify the date 1012 of the transaction, the merchants and items 1013 relating to the transaction [Thus, a plurality of stored transaction records, each carrying its associated merchant/location, is obtained from storage].” See also Reference1 [0078] “The pay network server may store the transaction data, e.g., 446, for each transaction in a database.”)
Reference1-Dang-Reference3 does not explicitly disclose displaying a map view that presents that plurality of location-associated transactions.
However, Tavares teaches displaying, in a user interface of the user device, a view of a map that includes the plurality of associations between the locations and the data transactions. (See Tavares [0196] “the computer system generates a report from the POS data and renders a graphical display on a display screen 1214… Display screen 1214 shows map 1202 along with an enhanced view of the geographical region 1216 of interest. A report 1218 displays growth and other information… the transaction growth, the average ticket growth, and the average annualized volume [Thus, a map view presenting the plurality of stored transactions together with the locations they are associated with].” See also Tavares [0019] “This numeric display may be superimposed over a map of the geographic region.” See also Tavares [0201] “the merchant may request… to have this information visually depicted on a map… The data on all merchants located within a given region may be stored in a database [Thus, the map is populated from the stored records].” See also Tavares [0202] “the merchant may request a report showing complementary businesses to be displayed on a map… the database may be searched.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Reference1-Dang-Reference3; which already queries its storage areas for a plurality of transactions and displays the results in the user interface, and renders maps in that interface, to incorporate the teachings of Tavares which renders aggregated transaction data over a map of the geography in which the transaction occurred.
One would be motivated to do so to make the location already held in the transaction record usable at a glance rather than record by record.
Regarding claim 19, Reference1-Dang-Reference3 in view of Tavares teaches all limitations and motivations of claim 18, further comprising: generating, by the user device, one or more data transaction insights based on the plurality of associations; and displaying, in the user interface, the one or more data transaction insights. (See Reference1 [0115] “a user may select the history mode 1010 to view a history of prior purchases and perform various actions on those prior purchases [Thus, based in part on the stored associations]… The wallet application may query the storage areas in the mobile device or elsewhere (e.g., one or more databases and/or tables remote from the mobile device) for transactions matching the search keywords… The user interface may then display the results of the query such as transaction 1015. The user interface may also identify the date 1012 of the transaction, the merchants and items 1013 relating to the transaction [e.g. generate one or more data transaction insights for display in a user interface displayed in a user interface].” See also Reference1 [0116] “the user may add the transaction to a group such as company expense, home expense, travel expense… Such grouping may facilitate year-end accounting of expenses, submission of work expense reports, submission for value added tax (VAT) refunds.” See also Reference1 [0117] “The history mode… may offer facilities for obtaining and displaying ratings 1019 of the items in the transaction.”)
Regarding claim 20, Reference1-Dang-Reference3 in view of Tavares teaches all limitations and motivations of claim 19, further comprising: generating, by the user device, one or more data transaction insights based on the plurality of associations; and displaying, in the user interface, the one or more data transaction insights. (See Reference1 [0115-0116], generating the displayed history and expense groupings from the stored transaction records. See also Reference3 [0020] “the GPS data geotagged into the image presents the location of the point of sale (POS) [e.g. the location of the non-transacting remote device].” See also Reference3 [0024] “a second, separate GPS information of the location of the user device at the time of transmitting the transaction information [e.g. a location of the user device during execution of the data transaction].” See also Reference3 [0033] “the payment provider can assess the validity of the purchase transaction by comparing the two pieces of GPS information [Thus, a derived result computed from the association together with both location values].” See also Reference3 [0036] “the payment provider may evaluate… the validity of the claimed transaction by further looking at the magnitude of the time difference… if the time difference… is bigger than a certain preset value of time, the payment provider may determine that the claimed purchase transaction is suspicious [Thus, a further derived result from the paired data].” See also Reference3 [0037] “the payment provider may further communicates the approval or rejection to the user on the user’s device [Thus, the derived result is returned for presentation].”)
Regarding claim 21, Reference1-Dang-Reference3 teaches all limitations and motivations of claim 1, wherein the content control module is further configured to generate a data transaction insight for presentation by the computing device based on the association that visually represents a relationship between the location of the non- transacting remote device and the location of the computing device during execution of the data transaction. (See Reference3 [0033] “the payment provider can assess the validity of the purchase transaction by comparing the two pieces of GPS information, one, embedded in a geotagged image telling the location of a payment instrument at the time of capture and geotagging, and the other, telling the location of the transmitting device at the time of transmission [Thus, the relationship between the performance location and the authorization location is determined].” See also Reference1 [0103] “the user may launch an aisle map 819 l which displays a map 819 m showing… the position of the user… the user may easily configure the map to add one or more other users (e.g., user’s kids) to share each other’s location.”)
Reference1-Dang-Reference3 does not explicitly disclose generating, for presentation, a data transaction insight that visually represents the determined relationship between two locations derived from stored transaction data.
However, teaches visually representing a spatial relationship between locations derived from stored transaction data. (See Tavares [0201-0202] “a merchant may be able to enter a request to see a graphical depiction of all similarly situation merchants within the region… and to have this information visually depicted on a map. In this way, the merchant can quickly see where the competing grocery stores are location [e.g. spatial relationship between the locations is visually represented]… the merchant may request a report showing complementary businesses to be displayed on a map… when a merchant wishes to see a report showing the location of complementary businesses, the database may be searched.” See also Tavares [0196] “Display screen 1214 shows map 1202 along with an enhanced view of the geographical region 1216 of interest.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Reference1-Dang-Reference3; in which Reference1’s wallet already renders maps within its user interface and plots on them the position of the user’s device and of other devices whose locations are shared, and queries the stored transaction records for display, to incorporate the teachings of Tavares which populate the map using the transaction location data.
One would be motivated to do so to effectively visualize and recognize the location at which a transaction was performed and where it was authorized.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Reference1-Dang-Reference3, and further in view of McGuire (US Patent Application Publication No. US 20210383440 A1).
Regarding claim 5, Reference1-Dang-Reference3 teaches all limitations and motivations of claim 4.
Reference1-Reference2 does not explicitly disclose wherein the one or more data transaction insights include one or more of a data transaction resource usage summary, or a data transaction location heatmap.
However, McGuire teaches generate data transaction insights that include a data transaction location heatmap. (See McGuire [0094] “venue management system 102 may communicate the message to user device 106 of the user based on the user conducting the payment transaction during the event, where the message include transaction data associated with the payment transaction.” See also McGuire claim 8 “receive a user request from the mobile device of the user, wherein the user request includes data associated with goods or services provided by a merchant attending the event… generate at least one message based on the current user location and the biometric data associated with the biometric of the user, the at least one message comprising… communicate heat map data associated with a heat map of a queue of a location of the merchant in the venue of the event to the mobile device of the user to cause the mobile device to display the heat map [Thus, generate data transaction insights that include a data transaction location heatmap]”)
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to modify Reference1- Reference2 to incorporate the teachings of McGuire of providing a heat map of a queue of a location of a merchant to a requesting user.
One would be motivated to do so to effectively provide an instant overview of key information for the user, enabling the user to make data-driven decisions.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OSCAR WEHOVZ whose telephone number is (571)272-3362. The examiner can normally be reached 8:00am - 5:00pm ET.
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, APU M MOFIZ can be reached at (571) 272-4080. 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.
/OSCAR WEHOVZ/Examiner, Art Unit 2161
/APU M MOFIZ/Supervisory Patent Examiner, Art Unit 2161
