DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on Dec. 18, 2025, and is made Non-Final. This action is being examined by James H. Miller, who is in the eastern time zone (EST), and who can be reached by email at James.Miller1@uspto.gov or by telephone at (469) 295-9082.
Interviews
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 .
Information Disclosure Statement
The information disclosure statements (IDSs) (x2) submitted on Nov. 12, 2025, and Apr. 2, 2026, were filed before the mailing of a first office action on the merits and therefore, is in compliance with the provisions of 37 CFR 1.97(b)(3). Accordingly, the IDSs have been considered.
Restriction/Election of Species
Applicant’s election with traverse of Group I (Claims 1–8, 10, 28, and 29), filed December 18, 2025, is acknowledged. The traversal is procedurally on the ground that the Examiner failed to identify the unique special technical feature (USTF) in each group and failed to explain why the groups lack unity with one another. Applicant’s argument has been fully considered but is not persuasive for the reason below. The restriction requirement is deemed proper and is therefore made FINAL.
Claims 11–16, 18, 19, and 21–23 are withdrawn from further consideration pursuant to 37 CFR 1.142(b), as being drawn to a nonelected Invention, there being no allowable generic or linking claim. Applicant timely traversed the restriction (election) requirement in the reply filed on Dec. 18, 2025.
Applicant argues that all four groups share a single general inventive concept based on double-spending verification of digital currency transaction information. This argument is not persuasive. Under 37 C.F.R. 1.475(a) and PCT Rule 13.2, a “special technical feature” must be one that defines a contribution which each claimed invention, considered as a whole, makes over the prior art — not merely a shared functional goal or problem statement. Applicant’s proposed USTF of “double-spending verification” identifies only the general problem addressed by all groups, not a specific technical feature that each group contributes over the prior art. While all groups generally relate to anomalous digital currency transaction verification, the USTFs must be the same across groups, which is not the case here. A shared technical objective is insufficient to establish unity of invention. MPEP § 1850.
Group I (Claims 1–8, 10, 28, 29): The USTF is “executing, the first terminal application, a corresponding anomaly determination operation according to a network connection state of a first operating institution back-end system” including “an operation of searching a local double-spending information list for double-spending information corresponding to the digital currency transaction information” (Claim 1). This contributes over the prior art by enabling fraud detection at the terminal without reliance on back-end connectivity — specifically, “in cases where the first terminal application does not establish 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” (Claim 2), where “the local double-spending information list is stored in a local security chip of the first terminal application” (Claim 5). Prior art systems could not perform double-spending verification in offline scenarios (Spec. ¶ 3).
Group II (Claims 11–16): The USTF is “using, by the first operating institution back-end system, a double-spending information list to perform double-spending verification on the digital currency transaction information, and if the double-spending verification has failed, 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” (Claim 11). This contributes over the prior art by enabling fraud detection at the institutional back-end with reliance on connectivity, where “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” (Claim 13), and further by “sending, by the first operating institution back-end system, the digital currency transaction information to a first verification platform” where “the first verification platform is an operating institution back-end system other than the first operating institution back-end system or a double-spending information sharing platform shared by various operating institutions” (Claim 14).
Group III (Claims 18, 19, 21): The USTF feature is that “in cases where a second operating institution back-end system establishes a network connection with a second terminal application, before the second terminal application sends digital currency transaction information of a current transaction to a first terminal application, initiating, by the second operating institution back-end system, a double-spending verification of the digital currency transaction information of the current transaction” and “when the double-spending verification has failed, determining, by the second operating institution back-end system, that the current transaction is anomalous, and terminating, by the second operating institution back-end system, the current transaction” (Claim 18). This contributes over the prior art by intercepting anomalous transactions at the sender’s side prior to transmission—a difference not shared by Groups I, II, or IV, where verification occurs either at the receiving terminal or after transmission.
Group IV (Claims 22–23): The USTF is “performing, by the second operating institution back-end system, double-spending verification on digital currency transaction information which has been sent from the second terminal application in an offline state, wherein the sent digital currency transaction information is sent from the second terminal application to other terminal applications” and “blocking, by the second operating institution back-end system, the second terminal application when the double-spending verification has failed, wherein an offline state of the second terminal application is a state in which the second terminal application does not establish a network connection with the second operating institution back-end system” (Claim 22). This contributes over the prior art by addressing the distinct fraud risk arising when “the second terminal application” conducts transactions “in an offline state” and the back-end system performs verification upon reconnection—a difference not addressed by Groups I, II, or III.
Groups I–IV do not share the same USTF. Group I’s USTF enables fraud detection at the terminal without connectivity. Group II’s USTF enables fraud detection at the receiving institution’s back-end and relies on connectivity. Group III’s USTF enables fraud detection by intercepting anomalous transactions at the sender’s side prior to transmission. Group IV’s USTF enables fraud detection of off-line transactions when connectivity is restored. Each Group addresses a distinct point in the transaction architecture. These are structurally and functionally distinct technical contributions, and no single USTF is shared across all groups. The groups are therefore not linked to form a single general inventive concept under 37 C.F.R. 1.475(a) and PCT Rule 13.1.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Claim Status
After entry of the preliminary amendment and election of Group I, 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 11–16, 18, 19, and 21–23 are withdrawn from consideration as being drawn to a nonelected Invention.
No Claims are presently cancelled or added.
This is a first action on the merits.
Claim Objections
Claims 1, 28, and 29 are objected to because of the following informalities. Appropriate correction is required.
Claims 1, 28, and 29: It is believed that “the digital currency transaction is anomalous” is “the digital currency transaction information is anomalous,” for proper antecedent basis.
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.
Claim 29 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 29: Independent Claim 29 recites, “A computer-readable medium, on which a computer program is stored …” Applicant’s Specification discloses the computer readable medium is broad enough to include transitory signals. Spec. ¶ 155 (“computer- readable signal medium”). Signals are not one of the four permissible statutory categories for letters patent. Accordingly, Claim 29 is rejected for being directed to non-statutory subject matter. In re Nuijten, 500 F.3d 1346, 1357 (Fed.Cir.2007) ("A transitory, propagating signal … is not a process, machine, manufacture, or composition of matter."). Based on this court precedent, the recited medium must specifically be claimed as “non-transitory”. There are not dependent claims for Claim 29.
Claims 1–3, 5–8, 10, 28, and 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
Note: Under the doctrine of compact prosecution, Claim 29 is presumed to be directed to statutory subject matter in the following § 101 (abstract idea) analysis.
Step 1: Claims 1–3, 5–8, 10, 28, and 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 “computer-readable medium” 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. Portions of the claim use italics to identify intended use limitations1 and underline, as needed, in further describing the abstract idea exception:
[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 sent from a second terminal application; and
[C] executing, the first terminal application, a corresponding anomaly determination operation according to a network connection state [binary condition = “0” or “1” therefore, “data”] of a first operating institution back-end system, to determine that the digital currency transaction is anomalous,
[D] wherein the first operating institution back-end system is an operating institution back-end of the first terminal application, and
[E] the anomaly determination operation is one of the following two operations:
[F] an operation of searching a local double-spending information list for double-spending information corresponding to the digital currency transaction information and
[G] an operation of sending the digital currency transaction information to the first operating institution back-end system for verification.
Claims are directed to an abstract idea exception.
Step 2A, Prong One: Rep. Claim 28 recites “receiving … digital currency transaction information” (Limitation B); “executing … a corresponding anomaly determination operation according to a network connection state [binary condition = “0” or “1” therefore, “data”] … to determine that the digital currency transaction is anomalous” (Limitation C); “wherein … the anomaly determination operation is [Limitation D] … searching a local double-spending information list for double-spending information corresponding to the digital currency transaction information [Limitation F] [or] sending the digital currency transaction information … for verification” (Limitation G), which recites a fundamental economic principle/practice under the organizing human activity exception because said Limitations describe concepts relating to the economy and commerce, such as determining s digital currency transaction is anonymous and “mitigating risks” thereof. MPEP § 2106.04(a)(2)(II)(A). 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(I) (citing Intellectual Ventures I LLC v. Capital One Bank (USA), N.A., 792 F.3d 1363, 1366, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015))
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; a first operating institution back-end system; and an operating institution back-end.
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; a first operating institution back-end system; and an operating institution back-end, 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”). 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 a 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–G 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).
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.
Rep. Claim 28 is not substantially different than Independent Claims 1 and 29 and includes all the limitations of Rep. Claim 28. Independent Claims 1 and 29 contain no additional elements. 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, as explained above, the claims are directed to an abstract idea. Second, each additional element represents currently available generic computer technology, used in a conventional manner (individually generic). Third, 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).
Accordingly, the additional elements of Rep. Claim 28 are elements that have been recognized, based on Applicant’s own disclosure2, 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., electronic device, comprising: one or more processors; a memory for storing one or more programs; a first terminal application; a second terminal application; a first operating institution back-end system; and an operating institution back-end) 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, displaying, 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)
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. 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 Claims 2 and 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. 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”].
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 sent from a second terminal application [terminal 20]; and
(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.)
executing, the first terminal application, a corresponding anomaly determination operation according to a network connection state […], to determine that the digital currency transaction is anomalous,
(Anomaly determination is performed differently based on whether the two terminals involved in the transaction are “online” or “offline” to a set of servers, which is the claimed “network connect state.” See at least, p. 17, “during step 116, the user has the choice between three options: - perform an "anonymous" off-line transaction as previously described, perform a "non-anonymous" off-line transaction as previously described, and - perform an online transaction in a conventional way.” Online: See at least p. 6, “Therefore, for the collection terminal to be sure that the transaction to one of its arrival addresses is valid, it must wait for it to be validated by the set of servers, then check that it has been registered in the blockchain. In order for the transaction to be recorded in the blockchain and then verified by the collection terminal, the payment terminal and the collection terminal must each have a connection to this set of servers. Thus, in the Bitcoin system initially developed, the security of a transaction between two terminals could only be guaranteed if these terminals each had a connection to the set of servers. This type of transaction, which requires having a connection to the set of servers to be secure against fraud such as double-spending, is later called "online transaction" or "on-chain transaction" in English.” See also, p. 3. Offline: “By cons, the originally developed Bitcoin system did not guarantee the security of a transaction between two terminals without connection to the set of computer servers. This second type of transaction is subsequently called "off-line transaction" or "off-chain transaction" in English.” p. 7)
[…]
the anomaly determination operation is one of the following two operations: an operation of searching a local double-spending information list for double-spending information corresponding to the digital currency transaction information and
(See at least p. 12, “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.” “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.” p. 13.)
an operation of sending the digital currency transaction information to the first operating institution back-end system for verification.
(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.)
Seigneur discloses executing, the first terminal application, a corresponding anomaly determination operation according to a network connection state to determine that the digital currency transaction is anomalous. Specifically, the corresponding anomaly determination operation is performed by a user selecting either an “offline” or “online" transaction at Step 116. (Seigneur, p. 17). Seigneur does not disclose executing a corresponding anomaly determination operation according to a network connection state of a first operating institution back-end system, to determine that the digital currency transaction is anomalous. Therefore, Seigneur does not disclose but Maeng discloses:
executing the first terminal application [mobile wallet] a corresponding anomaly determination operation [accept/reject transaction] according to a network connection state of a first operating institution back-end system [wallet management system] to determine that the digital currency transaction is anomalous,
(See at least col. 12:4–22, “At action 604, the wallet management system may determine if the mobile wallet is online. The wallet management system may use any suitable manner to determine if the mobile wallet is online. For example, the mobile wallet may be configured to provide the wallet management system with a periodic heartbeat message. When the wallet management system receives the periodic heartbeat message, it may generate a timestamp. To determine whether the mobile wallet is online, the wallet management system may check the time stamp of the most recently received heartbeat message. If more than a threshold time period has passed since the most recent heartbeat message was received, the wallet management system may determine that the mobile wallet is not online. In some examples, the wallet management may attempt to query the mobile wallet. If a response is received, the mobile wallet may be online. If no response is received before a timeout threshold has passed, the mobile wallet may not be online.” See also Claim 1; Fig. 6. The online/offline state is used to accept or reject transactions in the wallet management system. Col. 12:23–34. The determinations (online/offline, token match, etc.) are the “anomaly determination operation” that results in accepting or rejecting the transaction and this accepting and rejecting is performed “according to” the online/offline network connection status.)
wherein the first operating institution back-end system [wallet management system] is an operating institution back-end of the first terminal application [mobile wallet], and
(See at least Col. 5:49–54, “In some examples, the mobile wallet 110 may first determine whether it is on1ine 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.”
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 executing a corresponding anomaly determination operation according to a network connection state of a first operating institution back-end system to determine that the digital currency transaction is anomalous and wherein the first operating institution back-end system [wallet management system] is an operating institution back-end of the first terminal application [mobile wallet], 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.)
Regarding Claim 2, Seigneur and Maeng 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 discloses
comprises 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.)
Regarding Claim 3, Seigneur and Maeng disclose:
The method as claimed in claim 2 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 and Maeng 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 and Maeng 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
comprises: in cases where the first terminal application establishes a network connection with the first operating institution back-end system, [1] searching, by the first terminal application, a local double-spending information list for double-spending information corresponding to the digital currency transaction information, or [2] sending, by the first terminal application, the digital currency transaction information to the first operating institution back-end system for verification; and if the double-spending information corresponding to the digital currency transaction information is found in the local double-spending information list, or a verification result returned by the first operating institution back-end system is that the verification has failed, determining, by the first terminal application, that the digital currency transaction is anomalous [interruption of transaction].
((“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 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 and Maeng 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 and Maeng 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 and Maeng 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 and Maeng 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 and Maeng 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
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 See Changes in Examination Procedure Pertaining to Subject Matter Eligibility, Recent Subject Matter Eligibility Decision (Berkheimer v. HP, Inc.), 3-4, https://www.uspto.gov/sites/default/files/documents/memo-berkheimer-20180419.PDF (April, 18, 2018) (That additional elements are well-understood, routine, or conventional may be supported by various forms of evidence, including "[a] citation to an express statement in the specification or to a statement made by an applicant during prosecution that demonstrates the well-understood, routine, conventional nature of the additional element(s).").
Prosecution Insights