DETAILED ACTION
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.
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 .
Acknowledgements
This Office Action is in response to Applicant’s response filed on October 27, 2025 (“October 2025 Response”) which contained inter alia, claim amendments (“October 2025 Claims”) and “REMARKS” (“October 2025 Remarks”).
Claims 1-3, 7-10, and 14-17 are currently pending and have been examined.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-2, 7-9, and 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over Itwaru et al. (US 2014/0108252 A1)(“Itwaru”) in view of Labrou et al. (US 2005/0027543 A1)(“Labrou”), in view of Herring et al. (US 2014/0129231 A1)(“Herring”), and further in view of Kumar (WO 2017/006336 A1)(“Kumar”).
Claims 1, 8, and 15
As to Claims 1, 8, and 15, Itwaru discloses a computer-implemented method (“methods” [0007]) for secure, remote transaction authentication and settlement, the method comprising: ([0007]) /A system (“systems” [0007]) for secure, remote transaction authentication and settlement, the system comprising at least one server computer (“computer processor” [0015]) including at least one processor, the at least one server computer programmed and/or configured to ([0015]):/ A computer program product (“non-transitory computer readable medium,” Claim 1) for secure, remote transaction authentication and settlement, the computer program product comprising at least one non-transitory computer-readable medium including program instructions that, when executed by at least one processor (“computer processor,” Claim 1), cause the at least one processor to: (Claim 1)
receiving, with at least one processor of an authentication mediary system (transaction service 20) positioned communicatively between a user communication device (consumer mobile device 12) of a customer and a merchant communication device (“merchant 16 operating their computer device 17 (e.g. a merchant computer system including one or more servers, one or more desktop computers, one or more point of sale (POS) terminals, and/or one or more mobile devices)” [0044]) of a merchant (see Fig.1), from the merchant communication device, transaction data (transaction data 5) associated with a transaction to be completed between the merchant and the customer (consumer 18) via a point-of-sale (POS) terminal (“one or more point of sale (POS) terminals,” [0044])(“who requests…to include generic transaction data such as product data 206, merchant data 208 and/or specific transaction data 203 (further described below) from the transaction service 20.” [0044], “the merchant interface 8 also has an order generation module 60 used to collect the transaction 5 data (e.g. product data 206, merchant data 208, consumer data 209 and/or transaction data 210-see FIG. 3)for the plurality of products ordered/selected by the consumer 18 during interaction (e.g. online) with the merchant interface 8 via the computer device 12 (e.g. over the communications network 11)” [0195]), the transaction data comprising at least one of the following: a transaction cost (“pricing total” [0195]); a transaction description; a transaction time; a merchant identifier; or any combination thereof (“who requests…to include generic transaction data such as product data 206, merchant data 208 and/or specific transaction data 203 (further described below) from the transaction service 20.” [0044], see also [0195]);
generating, with the at least one processor (“the transaction service 20, for example, has the transaction interface 15 including the transaction processing system 80 and the OMRI or the sound code 3 processing system 90, such that the processing system 90 generates the OMRI 200 or the sound code 3 for the merchant 16 ( or directly for the consumer 18)” [0165]), (i) a unique identifier for the transaction and (ii) sound data encoding the unique identifier (“the sound code data 3 would contain (or otherwise reference) a merchant profile identifier 203…It is also recognized that the identifier 203 can be a unique identifier 203 of the transaction 5 (e.g. a unique transaction number) payment request” [0086], “the system 90 generates…the sound code data 3 for the merchant 16” [0049]), the sound data configured to cause an audio output device to produce a sound wave (“sound code data 3 (e.g. as generated by the merchant 16 directly as over an in-store sound system or on behalf of the merchant 16” [0035]) such that, when the sound wave is received by an audio input device (“sound recording equipment 130 in range of the sound code data 3 can be used to capture the sound code data 3.” [0051]), the sound wave is decodable to provide the unique identifier (“the consumer device 12 could be configured to decode or otherwise extract the sound-based transaction data from the sound code 3 (once captured by user interface 104---e.g. microphone)” [0028]);
storing, with the at least one processor in at least one database, the unique identifier in association with the transaction data (“Sound Code 3 contains or is otherwise associated with (e.g. via database 110 via a transaction interface 15 and/or via payment application 113 provisioned on the consumer device 12) sound-based transaction data and is used (as a lookup or index identifier (ID))…” [0028], “processing of the sound code 3 can be done by accessing the lookup table 63 of the transaction service 20 and/or a local lookup table 63 resident or otherwise accessible external to the transaction service 20, such that one or more portions of the audio signals of the sound code 3 are mapped/related to one or more portions of the information 201” [0194]);
communicating, with the at least one processor, the sound data to the merchant communication device to cause the sound wave to be produced at the POS terminal (“the sound code 3 can be displayed/played…or, in the case of a POS transaction, the display of the merchant POS Terminal or merchant device 17” [0128], “the merchant interface 8 could request or otherwise obtain the OMRI 200 (or sound code 3) pertaining to the transaction 5 directly from the transaction service 20” [0191]) for receipt and decoding by the user communication device (consumer device 12) of the customer (“…to be provided to the consumer 18 (e.g. as captured and processed by the consumer mobile device 12 and associated payment application 113)...the consumer device 12 could be configured to decode or otherwise extract the sound-based transaction data from the sound code 3 (once captured by user interface 104---e.g. microphone)” [0028]);
receiving, with the at least one processor (“transaction service 20…process the transaction 5 there-between upon receipt of the OMRI 200 or the sound code 3 (and/or information obtained from the OMRI 200 or the sound code 3 from the transaction application 113 provisioned on the computer device 12) from the consumer 18” [0165]) from the user communication device, the unique identifier (“the mobile application 113 can pass the…sound code 3 to the transaction interface 15 to initiate the purchasing process” [0134], “the sound code data 3 would contain (or otherwise reference) a merchant profile identifier 203…It is also recognized that the identifier 203 can be a unique identifier 203 of the transaction 5 (e.g. a unique transaction number) payment request” [0086]) that was decoded by the user communication device from the sound wave (“…to be provided to the consumer 18 (e.g. as captured and processed by the consumer mobile device 12 and associated payment application 113)...the consumer device 12 could be configured to decode or otherwise extract the sound-based transaction data from the sound code 3 (once captured by user interface 104---e.g. microphone)” [0028]);
in response to receiving the unique identifier that was decoded from the user communication device (“Step 6. The mobile application 113 can read the OMRI 200 and decode the data encoded in the OMRI 200 in order to extract the merchant data 208 (such as merchant ID, transaction ID, amount of purchase and any other pertinent information, etc.). In the case of the sound code 3, this can he interpreted using a lookup table 63 available to the application 113 or can be sent to the transaction service 20 (e.g. via the merchant interface 8) for interpretation by the transaction service 20 using the lookup table 63 available to the transaction service 20.” [0130]), communicating, with the at least one processor (“the transaction application 113 can be configured as a client application of the transaction service 20,” [0211]), at least a portion of the transaction data to the user communication device (“Step 13. The mobile application 113 displays (e.g. output data 217) a summary of the transaction 5 to be completed (e.g., amounts, quantities, merchant identity, etc.) on the Consumer’s mobile device 12.” [0137]);
receiving, with the at least one processor, a proof of authentication from the user communication device associated with a confirmation of the transaction (“Step 16. The Consumer 18 can select his/her preferred payment method and provide any optional additional payment authentication data, such as a PIN or password” [0140]);
after verifying the proof of authentication, receiving, with the at least one processor, user payment authorization data (“Order Form Data” [0143]) from the user communication device (“Step 19. Upon successful completion of the transaction, the mobile application 113 may prompt the Consumer 18 to send Order Form Data to the merchant 16” [0143], “Step 20. The Consumer can select “YES” and the mobile application 113 instructs the transaction interface 15 to send the Order Form Data to a Mobile Payment Application interface 8 running on the Merchant Transaction Server 17.” [0144]), the user payment authorization data comprising at least an account identifier associated with a customer transaction account (“Order Form Data- any Consumer information including, but not limited to, address, phone number, e-mail address, billing address, shipping address and date of birth.” [0258], “Payment Account- an account held by a Consumer with a financial institution, E-wallet provider, Credit Issuing Company, or the like” [0259], “Payment Account Information-information pertaining to a Payment Account, including but not limited to account numbers, account balances, passwords and PIN numbers.” [0260]);
corresponding, with the at least one processor (“transaction service 20…process the transaction 5 there-between upon receipt of the OMRI 200 or the sound code 3 (and/or information obtained from the OMRI 200 or the sound code 3 from the transaction application 113 provisioned on the computer device 12) from the consumer 18” [0165]) and based on the unique identifier received from the user communication device, the user payment authorization data with the transaction data (“the table 63 containing information 61 that is indexed or otherwise cross-referenced to the information 201, confirmation information denoting whether the transaction 5 has been successfully processed by the interfaces 8, 15 and/or the transaction processing system 14, transaction request messages from the computer device 12 requesting processing of the transaction 5 (including information 201 decoded from the OMRI 200 or otherwise obtained from the sound code 3 and/ or coded information 204 in or otherwise from the OMRI 200 in unencoded form), and any other network message described herein related to request and response messages for transaction 5 processing.” [0167]).
Itwaru does not directly disclose
receiving, with the at least one processor from the merchant communication device, a first sound profile of an environment of the POS terminal;
receiving, with the at least one processor from the user communication device, a second sound profile of an environment of the user communication device;
verifying, with the at least one processor, a location of the customer as proximal to the POS terminal, wherein verifying the location comprises: comparing the first sound profile to the second sound profile,
wherein generating the sound data comprises: determining, with the at least one processor, a frequency range of the sound wave that is nonoverlapping with a frequency range of the second sound profile associated with the environment of the user communication device, the frequency range determined to increase a likelihood of detection of the sound wave by the user communication device in the environment of the user communication device;
that the processor (transaction processing system 14) is an acquirer; and
generating, with the at least one processor, a transaction request to a processor associated with a merchant transaction account, the transaction request comprising the user payment authorization data and the transaction data for settlement of payment from the customer transaction account to the merchant transaction account for completion of the transaction.
Labrou teaches
an acquirer (“sends that message to the acquirer” [0053]), and
generating, with at least one processor, a transaction request (“merchant 104 generates its transaction view request and authorization and forwards its transaction view request and authorization and the consumer 102’s transaction view request and authorization to the STS 106.” [0212]) to a processor associated (“The Secure Transaction Server (STS 106) is responsible for deciding which transaction requests are legitimate and passes them to the payment service of a financial institution (preferably an Online Payment Service, or OPS, but which could also be a bank, a credit card processor, etc.) for further processing” [0119], [0120]) with a merchant transaction account, the transaction request comprising a user payment authorization data and transaction data for settlement of payment from the customer transaction account to the merchant transaction account for completion of the transaction (“merchant and consumer accounts” [0317], “The final function of the STS 106 included in the UPTF of the present invention is to ensure that a transaction request is securely passed to the financial institution for fulfillment.” [0121]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Itwaru by the features of Labrou, and, in particular, to include in Itwaru’s processor (payment platform/transaction processing system 14), the acquirer of Labrou, since the acquirer would help process the transaction for the merchant, and 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; and to include in Itwaru’s processor, the feature of generating a transaction request to a processor associated with a merchant transaction account, the transaction request comprising the user payment authorization data and the transaction data for settlement of payment from the customer transaction account to the merchant transaction account for completion of the transaction, as taught by Labrou, because this would provide added security to the transaction and help to ensure proper distribution of payment.
Herring teaches
receiving, with the at least one processor from the merchant communication device (“…the second communications device may be a point-of-sale computer or terminal” [0017]), a first sound profile of an environment of the POS terminal (“a second audio signal is generated by sound detected by the second microphone that is part of the second communications device” [0010);
receiving, with the at least one processor from the user communication device (“However, in other embodiments, the first communications device may be a mobile communications device while the second communications device is a type that is not considered to be mobile.” [0017]), a second sound profile of an environment of the user communication device (“A first audio signal is generated by sound detected by the first microphone that is part of the first mobile communications device” [0010]);
verifying, with the at least one processor, a location of the customer as proximal to the POS terminal, wherein verifying the location comprises: comparing the first sound profile to the second sound profile (“The service provider 102, for example, may then compare the two audio signals and authenticate the proximity of the first and second communications devices l0A, 10B.” [0027], “The service provider computer system may then determine whether the two communication devices heard the same sound by whether their audio signals match. If the audio signals match, then the two communications devices are determined to be in close proximity and a proposed electronic transaction may be completed” [0012], “assure that the electronic transaction is completed between the intended devices or parties, and avoid involving an unintended device or party.” [0011]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Itwaru/Labrou combination by the features of Herring and in particular to: include in Itwaru in the Itwaru/Labrou combination the features of: receiving, with the at least one processor from the merchant communication device, a first sound profile of an environment of the POS terminal; receiving, with the at least one processor from the user communication device, a second sound profile of an environment of the user communication device; and verifying, with the at least one processor, a location of the customer as proximal to the POS terminal, wherein verifying the location comprises: comparing the first sound profile to the second sound profile, as taught by Herring, because it would help “assure that the electronic transaction is completed between the intended devices or parties, and avoid involving an unintended device or party.” (Herring, [0011]).
Kumar teaches wherein generating sound data (“the second participating device 108 acknowledges the reception by emitting the audio signals in anti-duplication frequencies.” [0093]) comprises: determining, with at least one processor, a frequency range of the sound wave that is nonoverlapping with a frequency range of the second sound profile (“the audio signals are emitted from the first participating device 102” [0093]) associated with the environment of the user communication device (participating device 102)(“the audio signals emitted are anti-duplication signals and the audio signals are emitted in anti-duplication frequencies. Further, the anti-duplication frequencies are the frequencies that are different from the frequencies used for transmitting the payload data.” [0076], “the received audio signals are in anti-duplication frequencies, and the received audio signals include the transaction data, payload data, and the hardware information about the other participating device” [0077], as such, device 108 chooses anti-duplication frequencies for its emitted sound, which are frequencies that are different from those received from device 102), the frequency range determined to increase a likelihood of detection of the sound wave by the user communication device in the environment of the user communication device (“The frequency selector 308 chooses the frequency of the audio signal to be emitted to establish a secure channel. According to an embodiment herein, the frequencies are selected based on the proximity level detected and the quality of the audio signals received by the first participating device. According to an embodiment herein, the frequency is selected by comparing the received frequency with the set of pre-determined frequencies. The set of pre-determined frequencies are frequencies already used in case-scenarios, to ensure establishment of secure channel for enabling the financial transactions.” Page 28, Lines 16-23).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Itwaru/Labrou/Herring combination by the features of Kumar and in particular to: include in the generating of the sound data with the at least one processor of Itwaru of the Itwaru/Labrou/Herring combination the features of: determining a frequency range of the sound wave that is nonoverlapping with a frequency range of the second sound profile associated with the environment of the user communication device, the frequency range determined to increase a likelihood of detection of the sound wave by the user communication device in the environment of the user communication device, as taught by Kumar, because it would help to “ensure establishment of secure channel for enabling the financial transactions” (Kumar, Page 28, Line 23).
Claims 2, 9, and 16
The Itwaru/Labrou/Herring/Kumar combination discloses as discussed above.
Itwaru further discloses wherein the user payment authorization data is encrypted as received from the user communication device (“The mobile application 113 can open a secure encrypted communications channel with the transaction interface 15 (the transaction interface 15 running on transaction server 6) via the Internet 11 or other intermediary communications network. All further communication with the transaction interface 15 can be via this secure channel.” [0131]).
Itwaru does not directly disclose that the user payment authorization data is configured for decryption by the acquirer processor.
However, Labrou teaches the user payment authorization data is configured for decryption by the acquirer processor (acquirer processor is taught by the combination as discussed above)(“Every time that the user accepts a payment, essentially she uses the certificate as a digital signature for signing the "payment contract" sent by the merchant from the physical POS that she connect to in the store. The Merchant sends that message to the acquirer, who will decrypt…and then approve the payment…” [0053]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Itwaru/Labrou/Herring/Kumar combination by the feature of Labrou and in particular to include in Itwaru’s user payment authorization data, the feature that it is configured for decryption by the acquirer processor of Labrou, 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.
Claims 7 and 14
The Itwaru/Labrou/Herring/Kumar combination discloses as discussed above.
Itwaru further discloses in response to receiving an acknowledgment from the acquirer processor of the transaction being completed pursuant to the transaction request, communicating, with the at least one processor, a transaction confirmation message to the merchant communication device and/or the user communication device (“The transaction interface 15 can notify the merchant interface 8 on the merchant POS Terminal 17 of Transaction 5 completion by transmitting the Transaction information in a confirmation message” [0145], “The transaction interface 15 may also notify the mobile application 113 with the same or similar transaction 5 information as was transmitted to the merchant 16 (step 21).” [0153]).
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Itwaru in view of Labrou, in view of Herring, in view of Kumar, and further in view of Kumnick (US 2012/0221468 A1)(“Kumnick”).
Claims 3, 10, and 17
The Itwaru/Labrou/Herring/Kumar combination discloses as discussed above.
Labrou teaches the user payment authorization data is formatted and encrypted according to a predetermined ruleset (“all the workflows, security and transactions rely on using certificates. A certificate (assuming the existence of a Public Key Infrastructure, or PKI) is associated with a particular/specific banking account owned by the user; a user can have multiple certificates, each associated with a different account. Every time that the user accepts a payment, essentially she uses the certificate as a digital signature for signing the payment contract sent by the merchant from the physical POS that she connect to in the store. The Merchant sends that message to the acquirer, who will decrypt (with the help of the certificate authority) and then approve the payment” [0053]).
Itwaru and Labrou do not directly disclose that the user payment authorization data is formatted and encrypted according to a predetermined ruleset input by the acquirer processor.
Kumnick teaches user payment authorization data is formatted and encrypted according to a predetermined ruleset input by the acquirer processor (“The term ‘acquirer capture files’ may include files generated by a payment processing network or other computer apparatus from initial capture files received from a merchant access device or computer. The payment processing network generates acquirer capture files for a plurality of different acquirers based on preferences or rules for format and reception of capture files established by each acquirer. In embodiments of the invention, the acquirer capture files may be in the same format or may be in different formats.” [0051], “encryption is used to protect sensitive data. For example, transaction data can be encrypted at a merchant access device or merchant computer and decrypted by a payment processing computer.” [0146]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Itwaru/Labrou/Herring/Kumar combination by Kumnick and in particular to include in Labrou’s ruleset in the Itwaru/Labrou/Herring/Kumar combination, the feature that it is input by the acquirer processor, as taught by Kumnick, since this would provide added security to the transaction, and 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.
Response to Arguments
Applicant’s arguments filed on the October 2025 Remarks have been fully considered and addressed below.
On pages 13-14, Applicant argues that “ltwaru nowhere describes any step in which the transaction service returns transaction data to the consumer device upon decoding a sound code. Rather, the only transmission back to the consumer described in the reference occurs after the payment platform approves or denies the transaction (see, e.g., ltwaru, [0014]), which is fundamentally different from a data exchange triggered by a decoding event.” The Examiner respectfully disagrees. As discussed in the respective rejection, Itwaru discloses: in response to receiving the unique identifier that was decoded from the user communication device (“Step 6. The mobile application 113 can read the OMRI 200 and decode the data encoded in the OMRI 200 in order to extract the merchant data 208 (such as merchant ID, transaction ID, amount of purchase and any other pertinent information, etc.). In the case of the sound code 3, this can he interpreted using a lookup table 63 available to the application 113 or can be sent to the transaction service 20 (e.g. via the merchant interface 8) for interpretation by the transaction service 20 using the lookup table 63 available to the transaction service 20.” [0130]), communicating, with the at least one processor (“the transaction application 113 can be configured as a client application of the transaction service 20,” [0211]), at least a portion of the transaction data to the user communication device (“Step 13. The mobile application 113 displays (e.g. output data 217) a summary of the transaction 5 to be completed (e.g., amounts, quantities, merchant identity, etc.) on the Consumer’s mobile device 12.” [0137]).
On page 14, Applicant argues that Labrou does not teach the newly added limitations of “in response…receiving…a proof…after verifying…transaction account.” However, Labrou is not relied upon for those features; therefore, the argument is moot.
On pages 14-15, Applicant argues that Herring does not teach the newly added limitations of “in response…receiving…a proof…after verifying…transaction account.” However, Labrou is not relied upon for those features; therefore, the argument is moot.
On page 15, Applicant argues that Kumar does not teach the newly added limitations of “in response…receiving…a proof…after verifying…transaction account.” However, Labrou is not relied upon for those features; therefore, the argument is moot.
On page 15, Applicant argues that that combination of the cited references amounts to hindsight reasoning. In response to applicant's argument that the examiner’s conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971). As such, the argument is unpersuasive.
On pages 15-16, Applicant argues that the “references operate within distinct problem domains and employ mutually exclusive system architectures.” The Examiner respectfully disagrees. It has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, the references are all concerned with securing transactions.
On page 16, Applicant argues that the systems of the cited references are incompatible. The Examiner respectfully disagrees. As discussed in the respective rejection, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Itwaru/Labrou combination by the features of Herring and in particular to: include in Itwaru in the Itwaru/Labrou combination the features of: receiving, with the at least one processor from the merchant communication device, a first sound profile of an environment of the POS terminal; receiving, with the at least one processor from the user communication device, a second sound profile of an environment of the user communication device; and verifying, with the at least one processor, a location of the customer as proximal to the POS terminal, wherein verifying the location comprises: comparing the first sound profile to the second sound profile, as taught by Herring, because it would help “assure that the electronic transaction is completed between the intended devices or parties, and avoid involving an unintended device or party.” (Herring, [0011]). Furthermore, as discussed above, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Itwaru/Labrou/Herring combination by the features of Kumar and in particular to: include in the generating of the sound data with the at least one processor of Itwaru of the Itwaru/Labrou/Herring combination the features of: determining a frequency range of the sound wave that is nonoverlapping with a frequency range of the second sound profile associated with the environment of the user communication device, the frequency range determined to increase a likelihood of detection of the sound wave by the user communication device in the environment of the user communication device, as taught by Kumar, because it would help to “ensure establishment of secure channel for enabling the financial transactions” (Kumar, Page 28, Line 23).
On page 16, Applicant argues that “[t]he Office Action’s rationale for combining the references, provided on pages 10-13, are individually general and untethered to the actual combinations being advanced in the Office Action. None of the references recognizes or addresses a specific technical problem solved by Applicant: verifying co-location of user and POS devices through environmental sound profiles and encoding a non-overlapping acoustic identifier for the transaction.” The Examiner respectfully disagrees for the same reasons given in the respective rejections and for the reasons discussed above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MONICA A MANDEL whose telephone number is (571)270-7046. The examiner can normally be reached Monday and Thursday 10:00 AM-6:00 PM.
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, Ilana Spar can be reached at (571) 270-7537. 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.
/M.A.M/Examiner, Art Unit 3622
/ILANA L SPAR/Supervisory Patent Examiner, Art Unit 3622
Prosecution Insights