DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on Jan. 29, 2026, and is made 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
Examiner 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. Interviews conducted solely for the purpose of “sounding out” the examiner, including by local counsel acting only as a conduit for another practitioner, are not permitted under MPEP § 713.03. The Office is strictly enforcing established interview practice, and applicants should ensure that every interview request is directed toward advancing prosecution on the merits in compliance with MPEP §§ 713 and 713.03.
For after-final Interview requests, supervisory approval is required before an interview may be granted. Each AIR should specifically explain how the After-Final Interview request will advance prosecution—for example, by identifying targeted arguments responsive to the rejection of record, alleged defects in the examiner’s analysis, proposed claim amendments, or another concrete basis for discussion. See MPEP § 713. If the AIR form’s character limits prevent inclusion of all pertinent details, Applicants may send a contemporaneous email to the examiner at James.Miller1@uspto.gov.
The examiner is generally available Monday through Friday, 10:00 a.m. to 4:00 p.m. EST.
For any GRANTED Interview Request, Applicant can expect an email within 24 hours confirming an interview slot from the dates/times proposed and providing collaboration tool access instructions. For any DENIED Interview Request, the record will include a communication explaining the reason for the denial.
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on Nov. 26, 2025, was filed after the first Office action on the merits but before final action and contained the statement required by 37 CFR 1.97(e). Therefore, said IDS is in compliance with the provisions of 37 CFR 1.97(c). Accordingly, the IDS has been considered.
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, 3, 6, 7, 9, and 10 are presently amended.
Claim 8 is presently cancelled.
Claims 11 and 12 are presently 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 Applicant’s Specification has been reviewed and has overcome each and every objection to Applicant’s Specification previously set forth in the Non-Final Office Action mailed Oct. 30, 2025, [“Non-Final Office Action"]. The objection to Applicant’s Specification is withdrawn. Applicant's Amendment to the Specification is acknowledged and entered.
Applicant's Amendment to address objections to the drawings has been reviewed but entry is DENIED for the same reasons as indicated in the Non-Final Office Action. Portions of replacement drawings remain illegible and do not have satisfactory reproduction. The Drawing Objection is maintained.
Applicant's Amendment to address claim interpretations under 35 U.S.C. § 112(f) has been reviewed and has rebutted the presumption that the claim limitations should be treated in accordance with § 112(f) because the claims have been amended to recite sufficient structure. All interpretations under § 112(f) in the Non-Final Office Action are withdrawn. As Claim 8 has been cancelled, interpretations under § 112(f) have been rendered moot. Accordingly, the corresponding rejections of Claims 1–10 under §§ 112(a), (b) in the Non-Final Office Action are withdrawn.
Applicant's Amendment to address the rejection under 35 U.S.C. § 101 as being directed to non-statutory subject matter has been reviewed and has overcome each and every rejection under § 101 for non-statutory subject matter previously set forth in the Non-Final Office Action. The rejection of Claim 9 under § 101 is withdrawn. As Claim 8 has been cancelled, the rejection under § 101 is rendered moot. Applicant’s arguments that the claims are not directed to a judicial exception (i.e., an abstract idea) are addressed below.
Response to Arguments
35 U.S.C. § 101 Argument
Applicant argues the claims are directed to a practical application that solves a specific technical problem identified in the specification ¶ 5, namely that, when network communication is not available, information terminals cannot access a monetary transaction server and therefore cannot conduct a monetary transaction based on monetary data. The invention, here, solves that technical problem. Applicant’s Reply at 13.
Examiner respectfully disagrees.
The inability to conduct a transaction without a network is a business problem—not a technical one. The condition that a user wishes to complete a payment when no network is available is merely a business constraint on when a monetary transaction is performed, not a technological deficiency in the operation of the terminals themselves. The recited terminals, memories, displays, and image reading devices perform only their routine, generic functions (storing data, displaying images, reading images) to implement a monetary transaction between parties. Under the 2019 PEG, the "practical application" inquiry asks whether the claims improve the “functioning of a computer or other technology,” not whether they solve a business inconvenience. Paying someone when no internet is available is a problem humans have solved for millennia using gold, cash, checks, and IOUs — none of which require a network. Therefore, the specification at ¶ 5 identifies a commercial/business problem/function and reciting generic terminals that perform this known business function does not constitute integration into a practical application under Step 2A, Prong 2.
Applicant argues that the claims recite a specific “bidirectional optical communication protocol” between image display devices and image reading devices of two terminals. Applicant’s Reply at 13. Applicant argues that this protocol—where a first terminal reads transaction start image information from a second terminal, and the second terminal then reads payment completion image information from the first terminal—constitutes a specific technical implementation that renders the claims patent-eligible. Id.
Examiner respectfully disagrees.
The “bidirectional optical communication” relied upon by Applicant merely uses generic displays to present information and generic cameras or image readers to capture that information, which are conventional and well-known functions of such components. The ordered steps of displaying image information and reading that image information simply define the way data representing the monetary transaction is exchanged between parties, and therefore amount to implementing the underlying abstract financial transaction using well-known hardware. This does not improve the functioning of the computer or any other technology, but instead uses generic technology as a tool to perform a method of organizing human activity.
Examiner further notes that 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 detect that balance of the balance data has decreased at the first information terminal” is a negative limitation describing the content or meaning of the data being communicated and lacks a functional relationship to the substrate. The nature of the information conveyed (i.e., "balance decreased at the first terminal" versus "balance increased at the second terminal") is a distinction about what data represents, not about how technology functions. It does not improve the operation of the display, camera, processor, or memory in any technical way. "Claim limitations directed to the content of information and lacking a requisite functional relationship are not entitled to patentable weight because such information is not patent eligible subject matter under 35 U.S.C. § 101." Praxair Distrib., Inc. v. Mallinckrodt Hosp. Prod. IP Ltd., 890 F.3d 1024, 1032 (Fed. Cir. 2018).
Applicant argues that the claims are distinguishable from those in Electric Power Group because they do more than merely “collect and analyze data.” The claims establish a specific optical communication protocol that purportedly enables a technical function—offline peer to peer monetary transactions—that was previously impossible without network infrastructure.
Examiner respectfully disagrees.
The abstract idea implicated by the present claims is not limited to data collection and analysis but encompasses conducting and confirming a monetary transaction between parties, which is a fundamental economic practice. Electric Power Group is not the only relevant precedent and the Federal Circuit has consistently held that claims directed to conducting financial transactions between parties — even using specific data exchange protocols — fall within the "certain methods of organizing human activity" abstract idea grouping. The claimed "technical function" is actually a business function (completing a payment offline). Implementing that financial exchange via a sequence of image-code displays and readings still constitutes using generic computer components to carry out a method of organizing human activity. That the claimed implementation allows the business transaction to be carried out without a server or network connection does not, by itself, amount to an improvement in computer technology. Accordingly, the cited case law on abstract financial transaction implementations remains applicable, and Applicant’s attempt to distinguish Electric Power Group does not overcome the § 101 rejection.
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.
Drawings
Figs. 5, 6, 8, 9, and 10 are objected to because portions are illegible and do not have satisfactory reproduction. 37 CFR 1.84(l), (p)(3) (“Numbers, letters, and reference characters must measure at least .32 cm. (1⁄8 inch) in height”).
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claim 1 is objected to because of the following informalities. Appropriate correction is required.
Claim 1: It is believed that “reding” (Limitation C2 below) is “reading”; “detects” (Limitation C5, below) is “detect”; the “second storage memory” (Limitation D3, below) is “the second memory”; and “transation” (Limitation D4, below) is “transaction,” to correct believed spelling, grammatical, antecedent basis, and spelling errors, respectively.
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 and recites, in part, emphasis added by Examiner to identify limitations with normal font indicating the abstract idea exception, bold limitations indicating additional elements. Each limitation is identified by a letter for later use as a shorthand notation in referencing/describing each limitation. Portions of the claim use italics to identify intended use limitations1 and underline, as needed, in further describing the abstract idea exception:
[A] 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 offline 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, 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 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 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] when the payment completion image information has been read, increase balance of the balance data stored in the second storage memory according to the transaction amount, and
[D4] confirm that the payment has been completed in the first information terminal by reading the payment completion image information displayed on the first information terminal, and allow the first information terminal to complete the transation.
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, and “when the payment completion image information has been read, increase balance of the balance data … according to the transaction amount,” in Limitation D3, which recites 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 people. MPEP § 2106.04(a)(2)(II)(B). Limitations B–D 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–D 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).
Alternatively2, Limitations B, C1–C5, and D1–D4, 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–C5, and D1–D4, recite collecting information (Limitations C1, C2, C3, D1, D2, D4), analyzing it (Limitations C4, D3), 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. Likewise, Limitation D3 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 “increase balance of the balance data according to the transaction amount,” “when the payment completion image information has been read” in any known way, including mental processes. The increasing of one party’s balance by the amount the other party’s balance was decreased is mere bookkeeping and predates the internet and the computer.
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 the combination of these abstract idea exceptions.
Step 2A, Prong Two: Rep. Claim 1 does not contain additional elements that integrate the abstract idea exception into a practical application because the additional elements are mere instructions to apply the abstract idea exception. MPEP § 2106.05(f). The additional elements are limited to the computer components and 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] and a communication network.3
Regarding the 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] and a communication network, Applicant’s Specification does not otherwise describe them or describes them using exemplary language 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. 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 device. 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 conforms 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 generic “terminal”, here, appears to perform calculations (functions) that are programmed by software. Spec. ¶¶ 17, 18, 54, 58. This is a computer doing what it is designed to do—performing directions it is given to follow.
The displaying steps, Limitations B and C5, fail to transform the claims into patent eligible material, as this is part of the field of use and technical environment in which the abstract idea is being implement and does not result in an improvement to additional elements, a practical application, or inventive concept. MPEP 2106.05(h) (citing Electric Power Group). 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 or inventive concept. MPEP § 2106.05(f)(2) (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 further describes the computer hardware performing the steps/functions of the claimed invention, Limitations B–D. Performing the steps of the abstract idea exception itself simply adds a general-purpose computer after the fact to an abstract idea exception, MPEP § 2106.05(f)(2), or generically recites an effect of the judicial exception. MPEP § 2106.05(f)(3).
Therefore, the claim as a whole, looking at the additional elements individually and in combination, are no more than mere instructions to apply the exception 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.
Rep. Claim 1 is not substantially different than Independent Claims 7, 9, and 10 and includes all the limitations of Rep. Claim 1. Independent Claims 7, 9, and 10 contain no additional elements not otherwise analyzed with 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 whole, looking at the additional elements individually and in combination, are not sufficient to amount to significantly more than the recited judicial exception. As discussed with respect to Step 2A, Prong Two, the additional elements in the claim amount to no more than mere instructions to apply the exception using a generic computer and/or generic computer components. MPEP § 2106.05(f). The same analysis applies here in Step 2B. Mere instructions to apply an exception using a generic computer and/or generic computer components cannot provide an inventive concept. MPEP § 2106.05(I).
The additional elements, taken individually and in combination, do not result in the claim, as a whole, amounting to significantly more than the identified judicial exception.
The pending claims in their combination of additional elements is not inventive. First, the claims are directed to an abstract idea. Second, each additional element represents a currently available generic computer technology, used in the way in which it is commonly used (individually generic). Last, Applicant’s Specification discloses that the combination of additional elements is not inventive. Spec. ¶¶ 17, 18, 52, 54, 58, 64, 65, 71, 73, Fig. 3 (known and generic (exemplary) computer equipment as explained and cited supra.)
Thus, Examiner finds the additional elements of Rep. Claim 1 are elements that have been recognized as well-understood, routine, and conventional (“WURC”) activity in the particular field of this invention based on Applicant’s own disclosure4. Spec. Spec. ¶¶ 17, 18, 52, 54, 58, 64, 65, 71, 73, Fig. 3; MPEP § 2106.05(d). Specifically, Applicant’s Specification discloses the recited additional elements (i.e., the 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] and a communication network) are limited to generic computer components. These elements do no more than “apply” the recited abstract idea(s) on a known computer and computer-related components. The Examiner also finds the functions of reading, acquiring, receiving, storing, transmitting, displaying, and processing (e.g., performing mathematical operations on) data, described in Limitations A–D are all normal functions of a generic computer.
There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional elements in combination adds nothing that is not already present when looking at the elements individually. Their collective functions merely provide conventional computer implementation of the abstract idea at a high level of generality. Thus, Rep. Claim 1 does not provide an inventive concept.
Rep. Claim 1 is not substantially different than Independent Claims 7, 9, and 10 and includes all the limitations of Rep. Claim 1. Independent Claims 7, 9, and 10 contain no additional elements not otherwise analyzed. Therefore, Independent Claims 7, 9, and 10 also do not recite an inventive concept.
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. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. § 101. Dependent claims are dependent on Independent Claims and include all the limitations of the Independent Claims. Therefore, all dependent claims recite the same Abstract Idea. Dependent claims do not contain additional elements that integrate the abstract idea exception into a practical application or recite an inventive concept because the additional elements: (1) are mere instructions to apply the abstract idea exception; and/or (2) further limit the abstract idea exception of the Independent Claims. The abstract idea itself cannot provide the inventive concept or practical application. MPEP §§ 2106.05(I), 2106.04(d)(III).
Dependent Claims 2–6 all recite “wherein” clauses or limitations that further limit the abstract idea of the Independent Claims and contain no additional elements. 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), which recites a metal process under Classen. The data is “arranged two-dimensionally as information units.” (Claims 4, 5). 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).
Dependent Claims 11 and 12 all recite “wherein” clauses or limitations that further limit the abstract idea of the Independent Claims and contain no additional elements. An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III). Claims 11 and 12 add only the concept of deferred balance synchronization with a server upon network reconnection. The specification uniformly describes this as a routine operation performed by generic hardware over a generic network using publicly known methods. These limitations neither integrate the abstract financial-transaction idea into a practical application nor supply an inventive concept, because they recite nothing more than well-understood, 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, 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”]
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, 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 [user device 210] 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]; acquire the data of the transaction amount from the transaction start image information [QR code] read by the first image reading device;
(See at least ¶ 73, “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 [on the merchant payment system 230].” ¶ 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).” “¶ 63, “user device 210 may correspond to a …. smartphone.” A smartphone has a processor. Fig. 1, processing unit 16.)
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 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: a second memory configured to store balance data [payment information] belonging to the second information terminal;
(See at least ¶ 75, “At step 4.4, the merchant payment system 230 may store the offline payment information and may process the payment.” Fig. 8 teaches the merchant payment system 230 storing the payment approval message (step 860) and providing the offline transaction later to a payment server (step 865).
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.”)
[…]
confirm that the payment has been completed in the first information terminal by reading the payment completion image in formation displayed on the first information terminal, and allow the first information terminal to complete the transation.
(As explained elsewhere, the merchant reading the QR code form the user device knows the payment has been approved and the payer had sufficient offline reserve. ¶¶ 113–117.)
Claim 1 recites, a “first information terminal” and a “second information terminal,” each having an image display device and an image reading device and executing a monetary transaction between the two terminals in an offline situation using stored balances on the device itself. Bhat discloses a substantially similar arrangement comprising a mobile user device 210 (e.g., smartphone) and a merchant payment system 230. Bhat teaches that the merchant payment system 230 “may include an electronic credit card reader with mobile pay capabilities, a payment terminal, a scanner, or the like,” i.e., any suitable computing device for displaying and scanning QR codes and storing offline payment information.
Mere duplication of parts (smartphone) has no patentable significance unless a new and unexpected result is produced, as here. MPEP § 2144.04(VI).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the merchant payment system 230 as another mobile device of the same type as user device 210 (i.e., a second smartphone) in order to enable person-to-person (P2P) payments, since this is merely a substitution/duplication of known components performing the same functions of displaying a QR code, scanning a QR code, and storing offline transaction information on each device. MPEP § 2144.04(VI). Accordingly, it would have been obvious to modify Bhat’s system so that both the first and second information terminals are smartphones, thereby arriving at the claimed mobile to mobile offline monetary transaction system of the claimed invention.
The claimed invention is obvious in view of Bhat and MPEP § 2144 (Duplication of Parts). However, under the doctrine of compact prosecution, Examiner alternatively provides Dunne without relying on MPEP § 2144 as follows:
Bhat discloses the merchant payment system 230 stores “offline payment information” and the “payment approval message (860)”, but not “balance data belonging to the second information terminal” that is independently updated (e.g., a local merchant balance). Bhat’s balance concepts (offline reserve, remaining offline balance) are expressly defined for only one device, the user device (offline payment component 215). ¶¶ 64, 74, 75, 111, 112. Bhat does not disclose an analogous “offline balance” stored for the merchant payment system. Bhat discloses the merchant payment system 230 reading the payment approval message which confirms that the user device approved the offline payment and that its offline balance was decremented. ¶¶ 111–15. Bhat does not disclose that the merchant terminal sends a confirmation back that “allows the first information terminal to complete the transaction.” The Bhat payment flow is: user approves on user device, balance is updated on user device, user device sends approval to merchant, both devices store payment transaction and later report payment to the server. ¶¶ 110–17. There is no explicit communication where the merchant’s reading of the QR code is used to “allow” the first terminal to complete anything. Thus, Bhat does not disclose but Dunne discloses:
the second information terminal [mobile device 900] includes: a second memory configured to store balance data belonging to the second information terminal;
when the payment completion image information has been read, increase balance of the balance data stored in the second storage memory according to the transaction amount, and
(See at least Claim 1, “the payee device includes a second processor and a second memory comprising second computer program code.” See also Fig. 9 and associated text ¶ 49 (“The mobile device 900 may be a payer device or payee device as described above”). The payee token 155 (representing monetary value and includes balance data) is received and stored on the payee device 200. ¶ 39 (“a payee token 155 for the value of the sale is generated and locked to the payee device 200”). ¶ 40 (“A receipt for the sale may be stored within the payer device 100 and may be linked to the generated payee token 155 which is also stored on the payer device 100.”) ¶ 41 (“The payee token 155 may be then transmitted from the payer device 100 to the payee device 200, e.g., as a QR code scan”). Fig. 7 discloses the payment token carries balance data (monetary value of 25 Euro) with a sales receipt with attached payee token on the payee device. See also Fig. 5c. ¶ 30 (“A token may be a data packet (i.e. portion of data) which corresponds to a monetary value.”). ¶ 48 (“The payment information for each record may be maintained by the digital wallet and stored in a data storage unit such as a memory on the payer device 100.”) Because mobile device 900 “may be a payer device or payee device” this same architecture applies to both the payer and payee devices.
confirm that the payment has been completed in the first information terminal by reading the payment completion image in formation displayed on the first information terminal, and
(See at least ¶ 43, “The payer device 100 preferably transmits the token to the payee device 200 only in response to an input received from a user of the payer device 100 … user input is required in order to conduct the payment transaction.” Fig. 1, “Token Details Updated in In-App Virtual Wallet and BoS appears as a Receipt in Purchases with "Merchant Token" Attached”). ¶ 41 (“The payee token 155 may be then transmitted from
the payer device 100 to the payee device 200, e.g., as a QR code scan”). See also, ¶ 29.
allow the first information terminal to complete the transation [sic].
(See at least ¶ 41, “The transaction may be settled the next time either one of the payer device 100 or the payee device 200 connect to a secure network. Referring to FIG. 1, when the payer device 100 connects to a secure network, the transaction may be settled independent of the network connection status of the payee device 200. Similarly, when the payee device 200 connects to a secure network, the transaction may be settled independent of the network connection status of the payer device 100.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified Bhat's offline payment system— where the merchant payment system (second information terminal) receives a payment approval message via local communications (e.g., QR code scan) from the first user device (first information terminal), stores the message, and later syncs transaction details with a payment server to reconcile balances—with Dunne's teachings for peer-to-peer token exchange via QR code between payer device (first information terminal) and payee device (second information terminal). Specifically, Dunne teaches that the payee device confirms payment completion by reading (scanning) the payee token QR code displayed on the payer device screen, stores the token in its memory (updating its balance data), and allows the payer device to complete the transaction (e.g., settle independently upon network reconnection) as explained supra. Both references are in the same field of offline mobile payments using local communications (e.g., QR/NFC) between payer and payee/merchant devices to enable transactions without network connectivity to a server, then reconcile later. A POSITA would have been motivated to incorporate Dunne's QR code-based confirmation and payee-side balance storage into Bhat to provide visual confirmation of token/payment completion on the payer device (enhancing user trust and reducing errors in offline scenarios), enable the merchant device to immediately update and store its own balance data locally upon scan (mirroring payer-side updates for symmetry and faster local reconciliation), and ensure transaction completion on the payer side (e.g., via independent settlement), as both systems already use interchangeable local data (QR codes/payment approvals) for offline P2P/merchant exchanges with deferred server sync—this is a simple substitution of known confirmation mechanisms yielding predictable results with no change to Bhat's core offline reserve/balance flow.
Regarding Claim 2, Bhat and Dunne discloses:
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 4, Bhat and Dunne discloses:
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 and Dunne discloses:
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 and Dunne 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 and Dunne 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 and Dunne for the same rationale presented in Claim 1, supra.
Regarding Claim 11, Bhat and Dunne 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 and Dunne 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 3 is rejected under 35 U.S.C. 103 as being unpatentable over Bhat and Dunne and further in view of Kim (U.S. Pat. Pub. No. 2022/0207498) [“Kim”]
Regarding Claim 3, Bhat and Dunne discloses:
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.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Bhat and Dunne and further in view of Liberty et al. (U.S. Pat. Pub. No. 2014/0172531) [“Liberty”]
Regarding Claim 6, Bhat and Dunne discloses:
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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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).").