DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on Jul. 21, 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
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 emailing 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 .
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, 3, 5–8, 10, 28, 29 are pending and examined with Claims 1, 28, and 29 in independent form.
Claims 1, 3, 6, 28, and 29 are presently amended.
Claim 2 is presently cancelled; no claims are presently added.
Response to Amendment
Applicant's Amendment has been reviewed against Applicant’s Specification filed Apr. 19, 2024, [“Applicant’s Specification”] and accepted for examination.
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 Non-Final Office Action mailed May 4, 2026, [“Non-Final Office Action"]. The objection to Claims 1, 28, and 29 is withdrawn.
Applicant's Amendment to address the rejection under 35 U.S.C. § 101 because the claimed invention was directed to non-statutory subject matter has been reviewed and is persuasive. The rejection of Claim 29 under § 101 for being directed to non-statutory subject matter is withdrawn based on the amendment.
Response to Arguments
35 U.S.C. § 101 Argument
Applicant argues that the amended Claim 1 “is not an economic practice; rather, it is a technical solution proposed to address a specific technical defect in digital currency: the lack of global state synchronization in cross- institutional, offline environments. … Instead, it relies on a specific computer system architecture (terminal-backend interconnection, multi-institutional data synchronization) as a technical process.” Applicant’s Reply at 17.
Examiner respectfully disagrees. The identified exception is not merely the subject about “digital currency.” Rather, the claims explicitly recite “searching … a stored double-spending information list for double-spending information corresponding to the digital currency transaction information, and if the double-spending information corresponding to the digital currency transaction information is found, determining … that the double-spending verification has failed and the digital currency transaction is anomalous.” Claim 1. Those rules describe the economic practice of screening transactions for known double spending risk. MPEP § 2106.04(a)(2)(II)(A). Verifying a financial transaction to reduce risk of fraud or double payment is a fundamental economic practice that long predates computers. Bozeman Fin. LLC v. Fed. Reserve Bank of Atlanta, 955 F.3d 971, 978 (Fed. Cir. 2020) (“Verifying financial documents to reduce transactional fraud is a fundamental business practice that, without more, is not eligible for patent protection.”); Universal Secure Registry LLC v. Apple Inc., 10 F.4th 1342, 1353 (Fed. Cir. 2021) (“verifying the identity of a user to facilitate a transaction is a fundamental economic practice that has been performed at the point of sale well before the use of POS computers and Internet transactions”); Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307, 1313–14 (Fed. Cir. 2016) (receiving identifiers or paper mail, comparing them to or characterizing them from a known list of identifiers, and communicating the characterization or performing an action is an abstract idea).
Connectivity-depending architecture is considered at Step 2A, Prong Two but its recitation in the claims does not otherwise eliminate the identified judicial exception. Further, Applicant’s characterization of the amended claims as “technical” does not control. The Specification frames the problem solved as a financial risk problem, i.e., “the risk of double spending of the digital currency is high … so that the transaction security of the digital currency cannot be guaranteed” (Spec. ¶ 5), which is not a deficiency in the operation of any computer.
Applicant argues that the “data structure and method significantly improve the accuracy and real-time performance of verification … This defines a specific distributed system architecture, rather than a generic commercial process.” Applicant’s Reply at 18. Applicant further argues that the arrangement solves “how to ensure that a counterparty has not performed double-spending on a global scale when the terminal is offline and conducting cross-institutional transactions.” Applicant’s Reply at 17–18.
Examiner respectfully disagrees. The argument does not adequately explain why the claimed arrangement improves computer or network operation rather than the information used to assess transaction risk. Adding more entries to a blacklist makes the blacklist more complete but does not improve the computer itself. An improvement in the quality of the information used to make a risk decision is an improvement in the abstract idea itself. See, SAP Am., Inc. v. InvestPic, LLC, 898 F.3d 1161, 1163 (Fed. Cir. 2018).
Unlike the security profile in Finjan, Inc. v. Blue Coat Sys., Inc., 879 F.3d 1299. 1304–5 (Fed. Cir. 2018) which enabled a new kind of behavior based scanning, the claimed “stored double-spending information list compris[ing] first double-spending information and second double-spending information” merely enables the same lookup against a longer list.
Claim 1 does not require terminal pre-synchronization (that limitation is recited only in Dependent Claims), does not recite any “real-time” requirement, and does not recite that the local double-spending information list consulted in the offline branch does not contain any cross-institutional information. The cross-institutional “second double-spending information” is recited only in the stored list of the back-end system, which is consulted only when the terminal is online. Thus, the scenario Applicant identifies, i.e., a terminal “offline and conducting cross-institutional transactions” is address in Claim 1, if at all, by a local list of unspecified origin and connect.
The Specification confirmss that the terminal receives its local list only “[w]hen connecting to a network or performing an online service” (Spec, ¶ 64) so that any offline verification relies on information that is as current as the terminal’s last connection. The Specification further permits synchronization “periodically or under an agreed condition” (Spec. ¶ 104), which does not establish the asserted real time global verification while the terminal is offline. The scope of the claims is not commensurate with the argument.
Applicant argues that “This cross-institutional double-spending information synchronization mechanism based on interconnection protocols is not common general knowledge or a routine operation in the art.” Applicant’s Reply at 18–19. Applicant further argues that the recite steps of Claim 1 “constitute a complete technical closed loop with specific data flow and processing logic” and that “they define a specific mode of operation for the computer system within the digital currency network.” Applicant’s Reply at 19.
Examiner respectfully disagrees. The composition and source of the double-spending information (Limitations J and K) are part of the recited abstract idea because the y define what information is compared not how any computer operates, and the alleged novelty of the abstract idea is not legally relevant to eligibility. The WRC inquiry only applies to additional elements. MPEP § 2106.05(d). To the extent Applicant relies on the “interconnection and intercommunication” is treated as an additional element, the claim recites only the result, i.e., that “information is synchronously obtained … through interconnection and intercommunication” (Claim 1) by no particular protocol, or technical mechanism for achieving it. Claims that recite a desired result without the means of achieving it do not supply an inventive concept. Alternatively, an inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP § 2106.05(I); MPEP § 2106.04(d)(III). The Specification describes the synchronizing at the same level of generality by any known synchronizing technique. Spec. ¶ 65 (The double-spending information list … can be synchronized from other operating institution systems”); ¶ 104 (The various operating institutions may use a centralized or block chain manner to jointly maintain double-spending information of a user or digital currency. … and may synchronize double-spending information of the present operating institution to other operating institutions periodically or under an agreed condition.”).
The claimed “interconnection and intercommunication” and return of a verification result do not themselves identify the asserted “specific data sharing channels and synchronization logic.” Applicant’s Reply at 19. The amended ordered combination requires its own Step 2B analysis, but that requirement does not mean the ordered combination is nonconventional or inventive. Considered together, the amended limitations add nothing that is not already present when looking at additional elements individually. The “closed loop” merely receives data, looks it up locally or remotely depending on connectivity, and reports the result, which is a conventional client-server arrangement. MPEP § 2106.05(d)(II) (“Receiving or transmitting data over a network” is recognized by courts “as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner”). Further, the claimed offline/online arrangement is similar to the long-standing practice in the payment card industry in which a merchant lacking a connection to the card network consulted a printed list compiled from multiple issuing institutions and when a connection was available, submitted the transaction to the network for authorization. NPL Mastercard, “Chargeback Guide,” April 16, 2010 [“NPL MC Chargeback Guide”], § 2.1.2.3 (When to Obtain an Authorization The card acceptor must obtain an authorization from the issuer for: … Transactions in which the account number is listed in the applicable Warning Bulletin,” while “[i]n case of a POS device failure or telecommunication failure, the published floor limits apply”; § 2.1.2.5 (If a pick-up-card response is received, the card acceptor must not complete the transaction.”; § 2.1.3.3 (“IF” “The POS terminal is not online-capable and the final transaction amount does not exceed the card acceptor’s floor limit” “THEN” “The card acceptor is not required to obtain an authorization, but it must check the account number against the applicable Warning Bulletin.”); § 3.12.1 (chargeback reason code 4807, “Warning Bulleting File” … The issuer may use chargeback reason code 4807 if the following two conditions are met: The account number was listed in the Electronic Warning Bulletin File on the date of the transaction for the region or subregion in which the transaction was acquired.”; § 2.7.2.2. (“All magnetic stripe-read transactions, regardless of amount, must be authorized online by the issuer on a zero floor limit basis”); NPL MC Security, § 5.1.1 (The Electronic Warning Bulletin file or an effective regional Warning Notice lists the account number”); § 5.1.1.3 (“Neither MasterCard nor any Customer shall be liable for loss, costs, or other damages for claims declared against them by an Issuer for requested actions in the listing of an account or a Group or Series listing on the Electronic Warning Bulletin file or in the applicable regional Warning Notice by the Issuer.”); NPL Warning Bulletin, at 001-002. (All cited on PTO-892).
35 U.S.C. § 103 Argument
Applicant’s arguments with respect to Claims 1, 3, 5–8, 10, 28, 29 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 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, 3, 5–8, 10, 28, 29 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, 3, 5–8, 10, 28, 29 are directed to a statutory category. Claims 1, 3, 5–8 recite a “method” and are therefore, directed to the statutory category of a “process.” Claim 28 recites a “device” and is therefore, directed to the statutory category of a “machine.” Claim 29 recites a “ “non-transitory computer-readable medium, on which a computer program is stored” and is therefore, directed to the statutory category of an "article of manufacture.”
Representative Claim
Claim 28 is representative [“Rep. Claim 28”] 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.
[A] 28. An electronic device, comprising: one or more processors; a memory for storing one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors implementing following actions:
[B] receiving, by a first terminal application, digital currency transaction information of a digital currency transaction sent from a second terminal application;
[C] in cases where the first terminal application does not establish a network connection with the first operating institution back-end system,
[D] searching, by the first terminal application, a local double-spending information list for double-spending information corresponding to the digital currency transaction information; and
[E] if the double-spending information corresponding to the digital currency transaction information is found, determining, by the first terminal application, that the digital currency transaction is anomalous;
[F] in cases where the first terminal application establishes a network connection with the first operating institution back-end system,
[G] sending, by the first terminal application, the digital currency transaction information to the first operating institution back-end system;
[H] searching, by the first operating institution back-end system, a stored double-spending information list for double-spending information corresponding to the digital currency transaction information, and
[I] if the double-spending information corresponding to the digital currency transaction information is found, determining, by the first operating institution back-end system, that the double-spending verification has failed and the digital currency transaction is anomalous, wherein the double-spending information in the stored double-spending information list comprises first double-spending information and second double-spending information,
[J] the first double-spending information is generated by the first operating institution back-end system based on an anomaly of one or more of the following information: version information of a digital currency issued by the first operating institution itself, user wallet information corresponding to the issued digital currency, and digital currency information, and
[K] the second double-spending information is synchronously obtained by the first operating institution back-end system from other operating institutions back-end systems through interconnection and intercommunication; and
[L] returning, by the first operating institution back-end system, to the first terminal application a verification result indicating that the digital currency transaction is anomalous.
Claims are directed to an abstract idea exception.
Step 2A, Prong One: The normal font limitations of Rep. Claim 28, Limitations B, D, E, G, H, I, J, K, and L, recite a fundamental economic principle/practice under the certain methods of organizing human activity exception of mitigating transaction risk (here, the risk of double-spending or fraud) because said Limitations describe concepts relating to the economy and commerce, such as determining whether a digital currency transaction is anomalous and “mitigating risks” thereof. MPEP § 2106.04(a)(2)(II)(A); see Alice Corp. v. CLS Bank Int’l, 573 U.S. 208, 219–20 (2014) (intermediated settlement to mitigate settlement risk); Bozeman, 955 F.3d at 978 (“Verifying financial documents to reduce transactional fraud is a fundamental business practice that, without more, is not eligible for patent protection.”); Universal Secure Registry, 10 F.4th at 1353 (“verifying the identity of a user to facilitate a transaction is a fundamental economic practice that has been performed at the point of sale well before the use of POS computers and Internet transactions”); Intellectual Ventures I, 838 F.3d at 1313–14 (receiving identifiers or paper mail, comparing them to or characterizing them from a known list of identifiers, and communicating the characterization or performing an action is an abstract idea). Limitation J and K, which specify the content and source of information in the list, further narrow the abstract idea and are not additional elements. Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1355 (Fed. Cir. 2016) (“selecting information, by content or source, for collection, analysis, and display does nothing significant to differentiate a process from ordinary mental processes, whose implicit exclusion from § 101 undergirds
the information-based category of abstract ideas”).
Alternatively, Limitations D, E, H, and I, 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). Searching a list for an entry corresponding to received transaction information and if the entry is found, determining that the transaction is anomalous, is an observation, evaluation, and judgment that can be practically performed in the human mind or with pen and paper. In fact, it was performed for decades in the payment card industry. Credit card vendors, Mastercard® ad Visa®, distributed weekly to merchants in paper format, a list of cancelled, past due, or stolen credit account numbers called a “Warning Bulletin.” NPL Warning Bulletin, p.001; NPL MC Chargeback Guide, §§ 2.1.2.3, 3.12.1 (Warning Bulletin and Warning Bulleting File are network wide listings of account numbers that must be checked merchants.). Merchant acceptance procedures mandated a merchant whose terminal was “not online-capable” to “check the account number against the applicable Warning Bulletin.” NPL MC Chargeback Guide, § 2.1.3.3; see also §§ 2.1.2.3. If the account number was listed, the Merchant could not complete the transaction without authorization and upon a pickup response, was required to refuse the transaction and retain the card. NPL MC Chargeback Guide, §§ 2.1.2.3, 2.1.2.5. Thus, a clerk presenting a credit card with a number printed in the Warning Bulletin performs exactly the same comparison and judgment recited in Limitations D, E, H, and I. Substituting a wallet identifier or digital currency serial number for the account number and a generic processor for the clerk does not change the abstract character of these Limitations. MPEP § 2106.04(a)(2)(III)(A); CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372–73 (Fed. Cir. 2011) (held a claim for a method of detecting fraud in credit card transactions that consisted of obtaining transaction information associated with an IP address, storing the transaction information in a list, and utilizing the list to determine if the transactions are fraudulent was invalid because all three steps could “be performed in the human mind, or by a human using a pen and paper.”).
The mere fact that the data involved represents “digital currency transaction” does not change the abstract nature of the claimed steps, as applying the abstract idea to a particular field or type pf data does not render the concept patent eligible. MPEP § 2106.05(h) (citing Intellectual Ventures I LLC v. Capital One Bank (USA), N.A., 792 F.3d 1363, 1366, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015)); see also MPEP § 2106.05(a).
Step 2A, Prong Two: Rep. Claim 28 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: An electronic device, comprising: one or more processors; a memory for storing one or more programs; a first terminal application; a second terminal application; and the first operating institution back-end system.
Regarding the electronic device, comprising: one or more processors; a memory for storing one or more programs; a first terminal application; a second terminal application; the first operating institution back-end system; Limitation C; and Limitation F, 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 Myers, 410 F.2d 420, 424 (CCPA 1969) (“[T]he specification need not disclose what is well known in the art”). E.g., Spec. ¶ 39 (describing claimed “electronic device” as simply “comprising one or more processors” and “a memory for storing one or more programs” that implement the claimed method, with no further structural detail); ¶ 56 (all embodiments as “merely exemplary” and noting that “illustrations of well-known functions and structures are omitted”); ¶ 147 (describing terminal devices as “various electronic devices,” including but not limited to “a smart phone, a tablet computer, a laptop portable computer, a desktop computer, etc.”); ¶ 151 (“The terminal device or server shown in Fig. 12 is only an example, and should not bring any limitation to the functions and use scope of the embodiments of the present disclosure”); ¶ 152 (describing the CPU 1201 as a standard processor that “can perform various suitable actions and processes in accordance with a program stored in a read only memory ROM 1202 or a program loaded from a storage portion 1208 into a random access memory RAM 1203”); ¶ 157 (modules “may be implemented by software or hardware” and arranged “in a processor,” indicating the components are generic and interchangeable). The generic processor, here, appears to perform calculations (functions) that are programmed by software. Spec. ¶ 152. This is a computer doing what it is designed to do—performing directions it is given to follow.
Limitation A describes the processor executing programs stored in memory to perform the steps of the claimed invention. This takes generic hardware and describes the functions of receiving, storing, and sending data (instructions) between the processor and memory, which merely invokes computers or other machinery in its ordinary capacity to receive, store, or transmit data. MPEP § 2106.05(f)(2). Limitations B–L describe the processor, memory device, and instructions, performing the steps of the claimed invention, which represents the abstract idea exception itself. 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).
Limitations B, G and L are, in the alternative, insignificant extra solution activity because they are data gathering and data output steps necessary to perform the abstract idea and are recited at a high level of generality. MPEP § 2106.05(g). Limitations C and F do not recite elements that establish, tests, or manages a connection. Rather, they merely identify the technological environment in which the search is performed and select between two generic channels (local and remote search) for performing the same mental comparison. Generically inking the use of the judicial exception into a particular technological environment or field of use does not integrate the abstract idea exception into a practical application. MPEP § 2106.05(h).
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. Merchants lacking an online connection checked a presented credit card account number against a weekly issued paper “Warning Bulletin” of “canceled, past due, and stolen credit cards.” NPL Warning Bulletin, p.001; NPL MC Chargeback Guide, §§ 2.1.2.3, 2.1.3.3, 3.12.1; NPL NC Security, Chapter 5 (all), § 5.1.1.3. Where, as here, the claims merely automate a previously manual process using generic computer components, computer is being used as a tool to perform the pre-0existing process, not improved.
The specification confirms this characterization by describing the advantages of the claimed system in terms of business outcomes (“reducing the risk of double-spending” and “ensuring the transaction security of the digital currency”), rather than in terms of any specific technical improvement to the terminal, back-send systems, or the network itself. Spec. ¶¶ 3–5. 85, 159. The specification does not describe any specific technical improvement to connection detection, search, synchronization technology, communication channels, or computer architecture. Spec. ¶¶ 104, 108. 151–157.
To the extent the claimed invention is asserted to provide a technical solution, that solution is not commensurate with the scope of the claims. The specification describes the alleged technical solution as: (1) a local list “pre-synchronized” from the back-end and “stored in a local security chip” for offline verification (Spec. ¶¶ 63, 66); (2) online verification “preferentially” against a list “jointly maintain[ed]” by multiple institutions (Spec. ¶¶ 68, 65); and (3) a “blocking request” and local list update upon an anomaly. Spec. ¶¶ 69, 70. The claims, however, do not capture this solution. The claims do not recite the source, content, or storage of the offline list; any cross-institutional data in the offline branch; how the second double-spending information is “synchronously obtained” or any blocking of a detected double spender. Notably, these features appear only in dependent claims and are absent from Rep. Claim 28. Instead, the claims recite the asserted offline, cross-institutional double-spending protection as results obtained on generic components. Under MPEP § 2106.05(a), the claims must recite the improvement with sufficient specificity to reflect how the improvement is achieved, rather than claiming the desired outcome using generic components.
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 28 is directed to an abstract idea.
Independent Claims 1 and 29 are not substantially different than Rep. Claim 28, recite the same abstract idea as Rep. Claim 28, and contain no additional elements not otherwise analyzed for Rep. Claim 28. Therefore, Independent Claims 1 and 29 are also directed to the same abstract idea.
The claims do not provide an inventive concept.
Step 2B: Rep. Claim 28 fails Step 2B because the claim as whole, even when considering the additional elements individually and in combination, does not 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 generic computer components. See MPEP § 2106.05(f). The same analysis applies here in Step 2B. Mere instructions to apply a judicial exception on a computer and/or with basic computer components do not 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’ combination of additional elements is not inventive. First, each additional element represents currently available generic computer technology, used in a conventional manner (individually generic). The functions of those elements perform, receiving and transmitting over a network (Limitation B, G, L) and storing and retrieving information from memory (Limitations D, H, I (wherein clause)), which are activities courts have recognized as well understood, routine, and conventional [“WRC”] before the October 21, 2021 effective filing date when claimed, as here, in a merely generic manner. Second, Applicant’s Specification discloses that the combination of additional elements relies on conventional computer components and functions. Spec. ¶ 56 (all embodiments are “merely exemplary” and that “illustrations of well-known functions and structures are omitted in the following description.”); ¶ 156 (stating that the functions of the claimed steps “may occur in an order different from those marked in the drawings” and “may, in fact, be executed basically in parallel or in a reverse order,” confirming no specific technical interdependence among the claimed functions); ¶ 157 (the claimed modules “may be implemented by software or hardware” and can be “arranged in a processor.”); ¶¶ 39, 56, 147, 151, 152, 157, Fig. 12 (describing exemplary, known and generic computer equipment and networks). By describing these components only in an exemplary manner, Applicant represents they are so well known that no description was required under § 112(a). Lindemann, 730 F.2d at 1463.
Accordingly, the additional elements of Rep. Claim 28 are elements that have been recognized, based on Applicant’s own disclosure, as well-understood, routine, and conventional (“WURC”) activity in the field. See, Spec. ¶¶ 39, 56, 147, 151, 152, 157, Fig. 12; MPEP § 2106.05(d). Specifically, Applicant’s Specification describes the recited additional elements (i.e., the electronic device, comprising: one or more processors; a memory for storing one or more programs; a first terminal application; a second terminal application; the first operating institution back-end system; Limitation C; and Limitation F) as being implemented using generic, off-the-shelf computing technology. These elements do no more than “apply” the recited abstract idea(s) using known computer and computer-related components. The Specification also shows that the functions of receiving, storing, transmitting, and processing (e.g., performing logic or mathematical operations on) data are normal, well-understood operations of generic computer systems. See, e.g., Spec. ¶¶ 110, 148, 152, 153, 154 (describing receiving, storing, transmitting, displaying, and processing data as standard, off-the-shelf functions of the generic computer components depicted in Fig. 12).
Third, the ordered combination of additional elements (bond font) in Limitations A–L is WRC. The arrangement of a local list consulted when the terminal is offline and mandated industry wide for every card acceptance location in a Mastercard ® network for at least a decade before the effective filing date is shown in NPL MC Chargeback Guide (§§ 2.1.2.3, 2.1.2.5, 2.1.3.3, 3.12.1). A procedure required of every merchant in a worldwide card network is by definition, “widely prevalent or in common use,” not merely known. MPEP § 2106.05(d)(I). Prior art of record FOR EP 3743871 A1 (Dec. 2, 2020) discloses the same sequence on the same components: terminals with “a programmable microprocessor” and memory executing stored instructions (pp. 2, 10) (Limitation A); a collection terminal receiving transaction information from a payment terminal over “an exchange link (40)” (p.20) (Limitation B); a payment terminal that, when it lacks a connection to the set of servers, (1) “compares the key Kpa to the content of the list Lu. If the key Kp n belongs to the list Lu the process stops and the transaction between the terminals 20 and 22 is not performed.” FOR, p.13; (Limitations C, D, E) (2) “connects to the server 60 and updates the list” and “connects to the server 62 and updates the list LRev from the information downloaded from the server 62” when a connection is available. FOR, p.12; (3) and relies on “the set of servers” to “verify the absence of double-spending” before a transaction is recorded. FOR, pp. 6, 17 (Limitations F, G, H).
Prior art of record Maeng (U.S. Pat. No. 11,107,066) discloses a “mobile wallet 110 may first determine whether it is online or otherwise in communication with the mobile wallet management system 131. If the mobile wallet 110 is in communication the mobile wallet management system 131, it may initiate the payment in conjunction with the mobile wallet management system 131.” Maeng, Col. 5:49–54. The management system accepting or rejecting the transaction according to the wallet’s online/offline status and sending as authentication message reporting the result Maeng, col. 12:4–34, Claim 1 (Limitations F, G, L). As to the backend search and determination (Limitations H and I), FOR servers “in response to the receipt of any transaction … verify the absence of double-spending by checking that there is not a transaction of the same object from the same starting address already registered in the blockchain,” and records the transaction “only if these verifications confirm the validity.” FOR, p.3. Maeing’s wallet management system rejects the transaction when its determination fail (col. 12:23–34). As t the composition of the list (Limitations J and K), as explained in Step 2A, Prong One, is part f the abstract idea.
To the extent Applicant contends that synchronizing is an additional element, synchronizing a shared list among institutions by any known means is the conventional data exchange the courts have recognized. MPEP § 2106.05(d)(III). The same arrangement was mandated across the payment industry. NPL Mastercard, “Security Rules and Procedures,” March 31, 2016 [“NPL MC Security”] requires each acquirer to educate its merchants in “use of the Electronic Warning Bulletin file or Warning Notice, authorization procedures including Code 10 procedures,” NPL MC Security, § 7.3, and mandates retention of a card at the point of sale when “[t]he Electronic Warning Bulletin file or an effective regional Warning Notice lists the account number.” Id. at § 5.1.1. The Electronic Warning Bulletin being issued to identify “stolen credit cards” and updated in “real time”. NPL Wayback Machine, Investopedia, Warning Bulletin, February 21, 2021, [“NPL Warning Bulletin”], p.001. A procedure required of every merchant in a worldwide card network is by definition, “widely prevalent or in common use,” not merely known. MPEP § 2106.05(d)(I). The Specification is consistent by describing the terminal’s list as refreshed “together” with routine “recharging, withdrawing, and synchronizing” operations, Spec. ¶ 64, and the inter-institution synchronization as occurring “periodically or under an agreed condition” by “a centralized or block chain manner.” Spec. ¶ 104. All of this occurs by any means—a technical mechanism is not disclosed by the Specification. Because each additional element, individually and in ordered combination, was WRC, the additional elements supply no inventive concept.
There is no indication in the claim language or in the Specification that the combination of elements improves the functioning of a computer itself or improves any other technology or technical field. Rather, the additional elements simply implement the abstract idea on a conventional computer system at a high level of generality. Looking at the additional elements in combination adds nothing that is not already present when looking at the elements individually. The combination is the conventional offline local list / online remote verification arrangement. Their collective functions merely provide a conventional computer implementation of the abstract idea. Thus, Rep. Claims 28 does not provide an inventive concept.
Independent Claim 29 is a computer-readable medium claim whose instructions cause a system to perform the same abstract processing and generic computer operations recited in Rep. Claim 28. Independent Claim 1 is a method claim whose steps perform the same abstract processing and generic computer operations recited in Rep. Claim 28. Independent Claims 1 and 29 add no additional elements beyond those of Rep. Claim 28 that would amount to significantly more than the abstract idea. Therefore, Independent Claims 1 and 29 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. 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 Claim 6 merely specify which branch of Claim 1’s anomaly determination is executed—offline or online. Neither Claim introduces elements outside the scope of the abstract idea itself. Searching a list and sending data over a network are routine computer functions and not a practical application or inventive concept. Spec. ¶¶ 56, 61, 67,106.
Dependent Claims 3 and 5. Claim 3 adds pre-synchronization of the double spending list from the back-end system to the terminal, which is a conventional client-server data transmission. Spec. ¶¶ 64, 105; see also FOR, p.12; Maeng col. 8:14–40.. Claim 5 specifies storing that list in a security chip. The claimed “local security chip” is a well known piece of generic hardware used for its ordinary purpose. Spec. ¶¶ 56, 66, 115. Neither Claim 3 or Claim 5 improves any technology or supplies an inventive concept.
Dependent Claim 7 adds a priority rule favoring online verification, which is a logical ordering instruction that is itself abstract. Spec. ¶¶ 14, 68, 156. An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III).
Dependent Claim 8 adds either a blocking request (a routine network command) or a local list update (a basic database write) upon anomaly detection, Spec. ¶¶ 69, 70, 107, 120. These are generic computer functions that nether integrate the exception into a practical application of provide an inventive concept based on Applicant’s own disclosure. Id.
Dependent Claim 10 defines the data fields comprising double spending information. Enumerating data categories merely further limits the abstract idea of the independent claims and conta8ins no additional elements. These are standard financial transaction record fields. Spec. ¶¶ 17, 56, 71, 104. An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III).
Conclusion
Claims 1, 3, 5–8, 10, 28, 29 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 28 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–3, 5–8, 10, 28, 29 are rejected under 35 U.S.C. 103 as being unpatentable over FOR: EP 374387 A1 [“Seigneur”] in view of Maeng (U.S. Pat. No. 11,107,066) [“Maeng”] and further in view of Zhu et al. (U.S. Pat. Pub. No. 2020/0286076) [“Zhu”]
Regarding Claim 1, Seigneur discloses:
A method of verifying an anomalous [absence of double spending] digital currency transaction, comprising:
(See at least p. 2, “The invention relates to a secure system and method for transactions between terminals.” “to verify the absence of double-spending by checking that there is not a transaction of the same object from the same starting address already registered in the blockchain” p. 3.)
receiving, by a first terminal application [terminal 22], digital currency transaction information of a digital currency transaction sent from a second terminal application [terminal 20];
(See at least p. 20, “the payment and collection terminals (20, 22) are able to establish, via their respective transmitters / receivers, an exchange link (40) information between them.” “the cryptoprocessor transmits (126, 136) to the collection terminal, via the information exchange link, the first private key or the second signed transaction constructed by the cryptoprocessor” p. 21. “if the terminal 22 is equipped with a cryptoprocessor it can also be used in as a payment terminal. For example, it is programmed to be able to function as the terminal 20,” which permits terminal 22 to be the payment terminal. p. 15. The terminals 20, 22 have “a programmable microprocessor” and “instructions, executable by the cryptoprocessor 28,” which are the claimed applications. p. 10.)
in cases where the first terminal application does not establish a network connection with the first operating institution back-end system [offline], searching, by the first terminal application, a local double- spending information list for double-spending information corresponding to the digital currency transaction information; and if the double-spending information corresponding to the digital currency transaction information is found, determining, by the first terminal application, that the digital currency transaction is anomalous [interruption of the transaction];
(See at least p. 20, even if there is no connection with the set of servers, the payment and collection terminals (20, 22) are able to establish, via their respective transmitters / receivers, an exchange link (40).” “The list Lu contains transaction data already used to generate and perform an off-line transaction. This Lu list is used here to prevent double-spending for off-line transactions.” p. 12. “In response, during a step 124, if the user has selected the "anonymous transaction" option, the cryptoprocessor 28 compares the key Kpa to the content of the list Lu. If the key Kp n belongs to the list Lu the process stops and the transaction between the terminals 20 and 22 is not performed. Indeed, if the key Kpa already belongs to the list Lu it means that the X Bitcoins associated with the address @i have already been spent. The interruption of the transaction in this case therefore prevents double-spending. If the key Kpil does not belong to the list Lu, the process continues with a step 126.” p. 13. “In response to the reception of the address @ 2, during a step 132, the cryptoprocessor 28 compares the keys Kpri , Kpubi and the address @i to the content of the list Lu . If one of the keys Kpn, Kpubi and the address @i belongs to the list Lu , the process stops and the transaction between the terminals 20 and 22 is not performed. Indeed, as already explained next to step 124, this means that the X Bitcoins
associated with the address @i have already been spent. The interruption of the transaction in this case therefore prevents doublespending. If the keys Kpn, Kpubi and the address @i do not belong to the list Lu , the process continues with a step 136.” p.14.)
in cases where the first terminal application establishes a network connection with the first operating institution back-end system, sending, by the first terminal application, the digital currency transaction information to the first operating institution back-end system;
(See ay least p.2, “the payment and collection terminals are able to transmit all transactions built or received to the set of servers when they are connected to this set of servers”. p.14, “during a step 154, the terminal 22 connects to the servers 6 and informs them of the transaction T 2 received during step 136. The transaction T 2 is then verified by these computer servers and then recorded in the blockchain.” p.14, “when the terminal 22 connects again to the set 6 of servers, it transmits the transaction T 3 to the computer servers of the together 6 to be registered in the blockchain.” p.17 “as soon as the terminal 20 connects to a computer server of the set 6, the cryptoprocessor 28 automatically transmits it. also this transaction T 2 to this set 6 of computer servers.” User may, “perform an online transaction in a conventional way.” p.17)
searching, by the first operating institution back-end system, a stored double-spending information list for double-spending information corresponding to the digital currency transaction information, and if the double-spending information corresponding to the digital currency transaction information is found, determining, by the first operating institution back-end system, that the double-spending verification has failed and the digital currency transaction is anomalous,
(See at least p.9, “Before registering a transaction in a block, the computer server checks the validity of this transaction by executing the first and second scripts it contains. The computer server also verifies that the starting address contained in this transaction has not already been used for a previous transaction already registered in the blockchain. This last check makes it impossible or almost impossible to double-spend.” p.3, “If the starting address of the received transaction has already been used, the set of computer servers considers this transaction invalid and is therefore not registered in the blockchain. Thanks to this, double-spending is made impossible.” p.12, “the servers of the set 6 ensure that the starting address contained in this transaction Ti has not already been used for another transaction already recorded in the blockchain. If the transaction Ti is valid, then the computer servers of the set 6 register it in the blockchain. Otherwise, that is, if the IT servers determine that the transaction Ti is invalid, it is not registered in the blockchain.” p.3, “to verify the absence of double-spending by checking that there is not a transaction of the same object from the same starting address already registered in the blockchain, and • only if these verifications confirm the validity of the transaction received and the absence of double-spending, to record the transaction received in the blockchain” p.9, “The chain of blocks is distributed among the many computer servers. For this purpose, each computer server has a memory in which is recorded part or all of the block chain.”
Seigneur does not disclose the double-spending information in the stored double-spending information list comprises first double-spending information and second double-spending information, the first double-spending information is generated by the first operating institution back-end system based on an anomaly of one or more of the following information: version information of a digital currency issued by the first operating institution itself, user wallet information corresponding to the issued digital currency, and digital currency information, and the second double-spending information is synchronously obtained by the first operating institution back-end system from other operating institutions back- end systems through interconnection and intercommunication. Seigneur’s set 6 is a single peer-to-peer set of mining servers. pp. 9, 10. Seigneur does not disclose returning, by the first operating institution back-end system, to the first terminal application a verification result indicating that the digital currency transaction is anomalous. Seigneur servers merely decline to register an invalid transaction and the terminal “must wait for it to bevalidated by the set of servers, then check that it has been registered in the blockchain.” p.3. No message indicating an anomaly is returned by the servers to the terminal. Thus, Seigneur does not disclose but Maeng discloses:
wherein the double-spending information in the stored double-spending information list comprises first double-spending information and second double-spending information, the first double-spending information is generated by the first operating institution back-end system
(See at least col. 14:14–19, “At action 708, the financial institution system may generate financial institution token data. The financial institution token data may be data describing the element or elements of the mobile wallet held at a financial institution implementing the financial institution system” Col. 14:67–15:7, “the financial institution system may authenticate the financial institution token data by determining whether the financial institution token data (raw or encrypted) matches financial institution token data stored at the financial institution system. If the financial institution token data is not authenticated, the financial institution system may, at action 808, send a payment denial message to the POS device indicating that the requested payment is not authorized.” Col. 12:37–40, “the wallet management system may compare the oflline token received from the financial institution system with reference data stored at the wallet management system” Col. 12:47–50, “If the wallet management system determines that the oflline token does not match the reference data or is otherwise not authenticated, it may send the rejection message at action 616.”)
based on an anomaly of one or more of the following information: version information of a digital currency issued by the first operating institution itself, user wallet information corresponding to the issued digital currency, and digital currency information, and
(See at least col. 4:28–30, “the oflline token 160 may comprise mobile wallet identification data 162. Mobile wallet identification data 162 may uniquely identify the mobile wallet 110.” Claims 8, “determine that the mobile wallet identification data matches stored mobile wallet identification data associated with the mobile wallet application at the data storage.” col. 13:20–33, “if the user of a mobile wallet loses a mobile computing device storing one or more oflline tokens, the user may notify the wallet management system, for example, by sending a lost mobile computing device message. The wallet management system may store the lost 25 mobile computing device message in association with the mobile wallet. The wallet management system may check for a lost mobile computing device message associated with a mobile wallet before authenticating an oflline token for the mobile computing device. For example, if a lost mobile 30 computing device message has been received for a mobile wallet, the wallet management system may reject the authentication request.” Col.12:48–62, 4”50–56 (“digital currency information)
the second double-spending information is [ ] obtained by the first operating institution back-end system from other operating institutions back- end systems through interconnection and intercommunication; and
(See at least col. 15:8–30, “the financial institution may, at action 810, send to the wallet management system an authentication request message 809. The authentication 10 request message 809 may comprise all or a portion of the oflline token. For example, the authentication request message 809 may omit a portion of the oflline token corresponding to financial institution token data. At action 812, the wallet management system may receive 15 the authentication request message. The wallet management system may authenticate the oflline token ( or portion thereof) included in the authentication request message. Authentication may be performed, for example, as described with respect to the process flow 600. If the oflline token is 20 authenticated, the wallet management system may send an authentication message 805 to the financial institution system at action 816. The financial institution system may receive the authentication message at action 822 and send to the POS device a transaction authorization message at action 25 824. On the other hand, if the oflline token is not authenticated at action 814, the wallet management system may, at action 818, send an authentication failure message 807 to the financial institution system. In response, the financial institution system may, at action 820, send to the POS device a 30 payment denial message.”)
returning, by the first operating institution back-end system, to the first terminal application a verification result indicating that the digital currency transaction is anomalous.
(See at least col. 15:4-7, “the financial institution system may, at action 808, send a payment denial message to the POS device indicating that the requested payment is not authorized. Col. 15:29-30, “the financial institution system may, at action 820, send to the POS device a 30 payment denial message.” Col. 12:23-27, “send to the financial institution a rejection message comprising data indicating that the oflline token is not authenticated and/or that the payment should not proceed with the oflline token.” Col. 10:4-6, “Upon receiving the payment authorization message 418, the POS device may send a payment complete message to the mobile wallet 110 at action 420.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined the double-spending information in the stored double-spending information list comprises first double-spending information and second double-spending information, the first double-spending information is generated by the first operating institution back-end system based on an anomaly of one or more of the following information: version information of a digital currency issued by the first operating institution itself, user wallet information corresponding to the issued digital currency, and digital currency information, and the second double-spending information is synchronously obtained by the first operating institution back-end system from other operating institutions back- end systems through interconnection and intercommunication; and returning, by the first operating institution back-end system, to the first terminal application a verification result indicating that the digital currency transaction is anomalous, as taught by Maeng, to the known invention of Seigneur, in the same field of invention, with the motivation to allow the offline terminal side checks in Seigneur to be coordinated with an institution back end (wallet management server) that maintains explicit online/offline state for the terminal (wallet) application and rejects or authenticates transactions based on that state to avoid fraud and improve security for making payments with mobile computing devices. Maeng, col. 1:12–14; Col. 2:14–19; col. 9:52–53.)
Seigneur or Maeng do not disclose that the second double spending information is synchronously obtained by the first operating institution back end system from other operating institutions back end systems as part of the sored double spending information list. Maeng’s cross institution information (authentication failure message 807) is obtained by request for a single transaction. Col. 15:8–30. Thus, Seigneur does not disclose but Zhu discloses:
wherein the double-spending information in the stored double-spending information list comprises first double-spending information and second double-spending information … the second double-spending information is synchronously obtained by the first operating institution back-end system from other operating institutions back-end systems through interconnection and intercommunication
(See at least ¶ 13, “the one or more authorized institutions are to perform the transaction verification through two database lists including an anti-double-spend list and a transaction completion list.” ¶ 44, “all used addrids are recorded in the anti-double-spend list, thus after receiving the transaction, the commercial banks may compare all the input addrids in Sin with the data in the list. If duplicate items are found, it is proved that there is a double-spend, so that the transaction cannot be approved and thus the transaction fails.” ¶ 10, “the central node is a central bank, and the one or more authorized institutions are commercial banks.” ¶ 14, “the central node is a central bank, and the one or more authorized institutions are commercial banks.” ¶ 47, “the central bank may calculate Sout to form addrid, such as addridnew=(tx, indextx, v), and then broadcast it to inform all commercial banks to update the addrid list.” ¶ 51, “it is used to synchronize the account book for the central-bank commercial-bank. … the existence of the chain B may enable the commercial banks to synchronize their own database lists in real time to maintain stable operation of the system” ¶ 5, “the central bank and commercial banks will form a hierarchical coalition chain network, where only the commercial banks authorized by the central bank are qualified to verify the digital currency transaction” ¶ 9, “a second link of the two links is used for access by the central node and the one or more authorized institutions.” See also ¶ 41.
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 Seigneur’s terminal and server set double spending checks with Maeng’s operating institution backend that to the offline terminal side checks in Seigneur to be coordinated with an institution back end that maintins an explicit online.offline state for terminal application and rejects or authenticates transactions based on that state to avoid fraud and improve security for making payments with mobile computing dvice. Maeng, col.1:12-14, col. 2:14-19, col 9:52-53 and with the further rmotiation that an express denial message allows the terminal to terminate the transaction immediately rather than wait t inspect the blockchain, which Seigneur identifies as inappropriate for small purchases.
Regarding Claim 3, Seigneur, Maeng, and Zhu disclose:
The method as claimed in claim 1 and double-spending information in the local double-spending information list
Seigneur further discloses
wherein double-spending information in the local double-spending information list is pre-synchronized to the first terminal application by the first operating institution back-end system.
(See at least p.12, “In a step 106, the cryptoprocessor 28 connects to the server 60 and updates the list Rep Rep from the information downloaded from this server 60. In this step, the cryptoprocessor 28 also connects to the server 62 and updates the list LRev from the information downloaded from the server 62.” “The list L Rev includes a list of revoked cryptographic certificates. These revoked cryptographic certificates are no longer usable.” p.11.)
Regarding Claim 5, Seigneur, Maeng, and Zhu disclose:
The method as claimed in claim 3 and the local double- spending information list
Seigneur further discloses
wherein the local double- spending information list is stored in a local security chip [secure memory of crypto-processor] of the first terminal application [terminal 20].
(See at least Abstract, “a crypto-processor (28) of a payment terminal (20) is capable: of transmitting to a collection terminal (22) a private key which is the only one able to validly sign a transaction of an object or to transmit the signed transaction, then - of recording, in a secure memory, an identifier of the object which is transferred by the transaction, then - when a new transaction is constructed by the crypto-processor, of comparing the identifier of the object which is transferred by this new transaction to the identifier of the transferred object which is recorded in the secure memory, and - only if these identifiers
match, of preventing this new transaction from being transmitted to the collection terminal.”
Regarding Claim 6, Seigneur, Maeng, and Zhu disclose:
The method as claimed in claim 1 and wherein the executing, by the first terminal application, a corresponding anomaly determination operation according to the network connection state of a first operating institution back-end system, to determine that the digital currency transaction is anomalous
Seigneur further discloses
6. (Currently Amended) The method as claimed in claim 1, wherein the method further comprising: in cases where the first terminal application establishes a network connection with the first operating institution back-end system,
searching, by the first terminal application, a local double- spending information list for double-spending information corresponding to the digital currency transaction information; and
if the double-spending information corresponding to the digital currency transaction information is found in the local double-spending information list[interruption of transaction].
(Seigneur teaches a device to device anonymous transaction using a link. p.13 (“From now on, all the message exchanges between the terminals 20 and 22 are made via the secure link 40. In step 116, the cryptoprocessor 28 acquires via the man-machine interface 32 the choice of the user between two options, respectively, "anonymous transaction"). After confirmation of that transaction is step 120, “the cryptoprocessor 28 compares the key Kpa to the content of the list L u . If the key K p n belongs to the list Lu the process stops and the transaction between the terminals 20 and 22 is not performed. Indeed, if the key K already belongs to the list L u it means that the X Bitcoins associated with the address @i have already been spent. The interruption of the transaction in this case therefore prevents double-spending. If the key Kpil does not belong to the list Lu, the process continues with a step 126. In step 126, the cryptoprocessor 28 transmits to the terminal 22 the key K p n, the key Kpubi, the Bitcoins amount transferred to the terminal 22, and the address @ 1. Therefore, the terminal 22 is capable of constructing a signed and valid transaction from the starting address address @i to another destination address. Thus, the X bitcoins associated with the address @ i have been transferred from the terminal 20 to the terminal 22. Moreover, in this case, this transaction is anonymous because it leaves no trace in the blockchain even after a Valid transaction from the address @i to another address @ 2 was built by the terminal 22, then registered in the blockchain when the terminal 22 is connected again to the set 6.”) p.13. “Subsequently, in the case where the option "anonymous transaction" had been selected, in a step 152, the terminal 22 builds a transaction T 3 from the address @i to another address @ 3 . The transaction T 3 is signed with the key K p n received during the step 126. Then, when the terminal 22 connects again to the set 6 of servers, it transmits the transaction T 3 to the computer servers of the together 6 to be registered in the blockchain. The terminal 22 can build such a valid transaction because it is in possession of the key K p n.”) p.14.)
Regarding Claim 7, Seigneur, Maeng, and Zhu disclose:
The method as claimed in claim 6 and the first terminal application establishes a network connection with the first operating institution back-end system
Seigneur further discloses
wherein in cases where the first terminal application establishes a network connection with the first operating institution back-end system, an operation of sending the digital currency transaction information to the first operating institution back-end system for verification is preferentially executed.
(See at least p.10, “Before registering a transaction in a block … The computer server also verifies that the starting address contained in this transaction has not already been used for a previous transaction already registered in the blockchain. This last check makes it impossible or almost impossible to double-spend.” “the set of servers is fit, in response to the receipt of any transaction: … • to verify the absence of double-spending by checking that there is not a transaction of the same object from the same starting address already registered in the blockchain, and • only if these verifications confirm the validity of the transaction received and the absence of double-spending, to record the transaction received in the blockchain.” p. 6.)
Alternatively, Maeng discloses that when a transaction client (mobile wallet) is online, it sends transaction information to backend systems (wallet management system) system for verification and when offline, it relies on locally stored offline authorization data as explained above.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, Seigneur’s local offline verification mechanism (Lu) with Maeng’s online backend verification path so that when Seigneur’s terminal is offline, it uses list Lu a double spending check and when Seigneur’s terminal is online, it send transaction information to the backend servers for verification similar to Maeng’s wallet sending data to the wallet management server. It would be a routine design choice to make backend verification the preferred path whenever the terminal has connectivity because the backend has corporate/global view of risk and spending for fraud avoidance for double spending situations.
Regarding Claim 8, Seigneur, Maeng, and Zhu disclose:
The method as claimed in claim 6 and wherein in cases where it is determined that the digital currency transaction is anomalous
Seigneur further discloses
wherein in cases where it is determined that the digital currency transaction is anomalous, the first terminal application sends a blocking request to the first operating institution back-end system, so that the first operating institution back-end system sends the blocking request to a second operating institution back-end system, and block the second terminal application and/or a digital currency string of a current transaction by means of the second operating institution back-end system, wherein the second operating institution back-end system is an operating institution back-end of the second terminal application; or,
in cases where the digital currency transaction information is sent to the first operating institution back-end system for verification and it is determined that the digital currency transaction is anomalous, the first terminal application updates the local double-spending information list according to the digital currency transaction information.
((“The broadest reasonable interpretation (BRI) of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met.” MPEP § 2111.04(II). Here, the method claim recites, “or” which requires only one of the limitations. The italicized limitations are therefore, not explicitly rejected.
Seigneur discloses a first terminal application that maintains a local double-spending list (Lrev) and updates it to prevent double spending. See at least p.12, “In a step 106, the cryptoprocessor 28 connects to the server 60 and updates the list Rep Rep from the information downloaded from this server 60. In this step, the cryptoprocessor 28 also connects to the server 62 and updates the list LRev from the information downloaded from the server 62.” “The list L Rev includes a list of revoked cryptographic certificates. These revoked cryptographic certificates are no longer usable.” p.11.)
Regarding Claim 10, Seigneur, Maeng, and Zhu disclose:
The method as claimed in claim 1 and the double-spending information
Seigneur further discloses
wherein the double-spending information comprises one or more pieces of user wallet information, digital currency information, and digital currency version information, the digital currency information comprising a digital currency expression and/or a serial number.
(Each transaction includes an “object identifier.” p.8 (“an object identifier transferred, that is to say here typically a transferred cryptocurrency amount expressed in Bitcoin or Satochis”). To prevent double spending, the terminal maintains a list (Lu) which “contains transaction data already used to generate and perform an off-line transaction … to prevent double-spending for off-line transactions” (p.12). “when a new transaction is constructed by the cryptoprocessor, comparing the identifier of the object transferred by this new transaction to the second identifier of the transferred object stored in the secure memory, and - Only in the case where the identifier of the object transferred by this new transaction corresponds to the second identifier of the transferred object stored in the secure memory, to prohibit the transmission of this new transaction to the collection terminal.” p.20. “the cryptoprocessor 28 records in the list L u an identifier of the transferred object, that is to say here transferred X Bitcoins. In this embodiment, the key K p n, the key K pU bi or the address @ i unambiguously identify these transferred X Bitcoins. Thus, here, the cryptoprocessor 28 records these keys K p n, K pubi and the address @i in the list L u contained in the memory 36.” p.14.))
Regarding Claim 28, Seigneur discloses
An electronic device, comprising: one or more processors; a memory for storing one or more programs,when the one or more programs are executed by the one or more processors, the one or more processors implementing following actions:
(See at least p. 2, “terminal,” processor,” “memory”. p. 7 (“the information recording
medium includes instructions for implementing the claimed method, when these instructions are executed by the cryptoprocessor.”).
The remaining limitations of Claim 28 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Seigneur, Maeng, and Zhu for the same rationale presented in Claim 1 supra.
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 28.
Regarding Claim 29, Seigneur discloses
A computer-readable medium, on which a computer program is stored, wherein when the computer program is executed by a processor, following actions are implemented:
(See at least p. 7, “the information recording medium includes instructions for implementing the claimed method, when these instructions are executed by the cryptoprocessor.”).
The remaining limitations of Claim 29 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Seigneur, Maeng, and Zhu for the same rationale presented in Claim 1 supra.
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 29.
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
