DETAILED ACTION
Status of Application
This action is a Non-Final Rejection. This action is in response to the reply to the restriction requirement filed on October 21, 2025. Applicant’s election with traverse of claims 25-38 in the reply filed on October 21, 2025 is acknowledged. Claims 39-48 have been withdrawn from consideration.
Claims 1-24 have been canceled.
Claims 25-38 are rejected.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . 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 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.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on February 1. 2024 has been considered by the examiner.
Claim Interpretation
Applicant should be aware that there is claim language that does not serve to differentiate the claims from the prior art and/or provide an additional element that can be a consideration for eligibility1. See MPEP 2103(c).
Nonfunctional Descriptive Material
Nonfunctional descriptive material is generally not given patentable weight. See MPEP 2111.05. Any difference related merely to the meaning and information conveyed through labels (i.e., the type of the item) which does not explicitly alter or impact the steps of the method is nonfunctional descriptive material and does not patentably distinguish the claimed invention from the prior art in terms of patentability.
The following limitations include nonfunctional descriptive material:
Claim 38: “wherein the secure execution unit for managing the coin data sets transmits transaction register data to a transaction register, wherein the transaction register data comprise in particular a unique transaction identifier, a transaction amount, a coin managing unit identifier of the sender, a coin managing unit identifier of the recipient, and the register reference of the coin data set in the coin register, and/or transmits registration requests to the coin register, which comprises at least one register reference of a coin data set previously registered in the coin register and a register reference of a coin data set to be registered in the coin register.” (The content of the data is nonfunctional descriptive material.)
Other
The claims use the language of “and/or.” The broadest reasonable interpretation of “and/or” includes “or.” When a claim includes alternative options by using “and/or,” only one option is required according to the broadest reasonable interpretation.
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 25-38 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
The rejection below under 35 U.S.C. 112(b) explains that the claims are unclear and not sufficiently described in the Specification to allow one of ordinary skill in the art to understand the claimed invention. Although the Specification refers to language found in the claims, it does not describe that language, which appears to be a translation of a foreign document. For example, the claims recite several different specifications, as described in the 112(b) rejection. One of the specifications is a “counter-performance specification.” The following paragraphs refer to this specification:
[0041] The first and/or the second functional specification can alternatively be a counter- performance specification. The counter-performance is preferably provided in response to at least one received coin data set, and in particular in the response data to the sender of the received coin data set.
[0053] The functional specification can be a direction specification. The execution of the transaction comprises sending and/or receiving a coin data set. Alternatively or additionally, the functional specification can be a specification for conditional transactions. The conditional transaction is carried out only later, when a condition is met. The functional specification can further, alternatively or additionally, be a specification for counter-performances. The execution of the transaction includes providing the counter-performance, wherein in particular the transaction request includes a coin data set. The transaction can be a simple transaction (transmission or reception of coin data set), with or without provision of a counter-performance, or a conditioned transaction, with or without provision of a counter-performance.
[0107] The functional specifications 332 can be not only direction specifications, but also, for example, specifications for conditional transactions 416 or specifications for transactions with counter-performance 419. In Fig. 3, it is already indicated that these specifications 416, 419 can also additionally exist.
[0108] A storage region 436, 26 for the temporary storage of conditional transactions can be provided in the coin deposit 330 or across coin deposits. Conditional transactions are first temporarily stored, and later executed after the condition has been met. A corresponding method is described in more detail with reference to Fig. 7.
[0109] In order to be able to execute a transaction with counter-performance, the coin deposit managing unit 30 comprises a counter-performance unit 39. The counter-performance unit 39 generates, for example, response data, which are to be transmitted in a response as a counter- performance for one (or more) coin data sets received in a receipt transaction 406. The counter- performance unit provides a counter-performance that can be set in counter-performance data 439 of the coin deposit 330. The counter-performance specifications restrict the counter-performance functions permissible for the coin deposit 330. Starting from the counter-performance functions available in the counter-performance unit 39, specific counter-performance functions, encodings, or subtypes are thus selectively excluded for the coin deposit.
[0125] In an additional step 606, a certificate is created for the coin deposit. The certificate comprises at least the ID and/or the public key of the coin deposit. Certificates confirm the authenticity of the contained data elements for third parties. The certificate, like the ID or the public key, is a (public) data element of the coin deposit data set provided for forwarding to third parties, such as other coin managing units. The functional specifications for counter-performance are therefore not contained in the certificate. The exact restriction in the transmission and receipt directions, i.e., here, the two permissible recipient groups, are also treated as internal information. However, an (additional) part of the functional specifications is contained in the certificate. The certificate contains, for example, the indication that the coin deposit is unrestricted in the receipt direction ("no sender specification") and is partially restricted in the transmission direction.
[0153] Finally, for functional specifications, a distinction is made between direction specifications 821, 811, 816, 826, specifications for conditional transactions 822, 812, 817, 827, and specifications for transactions with counter-performance 814, 819. The coin deposit also comprises amount specifications 813, 838, 828.
As shown above, although these paragraphs refer to counter-performance specifications, they do not provide guidance as to what is meant by the counter-performance specification. This is an example of a lack of written description that is found throughout the claims, including the limitations discussed in the rejection under 35 U.S.C. 112(b) rejection. Applicant should show where the claim limitations are described in the Specification, show that one having ordinary skill in the art would understand the claim limitations, or amend the claims.
Claim Rejections - 35 USC § 112(b)
The following is a quotation 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 25-38 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim limitations “coin deposit managing unit,” “secure execution unit,” and “coin managing units” have been evaluated under the three-prong test set forth in MPEP § 2181, subsection I, but the result is inconclusive. For example, paragraph 0077 of the Specification states that “[t]he execution unit 211 is generally designed as software and is configured to manage the coin data sets of the coin deposit (transmit/receive coin data sets, transmit registration requests.).” It is unclear whether “generally designed as software” is intended to mean that it is software. Additionally, the coin deposit managing unit and the coin managing units are not defined so it is unclear whether they are hardware or software. Thus, it is unclear whether these limitations should be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The boundaries of these claim limitations are ambiguous; therefore, the claims are indefinite and are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
In response to this rejection, applicant must clarify whether these limitations should be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Mere assertion regarding applicant’s intent to invoke or not invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph is insufficient. Applicant may:
(a) Amend the claim to clearly invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, by reciting “means” or a generic placeholder for means, or by reciting “step.” The “means,” generic placeholder, or “step” must be modified by functional language, and must not be modified by sufficient structure, material, or acts for performing the claimed function;
(b) Present a sufficient showing that 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, should apply because the claim limitation recites a function to be performed and does not recite sufficient structure, material, or acts to perform that function;
(c) Amend the claim to clearly avoid invoking 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, by deleting the function or by reciting sufficient structure, material or acts to perform the recited function; or
(d) Present a sufficient showing that 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, does not apply because the limitation does not recite a function or does recite a function along with sufficient structure, material or acts to perform that function.
For purposes of examination, because the execution unit is described as software, the coin deposit managing unit, the secure execution unit, and the coin managing units are interpreted as software and as not invoking 35 U.S.C. 112(f).
Additionally, claims are indefinite because they appear to be a literal translation into English from a foreign document and claim terms and limitations are unclear and not defined in the Specification. For example, the claims recite “a first functional specification,” “a second, different functional specification,” “a transmit specification,” “receive specification,” “at least one partially freely-readable specification,” “counter-performance specification,” “a specification,” “an amount specification, i.e., a non- functional specification,” “a defined functional minimum specification,” and “a selectable functional specification.” It is not clear what is meant by “specification” or any of these specific specifications. The Specification refers to these terms but does not describe them. For purposes of examination, each of these specifications are interpreted as instructions, rules, or data.
Other limitations are similarly indefinite. For example, claim 25 recites “the first coin deposit comprises a first functional specification which checks the secure execution unit in the managing of coin data sets, and the second coin deposit comprises a second, different functional specification which checks the secure execution unit in the managing of coin data set.” It is unclear what is meant by “checks” and whether two different specifications are doing the same thing.
Claim 26 recites “wherein functional specifications relate to….” It is unclear whether this is referring to either the first or second functional specifications of claim 25 or a different functional specification.
Claim 37 recites “wherein the first and/or the second functional specification is a counter-performance specification, wherein the counter-performance is provided as performance in response to at least one received coin data set, and in particular in the response data to the sender of the received coin data set.” It is unclear what is meant by this limitation. For example, it is not clear what is meant by a counter-performance being provided as performance and how it is done in response to at least one received coin data set. It is also unclear what is meant by “in particular in the response data to the sender of the received coin data set” and how it relates to the preceding part of the limitation.
These are examples of indefiniteness that is found throughout the claims. For purposes of examination, the claims were interpreted as best understood and as shown in the rejection under 35 U.S.C. 103.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 25-38 are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Does the Claim Fall within a Statutory Category? (see MPEP 2106.03)
No, with respect to claims 25-38, which recite a coin deposit managing unit that comprises a secure execution unit and a first coin deposit. As explained in the rejection under 35 U.S.C. 112(b), the broadest reasonable interpretation of the secure execution unit includes software. The other limitation of claim 25 recites “a first coin deposit,” which appears to be data. Therefore, claims 25-38 are directed to software per se. Because software is not a statutory category, these claims are ineligible. To overcome this rejection, the claims should positively recite hardware. Although these claims are ineligible at step 1, they are being analyzed below with respect to the other steps.
Step 2A, Prong One: Is a Judicial Exception Recited? (see MPEP 2106.04(a))
The following claims identify the limitations that recite the abstract idea in regular text and that recite additional elements in bold:
25. A coin deposit managing unit, comprising:
a secure execution unit for managing digital coin data sets of a central bank,
wherein the secure execution unit is adapted to exchange digital coin data sets with coin managing units and to send registration requests to a coin register of the central bank, and
a first coin deposit that comprises at least a first digital coin data set, and a second coin deposit that comprises at least a second digital coin data set;
wherein the coin deposit managing unit manages coin deposits of different users; and
the first coin deposit comprises a first functional specification which checks the secure execution unit in the managing of coin data sets, and the second coin deposit comprises a second, different functional specification which checks the secure execution unit in the managing of coin data sets.
26. The coin deposit managing unit according to claim 25, wherein functional specifications relate to a function executable by the secure execution unit, in particular, completely or partially restricting, or not restricting, the executable function for the coin deposit.
27. The coin deposit managing unit according to claim 25, wherein the first and/or the second functional specification is a transmit or receive specification which restricts the sending of coin data sets or the receiving of coin data sets for the coin deposit.
28. The coin deposit managing unit according to claim 25, wherein
a transmit specification of the first and/or the second coin deposit is different from its receive specification; and/or
at least one partially restricting transmit specification restricts the sending of coin data sets to exactly one recipient, exactly one recipient group, or to several recipients and/or recipient groups; and/or
at least one partially restricting receive specification restricts the receiving of coin data sets to exactly one sender, exactly one sender group, or several senders and/or sender groups; and/or
the first functional specification as a send or receive specification of the first coin deposit comprises the second coin deposit,
wherein in particular the second coin deposit is a recipient or sender, and the only authorized recipient or sender, for coin data sets of the first coin deposit.
29. The coin deposit management unit according to claim 25, wherein the first and/or the second functional specification is a specification for conditional transactions.
30. The coin deposit managing unit according to claim 29, wherein
a conditional transaction for a coin deposit is buffer stored, in particular in a buffer store of the coin deposit or in a buffer store, extending over more than one coin deposit, of the coin deposit managing unit; and/or
the secure execution unit executes the conditional transaction only when a condition is met that is contained in the conditional transaction, and/or a conditional transaction comprises a temporal condition;
and/or a conditional transaction comprises an external triggering event and/or a securing value; and/or
a specification for conditional transactions contains a type of condition and/or a type of the conditional transaction which is permissible for the coin deposit.
31. The coin deposit managing unit according to claim 25, wherein
the first and the second coin deposit each comprise several functional specifications, and/or
the first and second functional specification relate to the same function executable by the secure execution unit.
32. The coin deposit managing unit according to claim 25, wherein the first and/or the second coin deposit further comprises an amount specification, i.e., a non- functional specification:
a maximum value for the amount of the coin data sets to be sent and/or for the amount of the coin data sets to be received, or
a maximum value or a minimum value for the total amount of the stored coin data sets.
33. The coin deposit managing unit according to claim 25, wherein the first and second functional specification comprise:
a defined functional minimum specification, which is initially defined in particular by an issuer of the coin deposit, and/or
a selectable functional specification, which is to be selected in particular by the user so that it is narrower than a defined functional specification.
34. The coin deposit management unit according to claim 25, wherein, the first and the second coin deposit are assigned to a first user; or
wherein the first coin deposit is assigned to a first user, and the second coin deposit is assigned to a second user.
35. The coin deposit managing unit according to claim 25, wherein the first and/or the second coin deposit further comprises one or more of the following data elements:
a unique coin managing unit identifier, which in particular identifies the coin deposit and the secure execution unit,
a public coin managing unit key of an asymmetrical key pair; optionally, a secret coin managing unit key of the asymmetrical key pair; and/or
a coin managing unit certificate, which in particular comprises the coin deposit identifier and/or the public coin deposit key as certified contents.
36. The coin managing unit according to claim 25, wherein the first and/or the second coin deposit comprises at least one partially freely-readable specification, and in particular the first or second functional specification;
wherein in particular a readable portion and a non-readable portion of the at least partially freely-readable specification are present; and
wherein the two portions are stored in different data elements, or
stored in a common data element in a non-readable manner, and additionally the readable portion is stored in a separate readable data element.
37. The coin managing unit according to claim 25, wherein the first and/or the second functional specification is a counter-performance specification,
wherein the counter-performance is provided as performance in response to at least one received coin data set, and in particular in the response data to the sender of the received coin data set.
38. The coin managing unit according to claim 25, wherein the secure execution unit for managing the coin data sets
transmits transaction register data to a transaction register,
wherein the transaction register data comprise in particular a unique transaction identifier, a transaction amount, a coin managing unit identifier of the sender, a coin managing unit identifier of the recipient, and the register reference of the coin data set in the coin register, and/or
transmits registration requests to the coin register, which comprises at least one register reference of a coin data set previously registered in the coin register and a register reference of a coin data set to be registered in the coin register.
Yes. But for the recited additional elements as shown above in bold, the remaining limitations of the claims recite certain methods of organizing human activity. The claims are directed to managing digital coins. This type of method of organizing human activity is a commercial interaction such as sales activities or behaviors and business relations. Thus, the claims recite an abstract idea.
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application? (see MPEP 2106.04(d))
No. The claims as a whole merely use a computer as a tool to perform the abstract idea. The claimed units or software components (i.e., additional elements that are in bold above) are recited at a high level of generality and are merely invoked as a tool to implement the steps. For example, only software implemented on a programmed general purpose computing device is needed to perform the claimed process. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Additionally, there is no improvement to the functioning of a computer or technology. Therefore, the abstract idea is not integrated into a practical application.
Step 2B: Does the Claim Provide an Inventive Concept? (see MPEP 2106.05)
No. As discussed with respect to Step 2A, Prong 2, the additional elements in the claims, both individually and in combination, amount to no more than tools to perform the abstract idea. Merely performing the abstract idea using a computer cannot provide an inventive concept. Therefore, the claims do not provide an inventive concept.
As such, the claims are not patent eligible.
Claim Rejections - 35 USC § 103
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 25-38 are rejected under 35 U.S.C. 103 as being unpatentable over Myshkin et al., U.S. Patent Application Publication No. 2018/0341931 A1 and Quibria, Nasreen. “Digital Dollar Digest: What Central Bank Digital Currency Architecture Means for Community Banks,” https://www.icba.org/w/digital-dollar-digest-what-central-bank-digital-currency-architecture-means-for-community-banks (June 3, 2021).
Claim 25:
Myshkin teaches:
a secure execution unit for managing digital coin data sets…, (see at least Myshkin, Figure 2 and associated text; paragraph 0020 (“…receive/release block 214 can store the cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents in a hot memory module (or a hot wallet), such as hot memory module 224a (or hot wallet 224a).”)).
wherein the secure execution unit is adapted to exchange digital coin data sets with coin managing units and to send registration requests to a coin register of the central bank, and (see at least Myshkin, paragraph 0019 (“Receive/release block 214 enables secure computer 210 to respond to requests for receipt and/or release of cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents of interest to an authorized user. Receive/release block 214 can receive these requests from another networked computer, such as platform server 130 in FIG. 1. Receive/release block 214 includes a non-IP network interface controller that enables it to receive and respond to requests over a non-IP communication link, such as secure connection 132 in FIG. 1.”); paragraph 0020 (“In response to a request for release of cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents from a withdrawing authorized user, receive/release block 214 can remove the cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents from a hot memory module (or a hot wallet), such as hot memory module 224a (or hot wallet 224a), and send the electronic documents in a response message.”)).
a first coin deposit that comprises at least a first digital coin data set, and a second coin deposit that comprises at least a second digital coin data set; wherein the coin deposit managing unit manages coin deposits of different users; and (see at least Myshkin, Figure 2 and associated text; paragraph 0015 (Authorized users use the secure electronic system.); paragraph 0020 (“…receive/release block 214 can store the cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents in a hot memory module (or a hot wallet), such as hot memory module 224a (or hot wallet 224a).”)).
the first coin deposit comprises a first functional specification which checks the secure execution unit in the managing of coin data sets, and the second coin deposit comprises a second, different functional specification which checks the secure execution unit in the managing of coin data set (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.)).
Myshkin does not explicitly teach, but Quibria, however, does teach:
…of a central bank (see at least Quibria (This reference discusses central bank digital currencies (CBDC).)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Quibria’s central bank with Myshkin’s secure electronic system for managing digital currencies. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of managing a digital currency such as CBDC that is issued by a central bank. Digital currency transactions are convenient and quick and it would be obvious to use one that is the liability of a central bank in order to reduce risk associated with a transaction.
Claim 26:
Myshkin further teaches:
wherein functional specifications relate to a function executable by the secure execution unit, in particular, completely or partially restricting, or not restricting, the executable function for the coin deposit (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.)).
Claim 27:
Myshkin further teaches:
wherein the first and/or the second functional specification is a transmit or receive specification which restricts the sending of coin data sets or the receiving of coin data sets for the coin deposit (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.)).
Claim 28:
Myshkin further teaches:
wherein a transmit specification of the first and/or the second coin deposit is different from its receive specification; and/or at least one partially restricting transmit specification restricts the sending of coin data sets to exactly one recipient, exactly one recipient group, or to several recipients and/or recipient groups; and/or at least one partially restricting receive specification restricts the receiving of coin data sets to exactly one sender, exactly one sender group, or several senders and/or sender groups; and/or the first functional specification as a send or receive specification of the first coin deposit comprises the second coin deposit, wherein in particular the second coin deposit is a recipient or sender, and the only authorized recipient or sender, for coin data sets of the first coin deposit (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.)).
Claim 29:
Myshkin further teaches:
wherein the first and/or the second functional specification is a specification for conditional transactions (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.)).
Claim 30:
Myshkin further teaches:
wherein a conditional transaction for a coin deposit is buffer stored, in particular in a buffer store of the coin deposit or in a buffer store, extending over more than one coin deposit, of the coin deposit managing unit; and/or the secure execution unit executes the conditional transaction only when a condition is met that is contained in the conditional transaction, and/or a conditional transaction comprises a temporal condition; and/or a conditional transaction comprises an external triggering event and/or a securing value; and/or a specification for conditional transactions contains a type of condition and/or a type of the conditional transaction which is permissible for the coin deposit (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.)).
Claim 31:
Myshkin further teaches:
wherein the first and the second coin deposit each comprise several functional specifications, and/or the first and second functional specification relate to the same function executable by the secure execution unit (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.)).
Claim 32:
Myshkin further teaches:
wherein the first and/or the second coin deposit further comprises an amount specification, i.e., a non- functional specification: a maximum value for the amount of the coin data sets to be sent and/or for the amount of the coin data sets to be received, or a maximum value or a minimum value for the total amount of the stored coin data sets (see at least Myshkin, paragraph 0028 (“Memory powering block 220 and empty/full checker 218 may communicate to power up cold memory modules 226b, 226c, and 226d (or cold wallets 226b, 226c, and 226d) when empty/full checker 218 detects an empty condition. Empty/full checker 218 can detect an empty condition when cryptocurrencies, digital currencies, tokens, smart contracts, or public or private keys stored in hot memory module 224a (or hot wallet 224a) fall below a low threshold. In one implementation, a low threshold can be a fixed quantity, such as zero. For example, if receive/release block 214 is required to release 700,000 units of cryptocurrencies, but hot memory module 224a (or hot wallet 224a) presently contains only 508,000 units, empty/full checker 218 can detect this condition and flag the anticipated empty condition, and memory powering block 220 can power up and make hot one of cold memory modules 226b, 226c, or 226d (or cold wallets 226b, 226c, or 226d) to provide additional cryptocurrencies for the anticipated deficit due to the upcoming empty condition of hot wallet 224a. In various implementation, a low threshold can be dynamic and depend on a quantity of cryptocurrencies presently requested to be released, an expected quantity of cryptocurrencies needed for satisfying upcoming requests, time, or other algorithms.”)).
Claim 33:
Myshkin further teaches:
wherein the first and second functional specification comprise: a defined functional minimum specification, which is initially defined in particular by an issuer of the coin deposit, and/or a selectable functional specification, which is to be selected in particular by the user so that it is narrower than a defined functional specification (see at least Myshkin, paragraph 0028 (“Memory powering block 220 and empty/full checker 218 may communicate to power up cold memory modules 226b, 226c, and 226d (or cold wallets 226b, 226c, and 226d) when empty/full checker 218 detects an empty condition. Empty/full checker 218 can detect an empty condition when cryptocurrencies, digital currencies, tokens, smart contracts, or public or private keys stored in hot memory module 224a (or hot wallet 224a) fall below a low threshold. In one implementation, a low threshold can be a fixed quantity, such as zero. For example, if receive/release block 214 is required to release 700,000 units of cryptocurrencies, but hot memory module 224a (or hot wallet 224a) presently contains only 508,000 units, empty/full checker 218 can detect this condition and flag the anticipated empty condition, and memory powering block 220 can power up and make hot one of cold memory modules 226b, 226c, or 226d (or cold wallets 226b, 226c, or 226d) to provide additional cryptocurrencies for the anticipated deficit due to the upcoming empty condition of hot wallet 224a. In various implementation, a low threshold can be dynamic and depend on a quantity of cryptocurrencies presently requested to be released, an expected quantity of cryptocurrencies needed for satisfying upcoming requests, time, or other algorithms.”)).
Claim 34:
Myshkin further teaches:
wherein, the first and the second coin deposit are assigned to a first user; or wherein the first coin deposit is assigned to a first user, and the second coin deposit is assigned to a second user (see at least Myshkin, Figure 2 and associated text; paragraph 0015 (Authorized users use the secure electronic system.); paragraph 0020 (“…receive/release block 214 can store the cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents in a hot memory module (or a hot wallet), such as hot memory module 224a (or hot wallet 224a).”)).
Claim 35:
Myshkin further teaches:
wherein the first and/or the second coin deposit further comprises one or more of the following data elements: a unique coin managing unit identifier, which in particular identifies the coin deposit and the secure execution unit, a public coin managing unit key of an asymmetrical key pair; optionally, a secret coin managing unit key of the asymmetrical key pair; and/or a coin managing unit certificate, which in particular comprises the coin deposit identifier and/or the public coin deposit key as certified contents (see at least Myshkin, paragraph 0014 (“FIG. 1 illustrates a diagram of a portion of an exemplary secure system 100 for creation, verification, management and storage of electronic documents such as cryptocurrencies, digital currencies, tokens, and smart contracts according to one implementation of the present application. As used in the present application, “electronic documents” may refer to any electronic representation capable of being stored. Electronic documents can be cryptocurrencies, digital currencies, tokens, or smart contracts. Electronic documents can also be public or private keys, such as public or private keys utilized in a cryptocurrency network.”))
Claim 36:
Myshkin further teaches:
wherein the first and/or the second coin deposit comprises at least one partially freely-readable specification, and in particular the first or second functional specification; wherein in particular a readable portion and a non-readable portion of the at least partially freely-readable specification are present; and wherein the two portions are stored in different data elements, or stored in a common data element in a non-readable manner, and additionally the readable portion is stored in a separate readable data element (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.)).
Claim 37:
Myshkin further teaches:
wherein the first and/or the second functional specification is a counter-performance specification, wherein the counter-performance is provided as performance in response to at least one received coin data set, and in particular in the response data to the sender of the received coin data set (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.); paragraph 0019 (“Receive/release block 214 enables secure computer 210 to respond to requests for receipt and/or release of cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents of interest to an authorized user. Receive/release block 214 can receive these requests from another networked computer, such as platform server 130 in FIG. 1. Receive/release block 214 includes a non-IP network interface controller that enables it to receive and respond to requests over a non-IP communication link, such as secure connection 132 in FIG. 1.”); paragraph 0020 (“In response to a request for release of cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents from a withdrawing authorized user, receive/release block 214 can remove the cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents from a hot memory module (or a hot wallet), such as hot memory module 224a (or hot wallet 224a), and send the electronic documents in a response message.”)).
Claim 38:
Myshkin further teaches:
wherein the secure execution unit for managing the coin data sets transmits transaction register data to a transaction register, wherein the transaction register data comprise in particular a unique transaction identifier, a transaction amount, a coin managing unit identifier of the sender, a coin managing unit identifier of the recipient, and the register reference of the coin data set in the coin register, and/or transmits registration requests to the coin register, which comprises at least one register reference of a coin data set previously registered in the coin register and a register reference of a coin data set to be registered in the coin register (see at least Myshkin, Figure 2 and associated text; paragraph 0020 (“…receive/release block 214 can store the cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents in a hot memory module (or a hot wallet), such as hot memory module 224a (or hot wallet 224a).”)).
Relevant Prior Art
The following references are relevant to Applicant’s invention:
Mallela et al., U.S. Patent Application Publication Number 2021/0224794 A1. This reference teaches a system for conducting and managing cryptocurrency transactions.
Fogg, U.S. Patent Number 10,915,895 B1. This reference teaches a system for managing and transferring electronic currencies.
Email Communications
Per MPEP 502.03, Applicant may authorize email communications by filing Form PTO/SB/439, available at https://www.uspto.gov/sites/default/files/documents/sb0439.pdf, via the USPTO patent electronic filing system.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ELIZABETH H ROSEN whose telephone number is (571) 270-1850 and email address is elizabeth.rosen@uspto.gov. The examiner can normally be reached Monday - Friday, 10 AM ET - 7 PM ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Michael Anderson, can be reached at 571-270-0508. 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.
/ELIZABETH H ROSEN/Primary Examiner, 3693
1 See MPEP 2106.04(d)(2) (“Examiners should keep in mind that in order to qualify as a "treatment" or "prophylaxis" limitation for purposes of this consideration, the claim limitation in question must affirmatively recite an action that effects a particular treatment or prophylaxis for a disease or medical condition. An example of such a limitation is a step of "administering amazonic acid to a patient" or a step of "administering a course of plasmapheresis to a patient." If the limitation does not actually provide a treatment or prophylaxis, e.g., it is merely an intended use of the claimed invention or a field of use limitation, then it cannot integrate a judicial exception under the "treatment or prophylaxis" consideration. For example, a step of "prescribing a topical steroid to a patient with eczema" is not a positive limitation because it does not require that the steroid actually be used by or on the patient, and a recitation that a claimed product is a "pharmaceutical composition" or that a "feed dispenser is operable to dispense a mineral supplement" are not affirmative limitations because they are merely indicating how the claimed invention might be used.”)