DETAILED ACTION
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 .
Election/Restrictions Acknowledgement
The applicant’s election without traverse of Group I: (Claims 1-11) is the communication received on Nov 7, 2025 is acknowledged.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on May 30, 2024 is being considered by the examiner.
Status of the Claims
This is a non-final rejection prepared in response to U.S. Patent Application 18/678,636 filed on
May 30, 2024.
Claims 1-11 are pending.
Claims 12-15 are withdrawn.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that use the word “means” or “step” but are nonetheless not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph because the claim limitation(s) recite(s) sufficient structure, materials, or acts to entirely perform the recited function. Such claim limitation(s) is/are: “means for exchanging one or more tokens with other secure transaction units in the electronic payment transaction system”, “means for transmitting registration requests to a token reference register of the electronic transaction system for registering the tokens in the electronic payment transaction system” and “control means configured to…” in claim 1 and 2.
Because this/these claim limitation(s) is/are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are not being interpreted to cover only the corresponding structure, material, or acts described in the specification as performing the claimed function, and equivalents thereof.
If applicant intends to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to remove the structure, materials, or acts that performs the claimed function; or (2) present a sufficient showing that the claim limitation(s) does/do not recite sufficient structure, materials, or acts to perform the claimed function.
Claim Rejections - 35 USC § 112
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 1-11 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.
Regarding claim 1 and 2, limitations “means for exchanging one or more tokens with other secure transaction units in the electronic payment transaction system”, “means for transmitting registration requests to a token reference register of the electronic transaction system for registering the tokens in the electronic payment transaction system” and “control means configured to…” invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Here the claims and specifications are silent with respect to any structure corresponding to the generic placeholder. Therefore the claim is rejected under 35 U.S.C. 112(a) for lacking adequate written description.
Claims 3-11 are also rejected upon rejected parent independent claim 1.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-11 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1 and 2, limitations “means for exchanging one or more tokens with other secure transaction units in the electronic payment transaction system”, “means for transmitting registration requests to a token reference register of the electronic transaction system for registering the tokens in the electronic payment transaction system” and “control means configured to…” invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification fails to disclose sufficient corresponding structure for the claimed “means” limitations. In other words, the structure for achieving the functions do not commensurate in scope of the operation. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claims 3-11 are also rejected upon rejected parent independent claim 1.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-11 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an
abstract idea without significantly more.
Step 1: Claims 1-11 are directed to a machine. Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One: Claim 1, recites (i.e., sets forth or describes) an abstract idea. More specifically, the following bolded claim elements recite abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
A secure transaction unit for managing payment transactions in an electronic payment transaction system, the secure transaction unit comprising:
means for exchanging one or more tokens with other secure transaction units in the electronic payment transaction system; and
means for transmitting registration requests to a token reference register of the electronic transaction system for registering the tokens in the electronic payment transaction system;
control means configured to: in a first mode, generate single registration requests comprising only single modification-commands concerning a modification of a token of the secure transaction unit; and
in a second mode, generate and/or process common registration requests comprising more than one modification-command, wherein a modification-command of a common registration request is related to a modification of a token of another secure transaction unit and wherein another modification-command of the common registration request is related to a modification of a token of the secure transaction unit.
Claim 1, recites (i.e., sets forth or describes) an abstract idea of securely exchanging tokens and generating/processing modification commands related to those tokens. The claim achieves this by transmitting registration request to register the token(s) containing a command or multiple commands to modify the token. As such claim 1 recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas (i.e., fundamental economic practices).
Claim 2 is significantly similar to claim 1 with the exception that claim 2 recites “in a second mode, generate and/or process common registration requests, wherein a common registration request comprising one modification-command, one or more token references related to a modification of a token of the secure transaction unit, and one or more token references related to a modification of a token from another secure transaction unit” instead of “in a second mode, generate and/or process common registration requests comprising more than one modification-command, wherein a modification-command of a common registration request is related to a modification of a token of another secure transaction unit and wherein another modification-command of the common registration request is related to a modification of a token of the secure transaction unit.” recited in claim 1.
Step 2A Prong Two: Because the claim recites abstract ideas, the analysis proceeds to
determine whether the claim recites additional elements that recite a practical application of the
abstract ideas. Here, the additional elements of a secure transaction unit and an electronic payment transaction system merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Therefore, the claim as a whole fail to recite a practical application of the abstract ideas.
Step 2B: Determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims: Claims 3-11 have also been analyzed for subject matter eligibility. However, claims 3-11 also fail to recite patent eligible subject matter for the following reasons:
Claim 3 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
each common registration request comprises token references, wherein
each token reference being uniquely assigned to one token, wherein
each token assigned to token references of common registration requests comprises at least a monetary value and a private key of a token-individual key pair as token elements, wherein each token reference comprising a monetary value of the assigned token and a public key corresponding to the private key of the token-individual key pair as token reference elements
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas.
Claim 4 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the common registration request comprises: a first switch-command on a first token having first token-type information to obtain a third token having a monetary value of the first token and the first token-type information; and/or a second switch-command on a second token having second token-type information to obtain a fourth token having the monetary value of the second token.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas.
Claim 5 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
processing the common registration requests requires a signing of the common registration request with a digital signature being generated by the secure transaction unit and/or the other secure transaction unit, preferably the generation being made commonly or independent.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a secure transaction unit and other secure transaction unit fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Further, the additional element “digital” generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
Claim 6 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the digital signature is commonly applied on the modification-command of the common registration request related to the modification of the token of the other secure transaction unit and on the other modification-command of the common registration request related to the modification of the token of the secure transaction unit .
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a secure transaction unit and other secure transaction unit fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim 7 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
a first digital signature is generated by the secure transaction unit on the modification-command of the common registration request and the one or more token references related to the modification of the token of the secure transaction unit and wherein
a second digital signature is generated by the other secure transaction unit on the modification-command of the common registration request and the one or more token references related to the modification of the token of the other secure transaction unit.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a secure transaction unit and other secure transaction unit fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Further, the additional element “digital” generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
Claim 8 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
a first digital signature is generated by the secure transaction unit on the modification-command, one input token reference related to the tokens of the secure transaction unit and all output token references related to the tokens of the secure transaction unit, and all output token references related to the tokens of the other secure transaction unit; and/or wherein
a second digital signature is generated by the other secure transaction unit on the other modification-command, one input token reference related to the tokens of the other secure transaction unit, all output token references related to the tokens of the secure transaction unit, and all output token references related to the tokens of the other secure transaction unit.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a secure transaction unit and other secure transaction unit fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Further, the additional element “digital” generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
Claim 9 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
a first digital signature is generated by the secure transaction unit only on the modification-command, an input token reference related to the token of the secure transaction unit and an output token reference related to the token of the other secure transaction unit; and/or wherein
a second digital signature is applied by the other secure transaction unit only on the other modification-command, an input token reference related to the token of the other secure transaction unit and an output token reference related to the token of the secure transaction unit.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a secure transaction unit and other secure transaction unit fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Further, the additional element “digital” generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
Claim 10 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
a first digital signature is generated by the secure transaction unit only on the modification-command and all input token references related to the tokens of the secure transaction unit; and/or wherein
a second digital signature is applied by the other secure transaction unit only on the modification-command and an all input token references related to the tokens of the other secure transaction unit.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a secure transaction unit and other secure transaction unit fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Further, the additional element “digital” generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
Claim 11 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
a first digital signature is applied by the secure transaction unit only on the modification-command, all input token references and all output token references related to the tokens of the secure transaction unit; and/or wherein a second digital signature is applied by the other secure transaction unit only on the modification-command, all input token references and all output token references related to the tokens of the other secure transaction unit.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a secure transaction unit and other secure transaction unit fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Further, the additional element “digital” generally links the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-11 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Albert (US 2024/0275599 A1).
Regarding claim 1, Albert discloses:
A secure transaction unit for managing payment transactions in an electronic payment transaction system, the secure transaction unit comprising: (¶0021, A transaction system is a system in which at least two, preferably a plurality of subscriber units can exchange (transmit) tokens directly amongst one another. The transaction system is, for example, a payment transaction system for exchanging monetary values in the form of payment tokens. ¶0068, In one embodiment, the token is an electronic coin data set or payment token for exchanging monetary values between subscriber units. In colloquial terms, such a payment token is also referred to as a "digital coin" or "electronic coin" and represents cash in electronic form. See fig. 1)
means for exchanging one or more tokens with other secure transaction units in the electronic payment transaction system; and (¶0129, According to the invention, a transaction system is provided which comprises a register layer with a token reference register of the preceding type for registering token references, and a direct transaction layer with a plurality of subscriber units, configured for the direct exchange of tokens among one another. ¶0130, According to the invention, a two-layer transaction system is thus provided from a direct transaction layer for the direct exchange of tokens and a register layer. ¶0141, The communication between two subscriber units for exchanging tokens can take place wirelessly or by wire, or for example also on an optical path, preferably via QR code or barcode, and can be designed as a secure channel. ¶0154, The subscriber units TE of the transaction system TS are configured to exchange tokens T directly amongst one another. ¶0173, The wallet serves to securely manage tokens T of the TE, to create token references TR, to modify tokens T and/or to exchange tokens T. See claim 45)
means for transmitting registration requests to a token reference register of the electronic transaction system for registering the tokens in the electronic payment transaction system; (¶0026, Preferably, the entire sequence of registration requests is sent from a subscriber unit of the transaction system to a registration request unit of the transaction system before the verification step is executed… The subscriber unit thus delegates the registration of the entire sequence to the registration request unit. ¶0028, In a less preferred embodiment, the token reference register sequentially receives and verifies each registration request from the sequence of registration requests from the subscriber unit before the next registration request from the sequence of registration requests is received and verified by the subscriber unit. ¶0031, In one embodiment, the subscriber unit and/or the registration request unit sends each registration request from the sequence of registration requests sequentially as an individual registration request to the token reference register without the token reference register, specifically the verification unit, being aware that this individual registration request is part of a sequence of registration requests. The sequence of registration requests is generally provided by a subscriber unit. ¶0087, For example, the registration request is sent by a subscriber unit of the transaction system or a token issuer of the transaction system. ¶0171, This registration request RA can be sent to the token reference register TRR. This registration request RA is received in the token reference register TRR. See claim 43)
control means configured to: in a first mode, generate single registration requests comprising only single modification-commands concerning a modification of a token of the secure transaction unit; and (¶0029, The token reference register can verify (specifically its verification unit) and store (specifically its memory unit) individual registration requests (i.e. individual registration requests relating to a token and/or its modification) or registration request batches (i.e. a plurality of individual registration requests relating to different tokens and/or their one modification) or also sequences of registration requests (i.e. a plurality of individual registration requests relating to the same token and/or its modification). ¶0030, Individual registration requests or parts of a registration request batch can be distributed to different verification units of a token reference register and these can thus be processed in parallel by different verification units of the token reference register. ¶0128, This allows the verification unit(s) to process individual registration requests, registration request batches or even sequences of registration requests, whereby the above-mentioned "load balancing" can be enabled.)
in a second mode, generate and/or process common registration requests comprising more than one modification-command, wherein a modification-command of a common registration request is related to a modification of a token of another secure transaction unit and wherein another modification-command of the common registration request is related to a modification of a token of the secure transaction unit. (¶0029, registration request batches (i.e. a plurality of individual registration requests relating to different tokens and/or their one modification) or also sequences of registration requests (i.e. a plurality of individual registration requests relating to the same token and/or its modification). ¶0138, When receiving a token from another subscriber unit, the received token is merged to the token in the token memory, with a registration request being created for this purpose. Preferably, the registration request has a token reference of the merged token and a token reference of each of the tokens to be merged. ¶0243, This algorithm is now explained using an example in which two modifications are made to a token T: Modification 1 (SPLIT, see also FIG. 6): The token value v a of the token Ta is divided from v=l00 into v6 =30 and into vc=70. Modification 2 (MERGE, see also FIG. 7): The token value v 6 =70 is combined with a token value v d=50 of another 6 token form a new token value ve=120. ¶0246, and can be transmitted together or RAs, g2A RAs,gw form a common signed RA. The TRR checks the validity and confirms all RAs,g (=proofs) by sending the following response RB back to the TE: Status=200, Sig2A, sig(pKeyrRR, [200, Sig2A, Sig2B]). ¶0251, This algorithm is now also explained using an example. Four modifications (SPLIT, MERGE, MERGE, SPLIT) will be carried out on a token T: Modification 1 (SPLIT, see also FIG. 6): The token value v a of the token Ta is divided from v=l00 into v6=30 and into vc=70. Modification 2 (MERGE, see also FIG. 7): The token value v 6 =70 is combined with a token value v d=50 of another token Td to form a new token value ve=120. Modification 3 (MERGE, see also FIG. 7): The token value ve=120 is combined with a token value vf=40 of another token Tf to form a new token value vg=160. Modification 4 (SPLIT, see also FIG. 6): The token value vg=160 is divided into vh=l00 and v,=60.)
Regarding claim 2, Albert discloses:
A secure transaction unit for managing payment transactions in an electronic payment transaction system, the secure transaction unit comprising: (¶0021, A transaction system is a system in which at least two, preferably a plurality of subscriber units can exchange (transmit) tokens directly amongst one another. The transaction system is, for example, a payment transaction system for exchanging monetary values in the form of payment tokens. ¶0068, In one embodiment, the token is an electronic coin data set or payment token for exchanging monetary values between subscriber units. In colloquial terms, such a payment token is also referred to as a "digital coin" or "electronic coin" and represents cash in electronic form. See fig. 1)
means for exchanging one or more tokens with other secure transaction units in the electronic payment transaction system; and (¶0129, According to the invention, a transaction system is provided which comprises a register layer with a token reference register of the preceding type for registering token references, and a direct transaction layer with a plurality of subscriber units, configured for the direct exchange of tokens among one another. ¶0130, According to the invention, a two-layer transaction system is thus provided from a direct transaction layer for the direct exchange of tokens and a register layer. ¶0141, The communication between two subscriber units for exchanging tokens can take place wirelessly or by wire, or for example also on an optical path, preferably via QR code or barcode, and can be designed as a secure channel. ¶0154, The subscriber units TE of the transaction system TS are configured to exchange tokens T directly amongst one another. ¶0173, The wallet serves to securely manage tokens T of the TE, to create token references TR, to modify tokens T and/or to exchange tokens T. See claim 45)
means for transmitting registration requests to a token reference register of the electronic transaction system for registering the tokens in the electronic payment transaction system; (¶0026, Preferably, the entire sequence of registration requests is sent from a subscriber unit of the transaction system to a registration request unit of the transaction system before the verification step is executed… The subscriber unit thus delegates the registration of the entire sequence to the registration request unit. ¶0028, In a less preferred embodiment, the token reference register sequentially receives and verifies each registration request from the sequence of registration requests from the subscriber unit before the next registration request from the sequence of registration requests is received and verified by the subscriber unit. ¶0031, In one embodiment, the subscriber unit and/or the registration request unit sends each registration request from the sequence of registration requests sequentially as an individual registration request to the token reference register without the token reference register, specifically the verification unit, being aware that this individual registration request is part of a sequence of registration requests. The sequence of registration requests is generally provided by a subscriber unit. ¶0087, For example, the registration request is sent by a subscriber unit of the transaction system or a token issuer of the transaction system. ¶0171, This registration request RA can be sent to the token reference register TRR. This registration request RA is received in the token reference register TRR. See claim 43)
control means configured to: in a first mode, generate single registration requests comprising only single modification-commands concerning a modification of a token of the secure transaction unit; and (¶0029, The token reference register can verify (specifically its verification unit) and store (specifically its memory unit) individual registration requests (i.e. individual registration requests relating to a token and/or its modification) or registration request batches (i.e. a plurality of individual registration requests relating to different tokens and/or their one modification) or also sequences of registration requests (i.e. a plurality of individual registration requests relating to the same token and/or its modification). ¶0030, Individual registration requests or parts of a registration request batch can be distributed to different verification units of a token reference register and these can thus be processed in parallel by different verification units of the token reference register. ¶0128, This allows the verification unit(s) to process individual registration requests, registration request batches or even sequences of registration requests, whereby the above-mentioned "load balancing" can be enabled.)
in a second mode, generate and/or process common registration requests, wherein a common registration request comprising one modification-command, one or more token references related to a modification of a token of the secure transaction unit, and one or more token references related to a modification of a token from another secure transaction unit. (¶0029, …registration request batches (i.e. a plurality of individual registration requests relating to different tokens and/or their one modification) or also sequences of registration requests (i.e. a plurality of individual registration requests relating to the same token and/or its modification). ¶0111, In one embodiment, the registration request relates to a switching of a token and preferably the registration request has a token reference of the token to be switched. The switching of the token is a further modification possibility. The token references contained in the registration request can be joined together by chaining (concatenation). If a token is transmitted by a subscriber unit directly to another subscriber unit, for example if the monetary value is to be transmitted as a token value within the scope of a payment transaction, the receiving subscriber unit can now have the token value re-registered to itself. The switching is thus registered in the token reference register. ¶0138, When receiving a token from another subscriber unit, the received token is merged to the token in the token memory, with a registration request being created for this purpose. Preferably, the registration request has a token reference of the merged token and a token reference of each of the tokens to be merged. Claim 44, … wherein a registration request is generated for this purpose, the registration request having a token reference for the merged token and, in each case, a token reference of the tokens to be merged.)
Regarding claim 3, Albert further discloses:
each common registration request comprises token references, wherein (¶0012, The method comprises the method steps of receiving, in a token reference register of the transaction system, a sequence of registration requests, each registration request of the sequence having a first token reference and at least one second token reference, and at least one token reference of a first registration request of the sequence and a token reference of a second registration request of the sequence being identical. ¶0019, Each registration request in the sequence therefore has at least two token references. For a split or merge modification of a token, three token references are provided per registration request. For a switch modification of a token, two token references are provided per registration request.)
each token reference being uniquely assigned to one token, wherein (¶0012, …verifying, using a verification unit of the token reference register, whether at least one of the at least one token reference contained in the received sequence of registration requests can be uniquely assigned to a first token of the transaction system,. ¶0022, Preferably, each token reference from the sequence of registration requests was (past) or is (present) uniquely assigned to a token in the transaction system. ¶0075, A token reference is assigned to each token in the transaction system. This assignment is unique, i.e. one token reference is assigned to precisely one token, and each token reference is assigned precisely one token.)
each token assigned to token references of common registration requests comprises at least a monetary value and a private key of a token-individual key pair as token elements, wherein (¶0070, A first token element of each token of the transaction system is a token value, for example an asset value, an asset, a commodity, and/or a monetary value. ¶0071, A second token element of each token of the transaction system is a private part of a token-individual key pair. ¶0072, The token is formed from the token value (first token element) and the private part.)
each token reference comprising a monetary value of the assigned token and a public key corresponding to the private key of the token-individual key pair as token reference elements. (¶0077, Each token reference in the transaction system is a data set comprising at least two token reference elements. ¶0078, A first token reference element of each token reference is the token value of the token uniquely assigned to the token reference. The token value of the token is thus identical to the token value of the assigned token reference. For example, the token value of the token reference is a copy of the token value of the assigned token. ¶0079, A second token element of each token reference of the transaction system is a public part of the token-individual key pair. ¶0161, A token reference TR can be stored in the token reference register TRR for each token T. The token reference TR comprises the token value v of the assigned token T and a public part R of the token-individual key pair. The token reference TR of the token T can be viewed at any time in the register TRR of the transaction system TS. The token value v of a token T is thus disclosed by the token reference register TRR. ¶0163, The token reference TR is then formed by the token value v of the token and the public part R of the key pair. The token reference TR is therefore the link or chaining of token value v and public part R. )
Regarding claim 4, Albert further discloses:
a first switch-command on a first token having first token-type information to obtain a third token having a monetary value of the first token and the first token-type information; and/or a second switch-command on a second token having second token-type information to obtain a fourth token having the monetary value of the second token (¶0023, A modification to a token is, in particular, the splitting (SPLIT) of tokens ( or their token value) or the merging (MERGE) of at least two tokens ( or their token values) or the switching (SWITCH) of the token from one subscriber unit to another subscriber unit. ¶0033, In a SWITCH modification, the registration request comprises precisely one token reference as an output token reference and precisely one input token reference. ¶0111, In one embodiment, the registration request relates to a switching of a token and preferably the registration request has a token reference of the token to be switched. The switching of the token is a further modification possibility. The token references contained in the registration request can be joined together by chaining (concatenation). If a token is transmitted by a subscriber unit directly to another subscriber unit, for example if the monetary value is to be transmitted as a token value within the scope of a payment transaction, the receiving subscriber unit can now have the token value re-registered to itself. The switching is thus registered in the token reference register. ¶0114, The token value of the token to be switched corresponds to the token value of the switched token. During the switch, a token having the same token value but a new private part is accordingly registered in the token reference register.)
Regarding claim 5, Albert further discloses:
processing the common registration requests requires a signing of the common registration request with a digital signature being generated by the secure transaction unit and/or the other secure transaction unit, preferably the generation being made commonly or independent. (¶0097, In one embodiment, the received registration request is signed with the private part of the token-individual key pair in order to be able to check or verify an assignment of the token reference to the token. ¶0165, In addition, the registration request RA can be signed with the private part r of the token-individual key pair. The signing makes it possible to verify whether the transmitter of the token reference TR was in possession of the token T, whereby the security in the transaction system TS is further increased. ¶0194, Each registration request RA can be signed in order to be able to check that the sender of the token reference TR is also in possession of the associated token T. An ECDSA scheme can be applied as a signature. The registration request RA is preferably signed with the private part r of the token T. ¶0246, and can be transmitted together or RAs, g2A RAs,gw form a common signed RA. The TRR checks the validity and confirms all RAs,g (=proofs) by sending the following response RB back to the TE: Status=200, Sig2A, sig(pKeyrRR, [200, Sig2A, Sig2B])). ¶0254, RAs,g2A and RAs,gw as well as RAs,g3A and RAs,g3B can be transmitted together or form a common signed RA. The TRR checks the validity and determines that RA3 is invalid and sends the following response RB back to the TE: Status=400, Sig3A, sig(pKeyrRR, [400, Sig3A, Sig3B]))
Regarding claim 6, Albert further discloses:
the digital signature is commonly applied on the modification-command of the common registration request related to the modification of the token of the other secure transaction unit and on the other modification-command of the common registration request related to the modification of the token of the secure transaction unit.(¶0097, In one embodiment, the received registration request is signed with the private part of the token-individual key pair in order to be able to check or verify an assignment of the token reference to the token. ¶0165, In addition, the registration request RA can be signed wit