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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 2/11/2025 was filed prior to examination. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Application Status
This Office Action is in response to Applicant’s response to the 03/03/2026 Restriction Requirement.
Applicant elected group I (corresponding to claims 1-9) without traverse.
Claims 1-20 are canceled.
Claims 1-9 are pending and have been examined.
This action is non-final.
Summary of Claim Rejections
Claims 1-91 are rejected under 35 U.S.C. § 101 for being directed to an abstract idea without significantly more.
Claims 1-92 are rejected under 35 U.S.C. § 103.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-9 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
As an initial matter, the relevant test is the Alice/Mayo test3. The following analysis provided in this section results from the instant application’s claims being examined within the scope of the Alice/Mayo test framework.
With respect Step 1 of Alice/Mayo analysis, the claims are either directed to a system, product of manufacture, or method. Therefore, each of the claims are directed to one of the four statutory categories of invention (Step 1 of Alice/Mayo Test: YES).
Based upon consideration of all relevant factors with respect to the claims as a whole, claims 1-9 are determined to be directed to an abstract idea of anonymously conducting a payment transaction. The rationales for the aforementioned determination are explained further below.
With respect Step 2A Prong I of Alice/Mayo analysis, claims 1-9 recite as a whole a method of organizing human activity because independent 1 recites:
“A method of anonymously conducting a secured payment transaction between a consumer and a merchant, the method carried out … in communication with an alias directory, the method comprising:
receiving… a request for a … transaction code from a merchant … wherein the request comprises a merchant alias identifier;
querying… an alias directory storing merchant information details;
validating… the merchant with the alias directory based on the merchant alias identifier;
generating…, the … transaction code; and
transmitting…, a response to the request for the dynamic transaction code to the merchant ….”
Under broadest reasonable interpretation consistent with the specification, these are recitations of commercial activities including anonymously conducting a payment transaction. Thus, the claims recite an abstract idea (Step 2A Prong I: Yes, the claims recite an abstract idea).
This judicial exception recited in independent claim 1 is not integrated into a practical application because, when analyzed under prong II of revised step 2A of the Alice/Mayo test:
The additional elements “…at a transaction code computer…”, “…, by a transaction code computer…”, “…dynamic…”, “by the transaction code computer”, and “…computer…” of claim 1 amounts to no more than mere instructions to implement the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05 (f), (h)), even when considering each claim’s additional elements both separately and as an ordered combination. See Alice Corp. v. CLS Bank International, 573 U.S. 208, 223-24 (2014): "… Stating an abstract idea "while adding the words ‘apply it’ " is not enough for patent eligibility. … Nor is limiting the use of an abstract idea " ‘to a particular technological environment.’ … Stating an abstract idea while adding the words "apply it with a computer" simply combines those two steps, with the same deficient result”.
An improvement in the abstract idea itself is not a technological solution to a technological problem (MPEP §§ 2106.05 (a), (a) II). See the following:
MPEP 2106.05(a) II: “… it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology … Merely adding generic computer components to perform the method is not sufficient.”
Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370 (Fed. Cir. 2015): “... our precedent is clear that merely adding computer functionality to increase the speed or efficiency of the process does not confer patent eligibility on an otherwise abstract idea.”
Customedia Techs. V. Dish Network Corp., 951 F.3d 1359, (Fed. Cir. 2020): “We have held that ‘claiming the improved speed or efficiency inherent with applying the abstract idea on a computer’ was insufficient to render the claims patent eligible as an improvement to computer functionality”.
In light of the above rationales provided for step 2A Prong II analysis, the Examiner respectfully submits the focus of the claims is not on an improvement in computers as tools, but rather on an abstract idea that uses computers as tools. Considered both separately and as an ordered combination, the additional elements of the independent claims do not integrate the abstract idea into a practical application, as they do no more than represent computers performing functions that correspond to (,i.e., implement,) the acts of the abstract anonymously conducting a payment transaction, and do not provide details such that one of ordinary skill in the art would recognize the claims as reflecting an improvement to the functioning of a computer or any other technology or technical field. (Step 2A Prong II of Alice/Mayo Test: NO, the additional elements do not integrate the judicial exception into a practical application). Accordingly, claim 1 is determined to be directed to an abstract idea (Step 2A of the Alice/Mayo Test: The claim is directed to an abstract idea).
When analyzed under step 2B, claims 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception. Claim 1, when viewed as a whole, do not include additional elements amounting to significantly more, as its elements, each viewed both individually and as an ordered combination, amount to no more than mere instructions to implement the abstract anonymously conducting a payment transaction concept within a particular technological environment, absent of any particular technological details that one of ordinary skill in the art would recognize the claimed invention as providing an improvement to the functioning of a computer or to any other technology or technical field – see MPEP §§ 2106.05 (a), (f), (h) and Alice Corp. v. CLS Bank International, 573 U.S. 208, 223-24 (2014). Even though claim 1 utilizes computer elements, the manner by which the claims’ additional elements are used is indistinguishable from mere addition of general-purpose computers added post-hoc to the abstract idea recited. Accordingly, the Examiner respectfully maintains the focus of the claims is not on such an improvement in computers as tools, but rather on abstract ideas that use computers as tools. Hence, none of the elements of the independent claims add significantly more to the abstract idea itself (i.e., an inventive concept), as merely employing computers as tools to automate and/or implement the abstract idea cannot provide significantly more than the judicial exception itself – see BSG Tech LLC vs. BuySeasons, Inc., 899 F.3d 1281, 1290 (Fed. Cir. 2018): “It has been clear since Alice that a Claimed invention’s use of the ineligible concept to which it is directed cannot supply the inventive concept that renders the invention ‘significantly more’ than that ineligible concept”.
Accordingly, independent claim 1 is not patent eligible.
With respect to the dependent claims, the dependent claims have been given the full analysis, including analyzing the additional limitations both individually and as an ordered combination (if any). The dependent claims, when analyzed both individually and in combination, are also held to be patent ineligible under 35 U.S.C. 101 because of the same reasoning as above, and because the claim limitations of the dependent claims fail to establish that the claims are integrated into a practical application or amount to significantly more. The rationales for the aforementioned determinations are explained further below.
With respect to dependent claims 2, 3, and 7 the additional limitations of the dependent claims, when considered individually and as an ordered combination, do not recite additional elements outside of the abstract idea that integrate the judicial exception into a practical application or amount to significantly more than the abstract idea, as the claims do not recite any further additional elements outside of the abstract idea and also do not indicate that the previously mentioned additional elements are successfully integrated / amounting to significantly more, either individually or as an ordered combination. For these reasons the dependent claims 2, 3, and 7 are also not patent eligible.
With respect to dependent claims 4 and 6, they recite further details of the abstract idea, save for the additional element, “…dynamic…”. The aforementioned additional element does no more than represent the use of computers as tools to perform the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05(f) & 2106.05(h)). Merely automating the abstract idea to try to make the process faster or more efficient does not integrate the abstract idea into a practical application or amount to significantly more. Accordingly, when considered as a whole, these claims do not improve the functioning of a computer, or to any other technology or technical field, do not integrate the judicial exception into a practical application, and do not amount to significantly more. Therefore, dependent claims 4 and 6 are also not patent eligible.
With respect to dependent claim 5, the additional limitations, when considered individually and as an ordered combination, do not recite additional elements outside of the abstract idea that integrate the judicial exception into a practical application, and do not amount to significantly more than the abstract idea. The claims fail to establish that the previously mentioned additional elements are successfully integrated / amounting to significantly more, either alone or in combination, and the additional element “…comprises a universal resource locator (URL) for the dynamic transaction code.” amounts to no more than mere instructions to implement the abstract idea by adding the words “apply it” (or an equivalent) – see MPEP § 2106.05(f). Accordingly, in view of the claims failing to establish that the aforementioned additional elements are successfully integrated / amounting to significantly more, either alone or in combination, the aforementioned dependent claims are not patent eligible subject matter.
With respect to dependent claims 8, it recites further details of the abstract idea, save for the additional element, “…from the merchant computer…”. The aforementioned additional element does no more than represent the use of computers as tools to perform the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05(f) & 2106.05(h)). Merely automating the abstract idea to try to make the process faster or more efficient does not integrate the abstract idea into a practical application or amount to significantly more. Accordingly, when considered as a whole, claim 8 does not improve the functioning of a computer, or to any other technology or technical field, does not integrate the judicial exception into a practical application, and does not amount to significantly more. Therefore, dependent claim 8 is also not patent eligible.
With respect to dependent claim 9, it does not recite any further abstract idea at step 2A Prong I. However, the additional element, “…where the dynamic transaction code is a dynamic quick response (QR) code”, does no more than represent the use of computers as tools to perform the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05(f) & 2106.05(h)). Accordingly, when considered as a whole, the claim does not improve the functioning of a computer, or to any other technology or technical field, does not integrate the judicial exception into a practical application, and does not amount to significantly more. Therefore, dependent claim 9 is also not patent eligible.
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 (i.e., changing from AIA to pre-AIA ) 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims rejected in view of Tran, in further view of Singh
Claims 1, 4, and 7-9 are rejected under 35 U.S.C. 103 as being unpatentable over United States Patent Publication No. US 11587054 B2 (Tran), in further view of US 10445629 B2 (Singh).
Claim 1
With respect to claim 1, Tran discloses a method of anonymously (Col 11, lines 23-18) conducting a secured payment transaction between a consumer and a merchant, (Col 1, lines 53 – Col 2, line 8);
See Col 1, lines 53 – Col 2, line 8, in further view of Col 11, lines 23-18. See also Fig. 11
the method carried out at a transaction code computer (“Payment Services Provider Computer” – see at least Fig. 6, refs 602 and 618, in further view of Col 5, lines 54-59: “…FIG. 6 is a block diagram of an example computer system 602 … computer system 602 may be operated by the payment services provider 202, and may accordingly be referred to hereinafter as a “payment services provider computer”) in communication with an alias directory (Fig. 6, ref 618), the method comprising:
See Col 5, lines 54-59, in further view of Fig. 6.
receiving, by a transaction code computer, a request for a dynamic transaction code from a merchant computer, wherein the request comprises a merchant alias identifier;
See Fig. 11, ref 1104: “…Transmit Request for QR Code”, in further view of at least:
Col 13, lines 29-38, disclosing wherein the request comprises a merchant alias identifier4: “At 1104 in FIG. 11, the merchant employee opens a QR application that runs on the POS device 400. The QR application receives the transaction amount and/or item description(s) from other software entities running on the POS device 400. The merchant employee interacts with the POS device 400 to cause the POS device 400 to transmit a request for a QR code to the payment services provider 202. The request contains at least an alias to identify the merchant that is transmitting the request and information related to the transaction, such as transaction amount.”
Col 13, lines 16-18, disclosing the flow of Fig. 11 corresponds to a flow where the QR code is a dynamic QR code: “…Processes that utilize a dynamic QR code will now be described, initially with reference to FIG. 11. …”
querying, by the transaction code computer, an alias directory storing merchant information details;
See Fig 11, ref 1122, in further view of at least Col 14, lines 3-11:
Col 14, lines 3-11: “At block 1122, the payment services provider 202 may append additional information to the payment request. The additional information may include the banking details (bank name/routing number and account number) for the merchant. This appending process may include retrieving such additional information from one or more directories (e.g., the directory 618, FIG. 6) stored by the payment services provider 202. The information appended at this point may also include the banking details for the user.)”
Examiner’s Note: Claim 1 does not require any particular order among the steps claimed – see ¶169 of Applicant Specification: “…With respect to the appended claims, those skilled in the art will appreciate that recited operations therein may generally be performed in any order. …”
validating, by the transaction code computer, the merchant with the alias directory based on the merchant alias identifier;
See Fig 11, ref 1118, in further view of associated disclosure (Col 13, lines 59-67), in further view of Fig. 11, ref 1122, and associated disclosure (Col 14, lines 3 - 11).
Col 13, lines 59-67: “Block 1118 may follow block 1116 in the process of FIG. 11. At block 1118, the (user's) mobile device 500 may transmit, to the payment services provider 202, a request for payment to be made to the merchant. The payment request may include the data (e.g., alias/proxy identifier) that identifies the merchant, as well as identifying information (again, perhaps an alias) for the user. The payment request also includes the transaction amount, as supplied to the user via the scanned QR code.”
Col 13, lines 59-67: “At block 1122, the payment services provider 202 may append additional information to the payment request. The additional information may include the banking details (bank name/routing number and account number) for the merchant. This appending process may include retrieving such additional information from one or more directories (e.g., the directory 618, FIG. 6) stored by the payment services provider 202. The information appended at this point may also include the banking details for the user.”
generating, by the transaction code computer, the dynamic transaction code; (Fig. 11, ref 1108, in further view of Col 13, lines 41-45: “At 1108, the payment services provider 202 generates the requested QR code. The QR code as generated by the payment services provider 202 may include the merchant alias/proxy identifier, transaction amount, description of purchased item(s) and geolocation information”) and
transmitting, by the transaction code computer, a response to the request for the dynamic transaction code to the merchant computer. (Fig. 11, ref 1110: “TRANSMIT QR CODE”, and associated disclosure in Col 13, lines 46-49: “At 1110, the payment services provider 202 transmits the QR code (as generated at 1108) to the POS device 400 (i.e., to the merchant).”)
While the examiner respectfully maintains Tran alone anticipates each and every claim limitation as mapped above, Examiner notes (a) Applicant may have intended the scope of the claims to correspond to each step being performed sequentially, even if not required by the claims, and (b) Applicant may argue the validating of Tran corresponding to steps 1118 and 1122 is not in-fact “…validating…”, and is more instead a “look-up”, or the like (of which the examiner respectfully disagrees, under broadest reasonable interpretation – particularly in view of ¶105 of Applicant Specification seemingly anonymizing the concepts: “…The dynamic transaction code engine 105 validates 716 the merchant identifier with the alias directory 106 using a merchant lookup API. …”).
Arguendo, examiner notes Singh, sharing the same Applicant as Tran, discloses:
validating, by the transaction code computer, the merchant with the alias directory (directory service) based on the merchant alias identifier (e.g., UUID) [before generating the QR code]
See at least ¶¶21, 22, 25,30, 56, and claim 1 of Singh:
¶¶21,22: “[¶21] … An X.509 certificate contains a public key and an identity (such as a hostname, or an organization, or an individual), … [¶22] In some embodiments according to this disclosure, each acquirer FI must not only register themselves but also must register their associated merchants to the directory service as part of the onboarding process. In order to register their associated merchants to the directory service, each acquirer FI provides merchant information that may include, but is not limited to, merchant identification data (i.e., merchant name, email address, phone number and the like), merchant location data (e.g., the merchant's business address), bank credentials (e.g., bank routing number and financial account number for receiving funds, payment card credential data, and/or debit credentials, and the like), a merchant category code (MCC), and a terminal identifier (which may be used for payment card transactions) to the directory service. After the acquirer FI provides all required information, the directory service generates a unique identifier, such as a unique “Merchant Identifier,” which facilitates the fast “look up” of merchant data during purchase transaction processing. In some implementations, the unique merchant identifier is generated using the UUID or “universally unique identifier.”
¶25: “… some embodiments, the directory service [a] performs identity verification of registered participants using X.509 certificates, [b] generates a secure one-way hash (for providing data integrity), [c] generates the secure QR code, and [d] transmits the secure QR code to the merchant for display so that it can be read by a consumer mobile device (such as a smartphone, tablet computer, personal digital assistant and the like) …”
¶30: “Referring again to FIG. 1, the merchant device 114 via the secure QR code app then establishes a connection to the directory service computer 106, and transmits the certificate (i.e., the acquirer-signed merchant certificate received during the onboarding process) to the directory service computer 106. the directory service computer 106 verifies the identity of the merchant by matching the merchant certificate to one stored in a memory (generated during the onboarding process), and establishes an encrypted and Pinned SSL tunnel between the secure QR code app of the merchant device 114 and the directory service computer 106 by using the certificate (which includes the acquirer FI-signed merchant certificate and the trusted third party signed acquirer certificate). The merchant device 114 then transmits a message via the Pinned SSL tunnel to the directory service computer 106, which message is dynamically created by using the transaction amount, the UUID [analogous to the claimed “alias”], and a transaction identifier. The transaction identifier (transaction ID) is a unique identifier assigned by the merchant (or the business) to each transaction that has been made with a payment card account. The transaction identifier uniquely identifies the transaction for the merchant, and use of the trusted and Pinned SSL tunnel provides non-repudiation of the transaction (also due to the use of the digital signature, which was provided by the directory service during onboarding).”
¶56: “…The directory service computer receives 502 an acquirer-signed merchant certificate from a merchant device. Next, if the acquirer signed merchant certificate does not match a stored certificate 504, then the directory service computer transmits 506 a request denied message to the merchant device, and the process ends….”
Claim 1: “A method for generating a dynamic secure QR code comprising: receiving, by a directory service computer from a merchant device, a secure QR code request comprising an acquirer financial institution (FI)-signed certificate; verifying, by the directory service computer, the identity of a merchant based on a match between the acquirer FI-signed certificate and a stored certificate; identifying, by the directory service computer, a merchant identifier (ID); establishing, by the directory service computer, an encrypted and Pinned SSL tunnel with the merchant device; receiving, by the directory service computer via the encrypted and Pinned SSL tunnel from the merchant device, a transaction message comprising a transaction amount, a universal unique identifier (UUID), and a transaction identifier (ID); generating, by the directory service computer, a Hash value; generating, by the directory service computer, a dynamic secure QR code by combining the Hash value, the transaction ID and the merchant ID; and transmitting, by the directory service computer, the dynamic secure QR code data to the merchant device to conduct a purchase transaction.”
Accordingly, it would have been rendered obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to have the network directory service of Tran check the requesting merchant’s identity via a more secure mechanism (e.g., the certificate mechanism of Singh’s), resulting in the method of Singh to perform validating, by the transaction code computer, the merchant with the alias directory based on the merchant alias identifier before generating the QR code, in order to advantageously increase the security of the solution of Tran, and to circumvent the security issue disclosed in Singh(¶6): “Most QR code hacks involve the hacker replacing the merchant's receiving account with the hacker's account without the knowledge of the merchant.”
Claim 4
With respect to claim 4, Tran in view of Singh renders obvious the method of claim 1. Tran does not disclose, but Singh additionally discloses:
wherein the response comprises a dynamic transaction code identifier.
See at least ¶¶21, 22, 25,30, 56, and claim 1 of Singh (shown in parent claim 1 mapping). See also ¶¶31, 33 (shown below). Examiner notes the same obviousness rationale of parent claim 1, applies herein, mutatis mutandis.
¶31: “… upon receipt of the message from the merchant device 114, the directory service computer 106 updates an Application Transaction Count (ATC) for the merchant, and generates a Hash value utilizing the merchant ID, merchant name, merchant location data, the transaction amount, the ATC, the UUID, and the transaction ID. … The directory service computer 106 then stores this Hash value and generates dynamic secure QR code data by combining the Hash, the transaction ID and the merchant ID. The dynamic secure QR code data is then transmitted to the merchant device 114, which displays the dynamic secure QR code 115 on a display screen (not shown) associated with the merchant device 114 for reading by a camera component (not shown) of the consumer's mobile device 104.”
¶33: “… the issuer FI computers 116B transmits a message containing the Hash, the transaction ID, and the merchant ID to the directory service computer 106 on the encrypted and Pinned SSL tunnel. The directory service computer 106 looks up the merchant using the merchant ID, validates the Hash (for security and data integrity purposes, to ensure that the data has not been tampered with), and identifies or verifies the transaction amount using the transaction ID. Once all is in order, the directory service computer 106 transmits the payment credentials and the transaction amount to the issuer FI computer associated with the consumer's payment card account (in this example, issuer FI computer 116B) via the encrypted tunnel. …”
Accordingly, it would have been rendered obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to incorporate the technique of Singh into the method of Tran, in order to advantageously guarantee data integrity (¶31).
Claim 7
With respect to claim 7, Tran in view of Singh renders obvious the method of claim 1. Tran additionally discloses:
onboarding, by the merchant computer, the merchant information details to the alias directory. (Col 8, lines 19-27)
Claim 8
With respect to claim 8, Tran in view of Singh renders obvious the method of claim 7. The following claim limitations are rejected under the same rationale as parent claim 7, mutatis mutandis:
wherein onboarding the merchant information details in the alias directory comprises:
Tran additionally discloses:
receiving, by the alias directory … a merchant payment option selection from the merchant computer; (Col 8, lines 11-27)
inserting, in the alias directory, account information related to the selected merchant payment option; (Col 7, lines 13-20)
and inserting, in the alias directory, merchant identification information. (Col 8, lines 11-27 and Col 8, lines 11-27)
Claim 9
With respect to claim 9, it is rejected under the same rationale as parent claim 1, mutatis mutandis.
Claims rejected in view of Trang and Singh, in further view of Kang
Claims 2, 3, and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Tran in view of Singh, in further view of Foreign patent document CN 110942297 A (Kang).
Claim 2
With respect to claim 2, Tran in view of Singh render obvious the limitations of parent claim 1. Tran additionally discloses:
The method of claim 1, wherein the request comprises transaction … information. (Fig 11, ref 1104, in further view of Col 13, lines 29-38 of Tran: “At 1104 in FIG. 11, the merchant employee opens a QR application that runs on the POS device 400. The QR application receives the transaction amount and/or item description(s) from other software entities running on the POS device 400. The merchant employee interacts with the POS device 400 to cause the POS device 400 to transmit a request for a QR code to the payment services provider 202. The request contains at least an alias to identify the merchant that is transmitting the request and information related to the transaction, such as transaction amount.”
While note required in the mapping, examiner notes ¶29 of Singh does not appear to be inconsistent with Tran in this regard: “…After entry of the total transaction amount, the cashier requests a dynamic QR code by, for example, pressing a “Request QR” button displayed on a touch screen. …”
Tran in view of Singh fails to disclose, but Kang discloses:
that the request includes …currency… information
See pages 3 and 4 of PDF translation supplied:
Pages 3-4 of Kang: “[page 3]…the terminal collection APP sends a two-dimensional code generation request to the server and sends payment parameters to the server… [page 4] … the payment parameters include but are not limited to … the currency …”
Accordingly, it would have been rendered obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention that the information related to the transaction of Tran would include the currency, as disclosed by Kang, in order to advantageously make known what currency the amount of Tran is denominated in, and to account for different currency types. The combination amounts to the use of a known data element in a known request to achieve a predictable result.
Claim 3
With respect to claim 3, Tran in view of Singh and Kang renders obvious the method of claim 2. Tran additionally discloses:
wherein the request comprises transaction amount information. (Fig 11, ref 1104, in further view of Col 13, lines 29-38 of Tran: “At 1104 in FIG. 11, … The request contains at least … information related to the transaction, such as transaction amount.” )
Claim 5
With respect to claim 5, Tran in view of Singh renders obvious the method of claim 4. Tran fails to disclose, but Singh discloses:
wherein the response [i.e., response including the QR code of Singh] comprises a universal resource locator (URL) for the dynamic transaction code.
See ¶5 of Singh: “…Conventionally, QR codes are used to store uniform resource locators (URLs) or other information that can be read by a camera component of a consumer's mobile device, which mobile device also includes a QR code application. …”, in further view of the prior mappings previously provided corresponding to the “…response..”.
Accordingly, it would have been rendered obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to that the response includes a URL for the dynamic transaction code, as that is how information within QR codes is conventionally provided, as explained by Singh.
While examiner maintains Tran in view of Singh alone renders obvious the method of claim 5, examiner notes, arguendo, that Kang discloses:
wherein the response comprises a universal resource locator (URL) for the dynamic transaction code.
See at least the following on pages 4-5 of the PDF (shown further below); see also refs S200 - S400 of translation (not shown below):
“… [page 5] if the verification is passed, generating a payment Token by using the Java UUID and binding the payment Token with the payment parameters to generate a record and storing the record in a database, and then returning a payment URL with the Token to the APP; JAVA UUID … can randomly generate a globally unique 32-bit string of numbers and letters … . [later, still in page 5] … the server acquires a payment Token in the payment URL, the payment interface verifies the validity of the payment parameter according to the Token query database, and if the verification is passed, the server acquires a payment platform source of the user,; …”
“[page 4] … The merchant terminal APP generates a payment two-dimensional code according to the payment URL and displays the payment two-dimensional code, and the content of the payment two-dimensional code is the payment URL; …”
Accordingly, it would have been rendered obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to modify the method of Tran in view of Singh with the technique of Kang, result in the response comprising a universal resource locator (URL) for the dynamic transaction code, in order to advantageously realize a one-code payment solution without providing two-dimensional codes of multiple payment companies (abstract of Kang), and to increase the safety of data transmission and storage involving those third party servers (e.g., see background on page 2 of PDF of Kang).
Claims rejected in view of Tran, Singh, and Kang, in further view of Dill
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Tran in view of Singh and Kang, in further view of US 20150032626 A1 (Dill).
Claim 6
With respect to claim 6, Tran in view of Singh and Kang renders obvious the method of claim 5. Tran in view of Singh and Kang additionally discloses wherein the response comprises … the dynamic transaction code (see mapping of the parent claims, mutatis mutandis).
PNG
media_image1.png
635
797
media_image1.png
Greyscale
Tran in view of Singh and Kang fails to disclose, but Dill discloses: … an expiry code for the dynamic transaction code … (See Fig. 4, refs 412, 408, 410, in further view of at least ¶11, ¶¶89, 108, and ¶¶6, 41, 55, 103 of Dill)
Accordingly, it would have been rendered obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to have the dynamic transaction tokens of Singh in view of Kang incorporate an expiry code, resulting in the response to in-turn comprise an expiry code for the dynamic transaction token, in order to advantageously increase the overall security of the QR code payments (e.g., by preventing stale QR codes from being functional, as they are higher risk than newly generated ones, to one of ordinary skill in the art).
Conclusion
The following prior art made of record is considered pertinent to applicant's disclosure:
Non-Patent Literature, “developer.visa.com” (Visa Developer)5.
United States Patent Application Publication No. US 20200027076 A1 (Sharma). The aspects drawn to certificate authentication are relevant (e.g., ¶¶37, 45, 54, 57, 128, 137, 169).
United States Patent Publication No. US 11416849 B1 (Dowling). At least Col 7, line 60 – Col 8, line 3 is relevant.
United States Patent Application Publication No. US-20170364910-A1 (Malhotra). At least the following is relevant: “[¶33] The alias directory 314 may map non-sensitive aliases to critical and sensitive account details. The alias directory 314 may be managed by a central trusted party … The sender of the funds transfer will only need the recipient's unique alias to send funds. In many cases the alias may be the recipient's phone number or email address, which may already be known to the sender, or which the recipient may not be reluctant to provide to the sender. … [¶65, in further view of Fig. 6] … At 606, the requestor/user may select an alias to represent the user's account details. The alias may be, for example, a phone number, an email address, a unique set of characters or a phrase or social media handle. The alias may then be mapped by the alias directory 314 to the user's account details. In some embodiments or use cases, the alias can be mapped to multiple accounts, though it may be advisable for a default account to be selected by the user. The default account may be the account that the alias directory 314 returns when a translation is requested. [¶73, in further view of Fig. 7] … At block 706, the alias is translated (e.g., at the alias directory 314, FIG. 3; e.g., at the request of the gateway computer 306) to the corresponding deposit account details. It will be assumed that the gateway computer 306 (or other computer performing like functions) is a trusted service provider with all relevant security and screening in place, and with secure communication channels with the alias directory 314. The translation of the alias at the alias directory 314 provides the required sensitive details (account details) needed by the system 300 to initiate and route a funds transfer. With this approach, all sensitive details needed in performing the funds transfer are maintained within trusted entities following stringent standards with respect to sensitive information. It will be appreciated that the alias is never used or usable to initiate a transfer of funds from the account represented by the alias. [¶85] In some embodiments, the merchant/merchant bank account may be indicated by an alias, until the same is translated as part of the transaction flow. [¶99, in further view of Fig. 10] … During the online interaction, the merchant may enter its identification details (name and address of merchant) and bank account details and may agree to terms and conditions of participating in the program. The merchant may then print out and display decals to inform customers of the merchant's participation in the optical-code-EFT acceptance program. …”. See also ¶13, suggesting a motivation for use: “By using an alias instead of the actual account details during potentially vulnerable communications between the funds transfer requester and his/her financial institution, the risk of compromise of the account details may be reduced.”
United States Patent Publication No. US 7848980 B2 (Carlson ‘980). At least Title, abstract, and following of claim 1 are pertinent: “…the personal alias allows the personal information of the payee to remain confidential; …”. See also Col 7, lines 57-65 indicating or otherwise reasonably suggesting an alias may correspond to more than one account.
United States Patent Publication No. US 8818882 B2 (Carlson ‘882). See title, abstract.
United States Patent Application Publication No. US 20130018779 A1 (Laquerre). At least ¶¶8-10, 31 are relevant for disclosing aspects drawn alias registration in a similar context.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK A MALKOWSKI whose telephone number is (313)446-6624. The examiner can normally be reached Monday - Friday, 9: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, Matthew Gart can be reached on (571) 272-3955. 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 3696
/MATTHEW S GART/Supervisory Patent Examiner, Art Unit 3696
1 I.e., the subject matter claimed.
2 I.e., the subject matter claimed.
3 See MPEP § 2106 I.
4 Examiner notes all subsequent underline emphasis is added by examiner, unless otherwise specified.
5 See PTO-892, items V-X.
Prosecution Insights