DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on May 8, 2026, and is made Non-Final. This action is being examined by James H. Miller, who is in the eastern time zone (EST), and who can be reached by email at James.Miller1@uspto.gov or by telephone at (469) 295-9082.
Interviews
Interviews are “indispensable to advance the prosecution of a patent application.” MPEP § 713. Accordingly, the following Examiner’s guidance and suggested workflow maximizes this benefit to Applicant by: (1) avoiding back and forth telephone calls for scheduling, (2) permitting Examiner out-of-office notifications to the Applicant when sending the agenda, and (3) permitting real-time document collaboration and screen sharing.
Interviews are available by telephone or, preferably, by video conferencing using the USPTO’s web-based collaboration platform. Applicants are strongly encouraged to schedule via the USPTO Automated Interview Request (AIR) portal at http://www.uspto.gov/interviewpractice. If an interview is needed more quickly than permitted by the AIR scheduling tool, note this in the AIR remarks for consideration. The Examiner routinely considers such urgent requests when practicable.
An agenda submitted when filing the AIR is strongly encouraged, because Examiners use agendas when determining whether to grant an interview. The AIR has character limits, so send the agenda contemporaneously to James.Miller1@uspto.gov and reference the AIR.
After-Final Interviews Requests are granted only at the Examiner’s discretion and only if disposal or clarification for appeal may be accomplished with only nominal further consideration. MPEP § 713.09. An advance agenda explaining how the interview advances prosecution—e.g., through targeted arguments, identified Examiner error, or proposed claim amendments—is strongly suggested.
For GRANTED requests, expect an email within two (2) business days confirming a date/time slot and collaboration tool access instructions. For DENIED requests, the record will include an explanation for the denial.
The examiner is generally available for interviews, Monday through Friday, 10:00 a.m. to 4:00 p.m. ET.
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 May 8, 2026, has been entered.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Claim Status
The status of claims is as follows:
Claims 1–7 and 9–12 are pending and examined with Claims 1, 7, 9, and 10 in independent form.
Claims 1, 2, 7, 9, and 10 are presently amended.
No Claims are presently cancelled or added.
Response to Amendment
Applicant's Amendment has been reviewed against Applicant’s Specification filed Apr. 14, 2025, [“Applicant’s Specification”] and accepted for examination.
Applicant's Amendment to address objections to the drawings has been reviewed and has overcome each and every objection to the disclosure previously set forth in the Final Office Action mailed Mar. 9, 2026, [“Final Office Action"]. The objection to the drawings is withdrawn. The replacement drawings are acknowledged and entered.
Applicant's Amendment to address claim objections has been reviewed and has overcome each and every objection to the claims previously set forth in the Final Office Action. The objection to Claim 1 is withdrawn.
Response to Arguments
35 U.S.C. § 101 Argument
Applicant argues that the amended claims are a technical improvement that achieves “replay resistance through invalidation of processed transaction codes” and that the transaction code “functions as a one time cryptographic event identifier … consumed upon successful execution and cannot be reused.” Applicant’s Reply at 12–13.
Applicant’s argument is not persuasive.
These asserted technical effects are not commensurate with the claim scope. The claims do not recite invalidation of any transaction code. Invalidation is only described in the specification using an unclaimed timestamp. Spec. ¶¶ 75, 79. The claims do not recite any “cryptographic event identifier” or operation. The specification discloses that the transaction code may be an “epoch second or a sequential number.” Spec. ¶ 55. Arguments based on features not recited in the claims cannot demonstrate an technological improvement, practical application, or inventive concept. To the extent Claim 1 recites deleting the transaction code after the balance increases, that step forms part of the abstract idea as explained below. As amended, Claim 1 is distinguished from the “invalidation” mechanism described in the Specification, ¶¶ 75, 79.
Applicant argues the amended claims are directed to a “technical control mechanism” and not a business method. Applicant’s Reply at 11–12.
Applicant’s argument is not persuasive.
Generating a code for a transaction, comparing a presented code against a stored code before crediting payment, and retiring the code once settled is a fundamental economic practice and fraud mitigation process. It is the electronic equivalent of redeeming a single-use paper coupon or gift certificate, where the merchant verifies coupon matches the current offer or the merchant verifies the gift certificate is valid, and honors each once, and collects or marks it so it cannot be redeemed again. Applicant’s own specification teaches the purpose in bookkeeping terms: preventing the balance from being increased “more than once for the same transaction,” Spec. ¶ 84, and “prevent[ing] fraud where, when another mobile terminal that is not involved in the transaction.” Spec. ¶ 85. The amended limitations therefore further narrow or define the abstract idea.
Applicant remaining arguments about integrating any exception into a practical application are not persuasive. Applicant’s Reply at 13–15. Notwithstanding any alleged technical solution is not recited by the claims (as explained above), the asserted technical problem of an inability to transact without a network, Spec. ¶ 5, is a commercial problem and the “maintaining state consistency between distributed terminals” does not appear in the disclosure. MPEP § 2145(I) ("Attorney argument is not evidence."). The claimed solution does not improve any terminal, camera, display, code format, or network. Each component performs its conventional function. Spec. ¶¶ 54, 58. The code is generated “using a publicly known method.” Spec. ¶ 73. Additionally, confining the transaction to an offline situation is merely a field of use limitation. MPEP § 2106.05(h). The abstract idea itself cannot furnish a practical application or inventive concept. Applicant’s reliance on Electric Power Group to distinguish the pending claims is unavailing. The claims collect information (reading codes), analyze it (matching codes), and act on it through routine data operation, such as updating a balance and deleting a stored value, all at a high level of generality. The claim language does not explain how the transaction start image is generated, or how the start image is different from pre-computer methods and does not provide any specific showing of what is inventive about the code or about the technology used to create the code. See, MPEP § 2106.05(a), citing Secured Mail Solutions, LLC v. Universal Wilde, Inc., 873 F.3d 905, 910-11, 124 USPQ2d 1502, 1505-06 (Fed. Cir. 2017) (“Affixing a barcode to a mail object in order to more reliably identify the sender and speed up mail processing, without any limitations specifying the technical details of the barcode or how it is generated or processed.”). An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III).
Applicant argues the combination of code generation, matching, and deletion is not well-understood, routine, or conventional (“WRC”). Applicant’s Reply at 15–16.
Applicant’s argument is not persuasive.
The asserted inventive concept is the abstract idea itself. The additional elements of generic terminals, cameras, displays, memories, and publicly known codes are conventional per Applicant’s own disclosure. Spec. ¶¶ 54, 58, 64, 65, 73. The ordered combination adds only the sequence in which the abstract steps are performed.
35 U.S.C. § 103 Argument
Applicant’s arguments with respect to Claims 1–7 and 9–12 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Objections
Claims 1, 7, 9, and 10 are objected to because of the following informalities. Appropriate correction is required.
Claim 1: It is believed that “the first image reding device” in Limitation C2 below, is “the first image reading device” to correct a typographical error.
Claim 1: It is believed that “acquire the transaction code the data of the transaction amount” in Limitation C3 below is “acquire the transaction code and the data of the transaction amount” to correct a grammatical error.
Claims 1, 7, 9, and 10: It is believed that “increase balance of the balance data stored in the second storage memory according to the transaction amount” in Limitation D4 below is “increase balance of the balance data stored in the second
Claim 9: It is believed that “a unique transaction code generate for each monetary transaction” is “a unique transaction code generated for each monetary transaction” to correct a grammatical error.
Claims 9 and 10: Amendments have a verb-form inconsistency with the amendments. The claims use the gerund form (e.g., storing, displaying) but amendments use the imperative form (determine whether … increase …delete).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1–7 and 9–12 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.
Claims 1–7 and 9–12: Independent Claims 1, 7, 9, and 10 recite "the transaction code stored in the second information terminal." There is insufficient antecedent basis for this limitation in the claims because there is no step storing a transaction code in the second information terminal. The second memory is recited as storing only "balance data." In Independent Claim 10, the lack of antecedent basis is additionally confusing because the second information terminal is not recited as generating or receiving any transaction code, rendering it unclear what stored code is compared in the amended determining step. All Dependent Claims are rejected as being dependent from a rejected Independent Claim.
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–7 and 9–12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Analysis
Step 1: Claims 1–7 and 9–12 are directed to a statutory category. Claims 1–6, 11, and 12 recite a “system” and are therefore directed to the statutory category of a “machine.” Claim 7 recites a “terminal” and are therefore directed to the statutory category of a “machine.” Claim 9 recites “A non-transitory storage medium” and is therefore directed to the statutory category of an "article of manufacture.” Claim 10 recites a “method” and is therefore, directed to the statutory category of a “process.”
Representative Claim
Claim 1 is representative [“Rep. Claim 1”] of the subject matter under examination. Normal font is used for limitations that recite the judicial exception. Bold font is used to indicate additional elements evaluated under Step 2A, Prong Two (practical application) and Step 2B (significantly more). Italics font is used where necessary to identify intended use limitations1 and underline font is used, as needed, in further describing the judicial exception. Each limitation is identified by a letter designator for use as a shorthand notation when analyzing/referencing each limitation. Rep. Claim 1 recites:
[A] 1. A monetary transaction system comprising: a first information terminal having a first image display device and a first image reading device; and a second information terminal having a second image display device and a second image reading device, wherein the monetary transaction system executes a monetary transaction based on monetary data between the first information terminal and the second information terminal in a situation of an inability of the first information terminal to connect to a communication network,
[B] wherein the second information terminal includes a second processor configured to display, on the second image display device, a unique transaction code generated for each monetary transaction and transaction start image information including data of a transaction amount of the monetary transaction,
[C] the first information terminal includes:
[C1] a first memory configured to store balance data belonging to the first information terminal;
[C2] a first processor configured to cause the first image reding device to read the transaction start image information displayed on the second image display device of the second information terminal;
[C3] acquire the transaction code the data of the transaction amount from the transaction start image information read by the first image reading device;
[C4] when a user of the first information terminal gives approval for payment of the transaction amount, reduce balance of the balance data stored in the first memory according to the transaction amount; and
[C5] when reduction of the balance of the balance data has been completed, display payment completion image information including the transaction code on the first image display device, the payment completion image information is not an image indicating that the balance of the balance data has increased at the second information terminal, but an image to make the second information terminal detects that balance of the balance data has decreased at the first information terminal,
[D] the second information terminal includes:
[D1] a second memory configured to store balance data belonging to the second information terminal; wherein
[D2] the second processor configured to cause the second image reading device to read the payment completion image information displayed by the first information terminal;
[D3] determine whether the transaction code included in the payment completion image information matches the transaction code stored in the second information terminal, and
[D4] when the transaction codes match, increase balance of the balance data stored in the second storage memory according to the transaction amount, and
[D5] when the increase in the balance of the balance data has been completed, delete the transaction code stored in the second information terminal.
Claims are directed to an abstract idea exception.
Step 2A, Prong One: Rep. Claim 1 recites “A monetary transaction system” to “execute[ ] a monetary transaction based on monetary data” in Limitation A, “when a user … gives approval for payment of the transaction amount, reduce balance of the balance data … according to the transaction amount,” in Limitation C4, “when the transaction codes match, increase balance of the balance data … according to the transaction amount” in Limitation D4, and “when the increase in the balance of the balance data has been completed, delete the transaction code” in Limitation D5, which recite commercial or legal interactions under the organizing human activity exception because a “monetary transaction” for “payment” recites “sales activities or behaviors and business relations” between two parties (a buyer and seller). MPEP § 2106.04(a)(2)(II)(B). Limitations B, C1, C2, C3, C4, C5, D1, D2, D3, D4, and D5 apart from the generic computer limitations in bold are the required steps and data inputs to “execute[ ] a monetary transaction based on monetary data” and therefore, recites the same exception. Id.
Alternatively, Limitations B, C1, C2, C3, C4, C5, D1, D2, D3, D4, and D5 recite a fundamental economic principle/practice under the organizing human activity exception because said Limitations describe concepts relating to the economy and commerce, such as bookkeeping, a practice long prevalent in our system of commerce and taught in any introductory accounting class. MPEP § 2106.04(a)(2)(II)(A). This grouping expressly includes mitigating risk. Limitations B, D3, D4, and D5 are the electronic equivalent of redeeming a single use paper coupon or numbered gift certificate that is verified, honored once, and collected or marked upon redemption to prevent a second redemption.
Alternatively2, Limitations B, C1, C2, C3, C4, C5, D1, D2, D3, D4, and D5, as drafted, recite the abstract idea exception of mental processes that under the broadest reasonable interpretation, cover performance in the human mind or with pen and paper, but for the recitation of the generic computer components indicated in bold. MPEP § 2106.04(a)(2)(III).
Claims recite a mental process when they contain limitations that can practically be performed in the human mind, including for example, observations, evaluations, judgments, and opinions. Examples of claims that recite mental processes include:
• a claim to "collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016);
. . .
• a claim to collecting and comparing known information (claim 1), which are steps that can be practically performed in the human mind, Classen Immunotherapies, Inc. v. Biogen IDEC, 659 F.3d 1057, 1067, 100 USPQ2d 1492, 1500 (Fed. Cir. 2011).
MPEP § 2106.04(a)(2)(III)(A). For example, but for the generic computer components claim language, here, Limitations B, C1, C2, C3, C4, C5, D1, D2, D3, D4, and D5, recite collecting information (Limitations B, C1, C2, C3, D1, D2) analyzing it (Limitations C4, D3, D4, D5) and displaying certain results of the collection and analysis (Limitations B, C5), where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind. For example, Limitation C4 is a mental process that is practically performed in the human mind or with pen and paper because it requires mere “observation, evaluation, judgment, and/or opinion” to “give[ ] approval for the payment of the transaction amount,” and “reduce the balance data … according to the transaction amount” in any known way, including mental processes, as a buyer does when approving a purchase and subtracting the price from a balance recorded in a paper ledger or checkbook register. Likewise, Limitation D3 is a mental process that is practically performed in the human mind or with pen and paper because collecting and comparing known information (i.e., the transaction code) is a step that can be practically performed in the human mind under Classen. Likewise, based on the matching in Limitation D3, Limitations D4 and D5 are mental processes that are practically performed in the human mind or with pen and paper because they require mere “observation, evaluation, judgment, and/or opinion” to increase balance of the balance data … according to the transaction amount” (Limitation D4) and “when the increase in the balance of the balance data has been completed, delete the transaction code” (Limitation D5). Deleting the used transaction code is electronic equivalent of crossing a redeemed entry off a handwritten ledger. See NPL, Aday, Mike, “Country Store Ledgers Provide an Intimate Look at Lives from the Past,” May 8, 2018) (cited on PTO-892).
If a claim limitation under BRI, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract idea exception. MPEP § 2106.04(a)(2)(III). Accordingly, the pending claims recite at least one of the abstract idea exceptions, individually, or in combination.
Step 2A, Prong Two: The additional elements identified in Rep. Claim 1, considered individually and as an ordered combination, do not integrate the abstract idea exception into a practical application. MPEP § 2106.04(d).
The additional elements are limited to the computer components and those indicated in bold, supra. The additional elements are: A monetary transaction system comprising: a first information terminal [mobile computer] having a first image display device [mobile device display screen], a first image reading device [camera], first memory, and a first processor and a second information terminal [mobile computer] having a second image display device [mobile device display screen], a second image reading device [camera], second memory, and a second processor, input device (Claim 7) [mobile device touch screen]; in a situation of an inability of the first information terminal to connect to a communication network.3
Field of Use Limitations do not amount to a practical application.
The claim element “in a situation of an inability of the first information terminal to connect to a communication network” is mere field of use, MPEP 2106.05(h) and does not, alone or in combination, supply a practical application because it merely describes the environment in which the monetary transaction occurs and adds no structure to and does not alter the operation of either terminal.
The additional elements do not improve the functioning of a computer or other technology. MPEP § 2106.05(a).
A claim improves technology only when it recites a specific improvement to the way a computer itself operates, not merely the application of an existing process using a computer. MPEP § 2106.05(a) (citing Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1336 (Fed. Cir. 2016)). Here, the abstract idea exception was previously performed manually. Spec. ¶¶ 53, 91 (analogizing the claimed transaction to “a monetary transaction purely by an actual currency” and identifying uses such as “splitting a food and beverage bill, settlement of group travel expenses among the members, lump-sum collection of donations or the like, sending money to family, payment of reward, and the like.”). Because the process can be performed manually, the computer is not being improved and is merely being used as a tool to perform the pre-existing manual process. Applying a pre-existing manual process using generic computer components is not an improvement to computer technology. MPEP § 2106.05(a) (citing Credit Acceptance Corp. v. Westlake Services, 859 F.3d 1044, 1055, 123 USPQ2d 1100, 1108-09 (Fed. Cir. 2017) (“Mere automation of manual processes, such as using a generic computer to process an application for financing a purchase” is not an “improvement in computer-functionality.”)
The specification confirms this characterization by describing the advantages of the claimed system in terms of business outcomes (completing a monetary transaction where no network is available, confirming that payment has been completed, and preventing duplicate crediting and fraud for the same transaction), rather than in terms of any specific technical improvement to the computer, GUI, server, mobile device, or network infrastructure itself. Spec. ¶¶ 6, 41, 56, 61, 84, 85. The specification does not describe any specific technical improvement to image-code generation or reading, image analysis methods, network communication protocols, authentication, display technology, rendering algorithms, data structures, or computer architecture, and the encryption and code-obfuscation techniques mentioned are optional, admittedly known (e.g., RSA) and unclaimed. Spec. ¶¶ 55, 63, 65, 71, 73. Further, the specification describes the GUI elements (amount-input screen, top-up screens, payment button, payment confirmation pop-up, and code-display screens) only at a high functional level without any unconventional technical mechanism. Spec. ¶¶ 55, 59–61, 76, 78, Figs. 4–7. Thus, these are generic GUI elements. Any improvements describe business outcomes, not technical improvements to the computers themselves.
The additional elements do not apply the abstract idea with a particular machine.
Although the claims recite specific hardware components (i.e., information terminals, processors, memories, image display devices, image reading devices, and an input device (Claim 7)), these components are recited at a high functional level and perform only their generic functions of receiving, transmitting, storing, and processing data. Spec. ¶¶ 54, 58, 64. A machine is “particular” only when it imposes a meaningful limit on the claim’s scope. MPEP § 2106.05(b). Here, any general-purpose smartphone, tablet, or laptop computer with a camera and display would satisfy the claim’s hardware requirements, which confirms that the hardware components are generic rather than “particular.” MPEP § 2106.05(b). The specification describes each computer component using broad, open-ended language without restricting the claimed hardware to any particular design, configuration, or architecture. Spec. ¶ 54, 58, 90, 92.
The additional elements are (1) mere instructions to apply the abstract idea exception. MPEP § 2106.05(f), (2) generally link the judicial exception to a particular technological environment, mobile terminal without network connectivity, MPEP § 2106.05(h); and/or (3) are insignificant extra-solution activity; MPEP § 2106.05(g).
Regarding the additional elements, Applicant’s Specification does not otherwise describe them with specificity beyond exemplary language or describes them as a general-purpose computer, as a part of a general-purpose computer, or as any known and exemplary (generic) computer component known in the prior art. The specification’s own broad, exemplary characterization confirms that these components are not described in a manner that would impose any specific technical limitation that would integrate the abstract idea into a practical application. Thus, Applicant takes the position that such hardware/software is so well known to those of ordinary skill in the art that no explanation is needed under 35 U.S.C. § 112(a). Lindemann Maschinenfabrik GMBH v. Am. Hoist & Derrick Co., 730 F.2d 1452, 1463 (Fed. Cir. 1984) (citing In re Meyers, 410 F.2d 420, 424 (CCPA 1969) (“[T]he specification need not disclose what is well known in the art”). Every claimed component is a standard commercially available feature of any modern smartphone. The terminals are identified as generic consumer devices. Spec. ¶ 54 (“The seller-side terminal 10 is an information terminal such as a smartphone, a tablet, or a laptop computer carried by the seller, and as illustrated in FIG. 3, includes a camera 11, a communication unit 12, a display 13, an input unit 14, a storage unit 15, and an operation unit 16 … a touch display that combines the display 13 and the input unit 14 may be used.”); ¶ 58 (The buyer-side terminal 20 is an information terminal such as a smartphone, a tablet, or a laptop computer carried by the buyer, and as illustrated in FIG. 3, includes a camera 21, a communication unit 22, the display 23, an input unit 24, a storage unit 25, and an operation unit 26. … a touch display that combines the display 23 and the input unit 24 may be used.”). The claimed components perform only their conventional functions. - The camera 11 "performs reading of an information code" (i.e., captures an image — a standard camera function). The communication unit 12 "communicates with the server 30" (standard networking). The display 13 "displays, on a screen, an information code 41" (standard screen output). The input unit 14 "allows the seller to input the transaction information" (standard user input). The storage unit 15 "stores a program" and "balance data" (standard data storage). Spec. ¶¶ 54, 58. Software operates as a standard “app,” confirming the invention is implemented as a conventional software application on a generic device. Spec. ¶¶ 54, 58. Information codes use publicly known methods, confirming the image-code mechanism relies on well known, publicly available encoding standards. Spec. ¶¶ 65, 73 ("a color QR code is generated and displayed as an information code 41 … and the color QR code can be generated using a publicly known method", which is an admission that the code-generation technique is conventional). Face authentication uses publicly known methods, which confirms the identity authentication step adds no technical novelty to the hardware or its operation. Spec. ¶ 71. The server is generic. Spec. ¶ 64. The communication network is generic. Spec. ¶¶ 52, 54, 58. The transaction code itself is generated by known means. Spec. ¶ 55.
The generic terminal, here, performs calculations (functions) and executes instructions that are programmed by software directed to the abstract idea. Spec. ¶¶ 54, 58. This is a computer doing what it is designed to do—performing directions it is given to follow, and whose directions are directed to the abstract idea.
The displaying and user interface steps, Limitations B and C5, do not provide a practical application because they merely describe the field of use and technical environment in which the abstract idea is implemented, and constitute insignificant extra-solution activity (mere output of the collection and analysis), without resulting in an improvement to the computer or GUI itself. MPEP §§ 2106.05(h), (g) (citing Electric Power Group). The specification confirms that the GUI elements are described only at a high, functional level without any specific technical improvement to the GUI or display technology. E.g., Spec. ¶¶ 55, 59–61, 76, 78, Figs. 4–7. Further, requiring the use of software to tailor information and provide it to the user on a generic computer also does not provide a practical application. MPEP § 2106.05(f) (citing Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370-71, 115 USPQ2d 1636, 1642 (Fed. Cir. 2015)).
Limitation A describes the computer hardware performing the steps of the claimed invention, Limitations B, C1, C2, C3, C4, C5, D1, D2, D3, D4, and D5, which represents the abstract idea exception itself on a general-purpose computer. Performing the steps of the abstract idea exception using a computer, merely adds a general-purpose computer after the fact to an abstract idea exception without imposing any meaningful technical limitations. MPEP § 2106.05(f)(2). Alternatively, the claim generically recites an effect of the abstract idea without specifying how the computer achieves that effect in any technically meaningful way. MPEP § 2106.05(f)(3).
Therefore, the claim as a whole, considering the additional elements individually and as an ordered combination, amounts to no more than mere instructions to apply the abstract idea using generic computer components and is not a practical application. MPEP § 2106.05(f). The additional elements do not integrate the abstract idea exception into a practical application because they do not impose any meaningful limits on the abstract idea exception. Accordingly, Rep. Claim 1 is directed to an abstract idea.
Independent Claims 7, 9, and 10 are not substantially different from Rep. Claim 1, recite the same abstract idea as Rep. Claim 1, and contain no additional elements not otherwise analyzed for Rep. Claim 1. Therefore, Independent Claims 7, 9, and 10 are also directed to the same abstract idea.
The claims do not provide an inventive concept.
Step 2B: Rep. Claim 1 fails Step 2B because the claim as a whole, even when considering the additional elements individually and in combination, does not amount to significantly more than the abstract idea. MPEP § 2106.05. The additional elements (i.e., A monetary transaction system comprising: a first information terminal [mobile computer] having a first image display device [mobile device display screen], a first image reading device [camera], first memory, and a first processor and a second information terminal [mobile computer] having a second image display device [mobile device display screen], a second image reading device [camera], second memory, and a second processor, input device (Claim 7) [mobile device touch screen]; in a situation of an inability of the first information terminal to connect to a communication network), are each well-understood, routine, and conventional (“WRC”) computer components and functions in the relevant field, as evidenced by Applicant’s own disclosure4. Further, Applicant’s Specification discloses that these components operate in no particular order and are implemented using generic, off-the-shelf computing technology. Spec. ¶¶ 52, 54, 58, 64, 65, 71, 73 (describing each component using exemplary language as generic or known computing equipment and networks).
(1) A monetary transaction system comprising: a first information terminal [mobile computer] having a first image display device [mobile device display screen], a first image reading device [camera], first memory, and a first processor and a second information terminal [mobile computer] having a second image display device [mobile device display screen], a second image reading device [camera], second memory, and a second processor, input device (Claim 7) [mobile device touch screen] are WRC in the financial technology field. Spec. ¶¶ 54, 58.
(2) in a situation of an inability of the first information terminal to connect to a communication network is a field of use limitations that cannot supply an inventnive concept under Step 2B. MPEP § 2106.05(h). The specification describes network unavailability as a known, pre-existing condition of conventional mobile terminals not as any unconventional feature of the claimed system. Spec. ¶¶ 3, 5, 52, 57.
(5) Information (QR) code generation, display, and camera-based scanning are WRC. Spec. ¶ 65 (describing known conventional code formats without disclosing any improvement to the scanning mechanism itself); ¶ 73 (the color QR code “can be generated using publicly known method”); ¶¶ 54, 58 (the cameras simply “perform [ ] reading of an information code”).
The Specification further confirms that the functions of receiving, storing, transmitting, and processing data are normal, well-understood operations of generic computer systems, and the steps may be performed in any order or concurrently. See, e.g., Spec. ¶¶ 54, 58, 64.
The combination is also WRC at the high level of generality recited:
The combination of the additional elements is likewise WRC. A combination of individually well-understood, routine, and conventional elements does not provide an inventive concept unless the combination itself produces an unconventional result or is applied in an unconventional manner. MPEP § 2106.05(d)(I). Here, the combination performs each step in exactly the manner described as conventional throughout Applicant’s own Specification. Spec. ¶ 89 (summarizing the operation of reading codes, deducting, and increasing balance data). There is no indication that the combination of these elements operates in an unconventional manner or produces a result that is other than what would be expected from the generic application of these individual components.
Unlike BASCOM, where the claims recited a specific non-conventional arrangement of installing a filtering tool at a specific network location (an ISP server) rather than on individual end-user devices, Rep. Claim 1 does not recite how the elements are combined in a non-conventional way. The claims recite each element at a high level of generality without specifying the particular arrangement or order that constitutes the alleged improvement. At the high level of generality recited, the combination is WRC. Any BASCOM argument fails because any non-conventional arrangement allegedly described in the specification is simply not recited in the claims. Spec. ¶¶ 63, 65–69, 71, 75, 79, 80, 84, 85. Rep. Claim 1 recites only the abstract steps of displaying, reading, acquiring, reducing, matching, increasing, and deleting without incorporating any specific technical details for how these elements are performed. A non-conventional arrangement that is described but not claimed cannot supply the inventive concept at Step 2B. Because the claims here recite only generic components performing generic functions at a high level of generality, the additional elements amount to no more than instructions to apply the abstract idea using a computer. MPEP § 2106.05(f). No inventive concept is present under Step 2B. MPEP § 2106.05(d).
Accordingly, the additional elements of Rep. Claim 1 have been recognized, based on Applicant’s own disclosure, as WRC activity in the field. MPEP § 2106.05(d). These elements do no more than “apply” the recited abstract idea(s) using known computer and computer-related components. See also Step 2A, Prong Two, supra.
Under the 2019 PEG, a conclusion that an additional element is insignificant extra-solution activity in Step 2A should be re-evaluated in Step 2B. Reevaluated under Step 2B, Limitations B and C5 are found to be no more than WRC extra-solution activity in the field of electronic transaction processing and do not provide an inventive concept. As discussed above, Limitations B and C5, merely recite displaying the transaction start image information and the payment completion image information, which is merely the output of the data collection and analysis steps, on generic display devices. Applicant’s Specification describes these operations as occurring within a conventional electronic transaction-processing environment implemented as a standard “app” running on generic smartphones, tablets, or laptop computers with a generic server and des not indicate that these functions are performed in an unconventional manner. Spec. ¶¶ 54, 58, 64. For example, the Specification explains when the payment has been completed, the buyer-side terminal simply “creates an information code 42 indicating payment completion,” and “displays the created information code 42 on the display 23,” using code generation that “can be generated using a publicly known method,” so that the seller-side terminal can confirm payment completion. Spec. ¶¶ 61, 73, 78. Moreover, neither the Specification nor the record identifies Limitations B and C5 as providing any improvement to the functioning of the computer itself, to the underlying network or storage technology, or to the display or image-color technology; nor has Applicant provided any evidence that such operations were not well-understood, routine, and conventional in the field at the time of the invention. Spec. ¶¶ 6, 41 (describing advantages solely as business outcomes). In view of this disclosure and the absence of contrary evidence, and consistent with MPEP § 2106.05(d) and USPTO guidance interpreting Berkheimer, these limitations are found to be well-understood, routine, and conventional extra-solution activity in the field of electronic transaction processing and do not supply an inventive concept.
Independent Claim 9 is a computer-readable medium claim whose program cause a system to perform the same abstract processing and generic computer operations recited in Rep. Claim 1. Independent Claim 7 is a terminal claim having elements that perform the same abstract processing and generic computer operations recited in Rep. Claim 1. Independent Claim 10 is a method claim whose steps perform the same abstract processing and generic computer operations recited in Rep. Claim 1. Independent Claims 7, 9, and 10 add no additional elements beyond those of Rep. Claim 1 that would amount to significantly more than the abstract idea. Therefore, Independent Claims 7, 9, and 10 also do not recite an inventive concept under Step 2B.
Dependent Claims Not Significantly More
The dependent claims have been given the full two-part analysis including analyzing the additional limitations both individually and in combination with the elements of the independent claims. Each dependent claim incorporates all the limitations of its parent Independent Claim and therefore recites the same abstract idea. The additional limitations recited in the dependent claims do not integrate the abstract idea exception into a practical application under Step 2A, Prong Two, and do not amount to significantly more than the abstract idea under Step 2B, for the following reasons:
Claims 2 and 3 recite "wherein" clauses that further describe the data content of the transaction start image information and payment completion image information. The transaction start image is created by combining an “identification code of the second terminal” (Claim 3), “a transaction code of a current transaction,” and “transaction information including the transaction amount (Claim 2). The two “codes” are compared for a match (Claim 3). Under Step 2A, Prong Two, these limitations merely further describe the judicial exception: selecting the particular data to be included in the information codes is insignificant extra-solution activity, MPEP § 2106.05(g), and comparing the identification code and transaction code for a match is itself the mental process of collecting and comparing known information under Classen. The only new additional element is the "input device" of amended Claim 2, which the Specification identifies as a generic component of an ordinary smartphone. Spec. ¶¶ 54, 72. Receiving user input is mere data gathering. MPEP § 2106.05(g). Under Step 2B, the claim language does not explain how the transaction start image information is generated, how it differs from pre-computer methods, or what is inventive about the code or the technology used to create it. The Specification admits the codes are generated "using a publicly known method." Spec. ¶¶ 55, 73; See also MPEP § 2106.05(a), citing Secured Mail Solutions, LLC v. Universal Wilde, Inc., 873 F.3d 905, 910–11 (Fed. Cir. 2017) (affixing a barcode to more reliably identify the sender, "without any limitations specifying the technical details of the barcode or how it is generated or processed," is not an inventive concept).
Claims 4 and 6 specify only the format in which data is presented or stored. Merely specifying the format of the data on which the abstract idea operates does not integrate the exception into a practical application or supply an inventive concept. The Specification admits this format is a conventional QR code, color QR code, or bar code. Spec. ¶¶ 62, 65, 66, 78.
Claim 5 recites a rule of the transaction itself (i.e., the transaction is performed "only within the balance"), a conventional rule of a cash transaction (you cannot spend more than you have) and therefore further limits the abstract idea. Spec. ¶ 60. The abstract idea itself cannot provide the inventive concept or practical application. MPEP §§ 2106.05(I), 2106.04(d). Secured Mail applies here also.
Claims 11 and 12 only add the concept of completing or reconciling the balance updates when connection to the communication network is restored. Under Step 2A, Prong Two, these limitations further describe the abstract bookkeeping practice of recording a transaction and settling the accounts later and is the electronic equivalent of maintaining a ledger entry until the books can be reconciled. The only additional element, the communication network, is generic. Spec. ¶ 52. Under Step 2B, the Specification describes this deferred update as a routine operation of the conventional balance data update function performed by generic hardware over a generic network. Spec. ¶ 57 (the balance data update function "accesses the server 30 and updates the server balance data" when communication "becomes available"); ¶ 64 (the generic server 30 performs the update processing). Receiving or transmitting data over a network is a computer function the courts have recognized as well-understood, routine, and conventional. MPEP § 2106.05(d)(II). These limitations recite nothing more than conventional post-transaction reconciliation steps performed by a general-purpose computer doing what it was designed to do.
Conclusion
Claims 1–7 and 9–12 are therefore drawn to ineligible subject matter as they are directed to an abstract idea without significantly more. The analysis above applies to all statutory categories of invention. As such, the presentment of Rep. Claim 1 otherwise styled as another statutory category is subject to the same analysis.
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.
Claims 1, 2, 3, 4, 5, 7, and 9–12 are rejected under 35 U.S.C. 103 as being unpatentable over Bhat et al. (U.S. Pat. Pub. No. 2019/0130385) [“Bhat”] in view of Dunne (U.S. Pat. Pub. No. 2018/0068293) [“Dunne”] in view of Kim (U.S. Pat. Pub. No. 2022/0207498) [“Kim”] and further in view of Hong (U.S. 2016/0019528) [“Hong”]
Regarding Claim 1, Bhat discloses
A monetary transaction system comprising:
(See at least Abstract, Title, Fig. 4.)
a first information terminal [user device 210] having a first image display device [display of the user device 210] and a first image reading device [camera]; and
(See at least ¶ 73, “if the payment request is in the form of a QR code displayed in the merchant payment system 230, the user device 210 may receive the offline payment request through a camera device to scan the QR code.” ¶ 63, “user device 210 may correspond to a …. smartphone.” A smartphone has a display. ¶ 110, “the user device 210 may present the offline payment request for approval to the user via a display of the user device 210.”)
a second information terminal [merchant payment system 230] having a second image display device and a second image reading device [scanner],
(See at least ¶ 72, “the offline payment request may be in the form of a QR code that is displayed on a display of the merchant payment system 230.” ¶ 115, “the merchant payment system 230 may be used to scan the QR code from a display of the user device 210.”)
wherein the monetary transaction system executes a monetary transaction based on monetary data [amount] between the first information terminal and the second information terminal in a situation of an inability of the first information terminal [user device 201] to connect to a communication network,
(Examiner interprets the inability to “connect to a communication network” as the inability “to access the monetary transaction server.” Spec. ¶ 5, Fig. 1. See at least ¶ 71, “The user device 210 is disconnected from the cellular network 240 and hence, is disconnected from the external network 250 and the payment server 220 … the user device 210 and/or the merchant payment system 230 may be disconnected from the payment server 220 during a network outage, network congestion/overload, and/or other similar situation. In this scenario, the user device 210 (e.g., user device 210-1) and the merchant payment system 230 may be unable to process mobile payments through communication with the payment server 220. In accordance with aspects of the present invention, the user device 210 and the merchant payment system 230 may communicate with each other via the local network 260 to process an offline transaction (e.g., a transaction that occurs when a connection to the payment server 220 is unavailable and occurs without requiring a connection to the payment server 220 at the time of the transaction).” See also Fig. 8, steps 815–845.). ¶ 107, “Process 800 may further include receiving an offline payment request (step 815). For example, the user device 210 may receive the offline payment request from the merchant payment system 230 through the local network 260. The offline payment request may identify an amount of the transaction.”)
wherein the second information terminal includes a second processor configured to display, on the second image display device, … [Kim] … transaction start image information [QR code] including data of a transaction amount of the monetary transaction,
(See at least ¶ 72, “the merchant payment system 230 may provide an offline payment request having details of a transaction for which payment is requested (e.g., an amount of the transaction based on the items/quantities in the transaction). … the offline payment request may be in the form of a QR code that is displayed on a display of the merchant payment system 230.” Fig. 8, step 810, “Generate and provide offline payment request via local communications” after generating a transaction record including a payment amount. ¶ 105.)
the first information terminal includes: a first memory configured to store balance data belonging to the first information terminal;
(See at least ¶ 64, “The offline payment component 215 may include an application (e.g.,
implemented by one or more program modules 42 of FIG. 1) and/or a data storage system (e.g., storage system 34 of FIG.1) that stores and updates information regarding a remaining balance that is available for offline transactions. ¶ 75, “At step 4.3, the offline payment component 215 may update a remaining offline balance amount that may be used for future offline transactions.” Fig. 6 and associated text ¶ 87, “Process 600 may also include receiving user input indicating an amount to reserve for offline transactions (step 670)” and ¶ 90, “process 600 may include initiating a pre-authorization charge for the offline reserve amount (step 690).” “¶ 63, “user device 210 may correspond to a …. smartphone.” A smartphone has a memory. Fig. 1, memory 28.)
a first processor configured to cause the first image reding device [camera] to read the transaction start image information [QR code] displayed on the second image display device of the second information terminal [merchant payment system 230];
(See at least ¶ 107, “the user device 210 may receive the offline payment request from the merchant payment system 230 through the local network 260. The offline payment request may identify an amount of the transaction.”)
acquire … [Kim] … [and] the data of the transaction amount from the transaction start image information [QR code] read by the first image reading device [camera];
(See at least ¶ 107, the request read from the QR code “may identify an amount of
the transaction” and “the user device 210 may compare a transaction amount from the offline payment request with a remaining offline balance stored by the user device 210.” ¶ 108.
when a user of the first information terminal gives approval for payment of the transaction amount, reduce balance of the balance data stored in the first memory according to the transaction amount; and
(See at least ¶ 110, “the user device 210 may present the offline payment request for approval to the user via a display of the user device 210.” ¶ 111, “Process 800 may further include receiving user input approving the offline payment request (step 835).” ¶ 112, “Process 800 may also include updating a remaining offline balance (step 840). For example, the user device 210 may update a remaining offline balance by subtracting the
transaction amount from the offline payment request from a current offline balance. The user device 210 may store the update remaining offline balance.”)
when reduction of the balance of the balance data has been completed [Fig. 8, step 840], display payment completion image information … [Kim] … on the first image display device,
(See at least ¶ 113, the user device 210 may provide the payment approval message to the merchant payment system 230 via location communications (e.g., via the local network 260) based on receiving the user input to approve the offline payment request and updating the remaining offline balance. In embodiments, the payment approval message may include an indication that the payment has been approved, an e-wallet ID of the user device 210, the transaction amount, and a payment account number. In embodiments, the payment approval message may be in the form of a QR code or computer file.” ¶ 115, “If the payment approval message is in the form of a QR code, the merchant payment system 230 may be used to scan the QR code from a display of the user device 210.” See also, ¶ 74. The payment completion image is a QR code that is generated on the user device 210 and scanned by the merchant payment system 230. The timing is met by the sequence steps of Fig. 8, step 845 following step 840)
the payment completion image information is not an image indicating that the balance of the balance data has increased at the second information terminal, but an image to make the second information terminal detects that balance of the balance data has decreased at the first information terminal,
(Examiner interprets “the second information terminal detects that balance of the balance data has decreased at the first information terminal” as the merchant payment system 230 scanning the payment completion QR code on the user device 210. See at least ¶ 115, “If the payment approval message is in the form of a QR code, the merchant payment system 230 may be used to scan the QR code from a display of the user device 210.” Confirmation of payment approval by the user device confirms the reduction of the payment amount as explained supra. ¶ 113, “the user device 210 may provide the payment approval message to the merchant payment system 230 … based on receiving the user input to approve the offline payment request and updating the remaining offline balance. Thus, Bhat teaches a “payment approval message” that is generated by the first (payer) device only after it reduces its local offline balance and completes payment. ¶¶ 112, 113. This message is encoded as a QR code including an indication that payment has been approved, the payer’s e wallet ID, the transaction amount, and a payer account number, and is displayed on the first device. ¶ 113. The merchant payment system (second terminal) scans this QR code to obtain that information and then uses it to proceed with its side of the transaction, while its own account is credited later. ¶ 115. Thus, the payment completion image (QR code) represents the payor side payment completion state and does not indicate an increased balance at the second terminal, but functions as an image by which the second terminal detects that payment (and the associated balance decrease) has been completed at the first terminal, as claimed.)
the second information terminal includes: … [Dunne] … ; wherein the second processor configured to cause the second image reading device [scanner] to read the payment completion image information [payment approval message QR code] displayed by the first information terminal [user device 210];
(See at least ¶ 115, “If the payment approval message is in the form of a QR code, the merchant payment system 230 may be used to scan the QR code from a display of the user device 210.” See also, ¶ 116; Fig. 8, steps 855, 860.)
[…]
Bhat does not disclose but Dunne discloses
a second memory configured to store balance data belonging to the second information terminal; and … increase balance of the balance data stored in the second storage memory according to the transaction amount, and
(See at least ¶ 39, “FIG. 5c, a payee token 155 for the value of the sale is generated and locked to the payee device 200. The payee token 155 representing the sale value is transmitted to and stored on the payee device 200 [balance data belonging to the second information terminal, increased by the transaction amount upon receipt of the completion image]. ¶¶ 40, 41, Figs. 6 & 7. The token is transmitted “As a QR code scan.” ¶ 41; see also ¶ 30, 43, 48. Both terminals are smartphones. ¶ 49.
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 merchant payment system of Bhat with storing payee-side monetary value received via the scanned completion QR code of Dunne, in the same field of invention, with the motivation to provide the payee an immediate, locally verifiable record of funds received while both devices remain offline, pending later settlement, Dunne, ¶ 41, and because applying Dunne’s known payee-token technique to Bhat’s online QR code exchange is predictable use of a known technique to improve a similar device in the same way.
Bhat do not disclose but Kim discloses:
a unique transaction code generated for each monetary transaction, acquire the transaction code, and determine whether the transaction code included in the payment completion image information matches the transaction code stored in the second information terminal, and when the transaction codes match,
(See at least ¶ 33, “generates and stores a transaction code.” “[T]he transaction code may be generated and stored for each transaction.” ¶ 35. “The payment authentication server 17 checks whether the transaction code transmitted to the user's smartphone 13 matches the transaction code received from a merchant terminal 16. When the matching is confirmed, the payment authentication server 17 may transmit the actual credit card number corresponding to the received transaction code to a payment approval server 18.” ¶ 34; see also ¶ 82 (same); ¶¶ 83, 67, 68.
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 merchant payment system of the Bhat such that a unique per transaction code is included in the transaction start image and the payment completion image is matched at the merchant payment system, as taught by Kim, in the same field of invention, because Bhat contemplates per-transaction ID checking to “prevent supplicative processing of a single transaction.” Bhat, ¶ 114. Kim demonstrates it was well known to confirm a legitimate transaction by comparing a per-transaction code received from the counterparty against a stored code. Kim, ¶¶ 34, 82. In Bhat’s offline setting, no server is reachable at transaction time so the known server-side matching function must be performed locally at the terminal that generated the code, which is a relocation of a known function that is a predictable design choice yielding no new or unexpected result. The matching operation taught by Kim is a simple equality comparison between a received transaction code and a previously generated transaction code, followed by an authorization step, and thus is not technically required to be performed at the server, especially for an offline transaction where the second device is not in communication with the server at the time of the transaction. Rather, the matching is a routine verification function that can be implemented at any node in a distributed payment architecture, including the second information terminal. It would have been a matter of predictable design choice with a reasonable expectation of success to have the second information terminal store the relevant identification code and transaction code, perform the matching locally for an offline transaction, and, when a match is confirmed, update its own balance data, for offline situations or to reduce latency and server load, while achieving the same overall result of confirming a legitimate transaction as in Kim.
Bhat des not disclose but Hong discloses
when the increase in the balance of the balance data has been completed, delete the transaction code stored in the second information terminal
(See at least ¶ 72, “When the settlement approval is completed, the payment and settlement management server 300 stores the information about the details of settlement in the database for the details of payment and settlement 322 of the storage unit 320 (S338). After storing the information about the details of settlement, the payment and settlement management server 300 may delete the barcode (the barcode used in settlement approval) registered in the payment and settlement database 321 (S339). This is because the barcode is a one-time barcode.” See also, ¶¶ 54, 80, 81.
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 merchant payment system of the Bhat such that the merchant payment system deletes its stored transaction code once the balance increase is competed, as taught by Hong, with the motivation to improve security by preventing the barcode form being stolen by a third party. Hong, ¶¶ 26, 27.
Regarding Claim 2, Bhat, Dunne, Kim, and Hong disclose:
The monetary transaction system according to claim 1 and the first and second information terminals.
Bhat further discloses
wherein the second information terminal includes an input device configured to input the transaction amount, and
(See at least Fig. 8, steps 805, 810, 815, 835. Step 805 (“Generate a transaction record while merchant payment system is offline”). Step 810 (“Generate and provide offline payment request via local communications”). Step 815 (“Receive offline payment request”). Step 835 (“Receive user input approving offline payment request”). ¶ 74 (“an amount of the transaction”).
in the second information terminal, the second processor is configured to generate the transaction start image information including transaction information including the transaction amount input by the input device, and display the transaction start image information on the second image display device,
(See at last ¶ 72, “the offline payment request may be in the form of a QR code that is displayed on a display of the merchant payment system 230.”). See also, ¶ 73.)
wherein, in the first information terminal, the first processor is configured to acquire the transaction information from the transaction start image information, and in order for the user of the first information terminal to give approval for payment of the transaction amount,
(See at least ¶ 73, “if the payment request is in the form of a QR code displayed in the merchant payment system 230, the user device 210 may receive the offline payment request through a camera device to scan the QR code. For example, a user of the user device 210 may orient the user device 210 such that the camera of the user device 210 is able to scan the QR code.”) Fig 8, step 830, “Present offline payment request for [user] approval.” Fig. 8, step 835, “Receive user input approving offline payment request.”)
when the transaction start image information including the transaction information has been read, display an image for requesting the approval on the first image display device of the first information terminal.
(See at least Fig 8, steps 815, 830, 835, cited supra. The offline payment request is the claimed transaction start image information (Step 815).
Regarding Claim 3, Bhat, Dunne, Kim, and Hong disclose:
The monetary transaction system according to claim 1, the second information terminal, second processor, first information terminal, the first processor
Bhat further discloses
wherein, in the second information terminal, the second processor is configured to generate the transaction start image information […], and display the transaction start image information on the second image display device,
(See at least ¶ 72, “the merchant payment system 230 may provide an offline payment request having details of a transaction for which payment is requested (e.g., an amount of the transaction based on the items/quantities in the transaction) … the offline payment request may be in the form of a QR code that is displayed on a display of the merchant payment system 230.” ¶ 75, “To prevent the offline transaction from being processed twice, the offline payment information may include a transaction ID. In embodiments, the payment server 220 may process only one offline transaction per transaction ID.”)
wherein, in the first information terminal, the first processor is configured to cause the first image reading device to read the transaction start image information […], and
(See at least ¶ 73, “if the payment request is in the form of a QR code displayed in the merchant payment system 230, the user device 210 may receive the offline payment request through a camera device to scan the QR code. For example, a user of the user device 210 may orient the user device 210 such that the camera of the user device 210 is able to scan the QR code.”)
generate the payment completion image information […] read from the transaction start image information by the first image reading device, and display the generated payment completion image information on the first image display device,
(See at least ¶ 74, “the user device 210 may generate an offline payment response having the payment information (e.g., account number, amount of payment corresponding to the amount of the payment request). At step 4.2, the user device 210 may provide the offline payment information to the merchant payment system 230 (e.g., in a similar manner as the user device 210 received the offline payment request). For example, the user device 210 may provide the offline payment information by generating a QR code that the merchant payment system 230 may scan, or through another type of communications protocol associated with the local network”)
[…]
Bhat discloses a QR code offline payment request image displayed at the merchant terminal with a transaction amount. Bhat, ¶¶ 72, 105. Bhat discloses a first terminal camera scanning the QR transaction request image on the second terminal’s display. Bhat, ¶¶ 72, 73. Bhat discloses the “offline transaction information” includes a “merchant ID” and “transaction ID” for payment server processing. Bhat, ¶ 119. Bhat does not explicitly disclose the QR payment request image itself “includes an identification code of the second information terminal and a transaction code” or that the first image reading device reads “the identification code of the second information terminal and a transaction code.” Thus, Bhat does not explicitly disclose but Dunne discloses:
generating the transaction start image information including an identification code of the second information terminal [Device ID] and a transaction code of a current transaction [BoS ID]
read the transaction start image information including the identification code of the second information terminal and the transaction code,
generate the payment completion image information including the identification code of the second information terminal and the transaction code
(See at least ¶ 38, “FIG. 4 is a screenshot illustrating a bill of sale 250 being created on a merchant or payee device 200 … The bill of sale 250 may comprise … key data associated at least with the payee device 200. For example, the key data may comprise a payee device ID. The bill of sale may be delivered to a user acting as a customer or payer via a short-range wireless communication protocol, e.g., as a QR code scan … all the required data for the sale may be transferred from the merchant to the customer. That is, the bill of sale may be delivered from the payee device 200 to the payer device 100. FIGS. 5a to 5c are screenshots illustrating a bill of sale 250 being received at the payer device 100.” Fig. 4 discloses a Bill of Sale (BoS) “ID:1234567VCO”. Fig. 5a discloses a “Device ID:xxxxxxxxxx”. Seel also, ¶ 39 (“Referring to FIG. 5c, a payee token 155 for the value of the sale is generated and locked to the payee device 200 using the data retrieved with the bill of sale 250 such as the payee device ID.” The payer device reads the BoS (transaction start information) that includes at least the BoS ID and Payer device ID. The payer device then generates a payee token 155 (payment completion image information) using the data retrieved with the bill of sale 250, which includes the BoS ID and Payer device ID and uses those identifiers to bind the token to the sale. ¶¶ 39, 41.)
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 3.
Bhat does not disclose but Kim discloses:
wherein, in the second information terminal [merchant terminal 16], the second processor is configured to determine whether the identification code of the second information terminal and the transaction code included in the payment completion image information displayed by the first information terminal match the identification code of the second information terminal and the transaction code stored in advance in the second information terminal, and, when the identification code of the second information terminal and the transaction code match, increase the balance of the balance data stored in the second memory.
(See at least ¶ 34, “The payment authentication server 17 checks whether the transaction code transmitted to the user's smartphone 13 matches the transaction code received from a merchant terminal 16. When the matching is confirmed, the payment authentication server 17 may transmit the actual credit card number corresponding to the received transaction code to a payment approval server 18.” ¶ 82, “The merchant terminal 16 transmits the mobile transaction code to the payment authentication server 17 (S616), and the payment authentication server 17 confirms a legitimate transaction when the mobile transaction code received from the merchant terminal 16 matches the mobile transaction code previously generated by the payment authentication server 17 and transmitted to the user's smart phone 13 (S617).” See also, ¶¶ 67, 68. ¶ 83, “When the payment authentication server 17 confirms that it is a legitimate transaction, it transmits an actual credit card number corresponding to the mobile transaction code to the payment approval server 18.”
Therefore, Kim teaches a “second information terminal” (merchant terminal 16) that participates in the transaction process transmits the mobile transaction code. A comparison step where a mobile transaction code “received from the merchant terminal 16” is matched with a mobile transaction code “previously generated by the payment authentication server and transmitted to the user's smart phone 13 (S617).” A subsequent settlement step where “when matching is checked,” the payment authentication server sends an actual credit card number to a payment approval server, which results in an update of an account balance (merchant credited, user debited) (increase the balance of the balance data). Thus, Kim teaches all of the elements of generating and using a transaction code, including matching the code for authorization and updating balances, but performs the matching and balance update at a central payment authentication server. Further, Kim teaches it as well known in the prior art to confirm a transaction by comparing a received transaction code to a previously generated transaction code and if matched, updating the balances on the respective accounts.
For clarity of the record with respect to the limitation reciting “wherein, in the second information terminal, the second processor … is configured to determine whether the identification code of the second information terminal and the transaction code included in the payment completion image information displayed by the first information terminal match the identification code of the second information terminal and the transaction code stored in advance in the second information terminal, and, when the identification code of the second information terminal and the transaction code match, increase the balance of the balance data stored in the second memory,” Bhat in view of Dunne is relied upon for the second information terminal storing an identification code and transaction code and updating balance data upon determining a match, as discussed above, while Kim is relied upon to show that performing matching of a received transaction code against a previously generated transaction code to confirm a legitimate transaction and trigger payment completion is well-known in mobile payment systems.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to relocate this known matching functionality and payment-completion trigger from the server to the second information terminal of Bhat. The matching operation taught by Kim is a simple equality comparison between a received transaction code and a previously generated transaction code, followed by an authorization step, and thus is not technically required to be performed at the server, especially for an offline transaction where the second device is not in communication with the server at the time of the transaction. Rather, the matching is a routine verification function that can be implemented at any node in a distributed payment architecture, including the second information terminal. It would have been a matter of predictable design choice with a reasonable expectation of success to have the second information terminal store the relevant identification code and transaction code, perform the matching locally for an offline transaction, and, when a match is confirmed, update its own balance data, for offline situations or to reduce latency and server load, while achieving the same overall result of confirming a legitimate transaction as in Kim.
Regarding Claim 4, Bhat, Dunne, Kim, and Hong disclose:
The monetary transaction system according to claim 1 and the payment completion image is displayed
Bhat further discloses
wherein the payment completion image information is displayed in an information code having information cells arranged two-dimensionally as information units [QR code].
(See at least ¶ 18, “communications via local code scanning of codes (e.g., Quick Response (QR) codes, bar codes, etc.) generated on the user device and the merchant payment system in which the QR codes include transaction details.”). See also, ¶¶ 69, 72, 73, 74. A QR code is a two-dimensional code with information arranged in rows and columns.)
Regarding Claim 5, Bhat, Dunne, Kim, and Hong disclose:
The monetary transaction system according to claim 1 and the payment completion image is displayed
Bhat further discloses
wherein the monetary transaction is performed only within the balance of the balance data of the first information terminal.
(Examiner interprets this limitation as the first information terminal (payor device) has a local balance and only proceeds with an offline payment if the transaction amount is less than the local balance. See at least ¶ 108, “Process 800 may also include determining whether an offline balance is sufficient to approve the request (step 820).” ¶ 109, “If, for example, the offline balance is not sufficient (step 820-NO), process 800 may further include rejecting the offline payment request (step 825).”)
Regarding Claim 7, the limitations are not substantively different than those presented in Claims 1 and 2 (combined) and are therefore, rejected, mutatis mutandis, based on Bhat, Dunne, Kim and Hong for the same rationale presented in Claims 1 and 2 (combined), supra.
Regarding Claim 9, the limitations are not substantively different than those presented in Claim 1 and is therefore, rejected, mutatis mutandis, based on Bhat, Dunne, Kim and Hong for the same rationale presented in Claim 1, supra.
Regarding Claim 10, the limitations are not substantively different than those presented in Claim 1 and is therefore, rejected, mutatis mutandis, based on Bhat, Dunne, Kim and Hong for the same rationale presented in Claim 1, supra.
Regarding Claim 11, Bhat, Dunne, Kim, Hong discloses:
The monetary transaction system according to claim 1 and the first processor
Bhat further discloses
wherein the first processor is further configured to: store a record of the transaction amount; and
(See at least ¶ 105, “As shown in FIG. 8, process 800 may include generating a transaction record while the merchant payment system is offline (step 805). For example, the merchant payment system 230 may generate a transaction record that identifies a payment amount to be paid for a transaction.” Abstract, “a user device to … provide the
offline transaction information to the payment server … when the user device and the payment server are connected via a network.”)
in response to restoring connection to the communication network, completing reduction of the balance of the balance data using the communication network.
(See at least Fig. 8, steps 850, 865, “Provide offline transaction information to payment server when connectivity is restored” and the payment server then “debit[s] account of payer” and “update[s] pre-authorized offline amount” (Fig. 9 steps 930, 940). See also ¶¶ 57, 113.)
Regarding Claim 12, Bhat, Dunne, Kim, Hong discloses:
The monetary transaction system according to claim 1 and the second processor
Bhat further discloses
wherein the second processor is further configured to: connect to the communication network to complete increase of the balance of the balance data.
(See at least ¶ 116, “Process 800 may also include storing the payment approval message (step 860). For example, the merchant payment system 230 may store the payment approval message until connectivity to the payment server 220 is restored.” ¶ 117, “Process 800 may further include providing offline transaction information to the payment server when connectivity is restored (step 865). For example, the merchant payment system 230 may provide the offline transaction information (e.g., the payment approval message indicating that an offline transaction took place) to the payment server
220 when connectivity is restored to the payment server 220 (e.g., in a similar manner as the user device 210 provides the offline transaction information to the payment server 220 at step 850).”)
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Bhat, Dunne, Kim, and Hong and further in view of Liberty et al. (U.S. Pat. Pub. No. 2014/0172531) [“Liberty”]
Regarding Claim 6, Bhat, Dunne, Kim, and Hong disclose:
The monetary transaction system according to claim 1 and the balance data of the first information terminal
Bhat further discloses
wherein the balance data of the first information terminal is stored in the first memory of the first information terminal in a form included in an information code having information cells arranged two-dimensionally as information units [QR code], and
(See at least ¶ 64, where a first user device (a first information terminal) “stores and updates information regarding a remaining balance that is available for offline transactions.” Bhat further explains that after an offline transaction is approved, “the user device 210 may update a remaining offline balance by subtracting the transaction amount from a current offline balance. The user device 210 may store the updated remaining offline balance such that future offline transactions do not exceed the remaining balance.” ¶ 112. Bhat also teaches using QR codes as a mechanism for local communications between the user device and a merchant terminal and between user devices. For example, the offline payment request “may be in the form of a QR code that is displayed on a display of the merchant payment system 230,” and the user device “may receive the offline payment request through a camera device to scan the QR code.” ¶¶ 72, 73. Likewise, the user device may provide offline payment information “by generating a QR code that the merchant payment system 230 may scan.” ¶ 74. For handover, “the handover local communications mode may include the generation of a QR code on user device 210 1 that may be scanned by user device 210 2 to transmit data,” and handover/confirmation/status data “may be … in the form of a QR code.” ¶¶ 93, 94, 95, 100, 101, 102.
It is well known in the art that QR (two-dimensional) codes are generic containers for arbitrary digital data, including payment/account-related information, and that such data can be structured for inclusion in a QR code. For example, Liberty teaches constructing QR codes that encode purchaser account information and transaction data for use in payment processing. Liberty, ¶¶ 51, 56, 62 Generic 2D-code prior art such as this teaches that financial or account data structures may be represented in a form suitable for inclusion in a QR code.
the balance data of the second information terminal is stored in the second memory of the second information terminal also in a form included in an information code having information cells arranged two-dimensionally as information units.
(Mere duplication of parts has no patentable significance unless a new and unexpected result is produced, as here. MPEP § 2144.04(VI). See prior mapping and explanation for the first terminal device)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to structure the balance data stored in the first memory of Bhat’s user device in a form that may be included in a QR code. Given that Bhat already uses QR codes as a vehicle for locally communicating transaction related data and that Liberty teaches encoding arbitrary financial/account data in QR codes, a skilled artisan would have found it a routine design choice with predictable results to represent Bhat’s locally stored offline balance data in a format directly compatible with QR encoding, thereby enabling the balance or balance related information (e.g., payment information) to be transmitted optically via QR codes when desired. Accordingly, the combination of Bhat with Liberty (representing generic QR code prior art) renders obvious the limitation that “balance data of the first information terminal is stored in the first memory in a form that may be included in a QR code.”
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES H MILLER whose telephone number is (469)295-9082. The examiner can normally be reached M-F: 10- 4 PM (EST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett M Sigmond can be reached at (303) 297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JAMES H MILLER/Primary Examiner, Art Unit 3694
1 Statements of intended use fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C).
2 “It should be noted that these groupings are not mutually exclusive, i.e., some claims recite limitations that fall within more than one grouping or sub-grouping. … Accordingly, examiners should identify at least one abstract idea grouping, but preferably identify all groupings to the extent possible, if a claim limitation(s) is determined to fall within multiple groupings and proceed with the analysis in Step 2A Prong Two.” MPEP § 2106.04(a).
3 Examiner also analyzes the claimed structure recited in other Independent Claims with Rep. Claim 1.
4 See Changes in Examination Procedure Pertaining to Subject Matter Eligibility, Recent Subject Matter Eligibility Decision (Berkheimer v. HP, Inc.), 3-4, https://www.uspto.gov/sites/default/files/documents/memo-berkheimer-20180419.PDF (April, 18, 2018) (That additional elements are well-understood, routine, or conventional may be supported by various forms of evidence, including "[a] citation to an express statement in the specification or to a statement made by an applicant during prosecution that demonstrates the well-understood, routine, conventional nature of the additional element(s).").
Prosecution Insights