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 .
Status of the Claims
This is a final rejection prepared in response to applicant’s amendment filed on April 20, 2026.
Claims 1-2 are amended.
Claims 12-15 are withdrawn.
Claims 1-11 are pending.
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:
a communication interface configured to exchange one or more tokens with other secure transaction units in the electronic payment transaction system; and
the communication interface being configured to transmit registration requests to a token reference register of the electronic transaction system for registering the tokens in the electronic payment transaction system;
one or more processors 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 stored in another secure transaction unit and wherein another modification-command of the common registration request is related to a modification of a token stored in the secure transaction unit, the common registration request being configured to cause the token reference register to process the modifications as an atomic operation such that either all of the modifications are registered or none of the modifications are registered.
Claim 1, recites (i.e., sets forth or describes) an abstract idea of securely registering 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 comprises one modification-command, one or more token references related to a modification of a token stored in the secure transaction unit, and one or more token references related to a modification of a token stored in another secure transaction unit, the common registration request being configured to cause the token reference register to process the modifications as an atomic operation such that either all of the modifications are registered or none of the modifications are registered. ” 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 stored in another secure transaction unit and wherein another modification-command of the common registration request is related to a modification of a token stored in the secure transaction unit, the common registration request being configured to cause the token reference register to process the modifications as an atomic operation such that either all of the modifications are registered or none of the modifications are registered.” 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 communication interface, one or more processors, 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)
a communication interface configured to exchange 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)
the communication interface being further configured to transmit 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)
one or more processors 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 stored in another secure transaction unit and wherein another modification-command of the common registration request is related to a modification of a token stored in the secure transaction unit, the common registration request being configured to cause the token reference register to process the modifications as an atomic operation such that either all of the modifications are registered or none of the modifications are registered. (¶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)
a communication interface configured to exchange 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)
the communication interface being further configured to transmit 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)
one or more processors 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 comprises one modification-command, one or more token references related to a modification of a token stored in the secure transaction unit, and one or more token references related to a modification of a token stored in another secure transaction unit, the common registration request being configured to cause the token reference register to process the modifications as an atomic operation such that either all of the modifications are registered or none of the modifications are registered. (¶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 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. ¶0183, A registration request RA is preferably signed with the private part r. The signature allows the syntactic authenticity of the command to be easily checked by the recipient (TRR or TE). This check is preferably carried out in database 1 or verification unit 2. In addition, a registration request RA can, for example, be validated syntactically by checking the signature and/or the token reference TR. ¶0189, FIG. 3b shows an overview of commands CO and their signed registration request syntax RA. In this case, input tokens T and input token references TR are "consumed" per command CO. In this case, output tokens T and output token references TR are "created" per command CO.)
Further, regarding the claimed limitation “applied on…” in “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.” consists of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Regarding claim 7, Albert further discloses:
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. (¶0189, FIG. 3b shows an overview of commands CO and their signed registration request syntax RA. In this case, input tokens T and input token references TR are "consumed" per command CO. In this case, output tokens T and output token references TR are "created" per command CO. ¶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.)
Further, regarding the claimed limitations “…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” does not move to distinguish over prior art.
Regarding claim 8, Albert further discloses:
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. (¶0189, FIG. 3b shows an overview of commands CO and their signed registration request syntax RA. In this case, input tokens T and input token references TR are "consumed" per command CO. In this case, output tokens T and output token references TR are "created" per command CO. ¶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.)
Further, regarding the claimed limitations “…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.” does not move to distinguish over prior art.
Regarding claim 9, Albert further discloses:
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. (¶0189, FIG. 3b shows an overview of commands CO and their signed registration request syntax RA. In this case, input tokens T and input token references TR are "consumed" per command CO. In this case, output tokens T and output token references TR are "created" per command CO. ¶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.)
Further, regarding the claimed limitations “…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.” does not move to distinguish over prior art.
Regarding claim 10, Albert further discloses:
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. (¶0189, FIG. 3b shows an overview of commands CO and their signed registration request syntax RA. In this case, input tokens T and input token references TR are "consumed" per command CO. In this case, output tokens T and output token references TR are "created" per command CO. ¶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.)
Further, regarding the claimed limitations “…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.” does not move to distinguish over prior art.
Regarding claim 11, Albert further discloses:
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. (¶0189, FIG. 3b shows an overview of commands CO and their signed registration request syntax RA. In this case, input tokens T and input token references TR are "consumed" per command CO. In this case, output tokens T and output token references TR are "created" per command CO. ¶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.)
Further, regarding the claimed limitations “…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.” does not move to distinguish over prior art.
Response to Arguments
Claim Rejections – 35 U.S.C. § 112
Claim rejections 35 U.S.C. § 112 in the previous non-final action dated 12/19/2025 are withdrawn in light of the claim amendments.
Claim Rejections – 35 U.S.C. § 101
The applicant asserts that “claims are not directed merely to a fundamental economic practice or to the general idea of securely exchanging tokens” and that “the amended claims integrate any alleged abstract idea into a practical application”. The basis of these assertions are based on the applicant’s argument on pages 13-14.
First, regarding the applicant’s assertion that “claims are not directed merely to a fundamental economic practice or to the general idea of securely exchanging tokens”, the examiner finds it not persuasive and respectfully disagrees. The claim does not recite any improvement to a computer functionality or the operations of the recited secured transaction units. Rather, the claim recites exchanging tokens, transmitting registration requests to a register and processing modification commands to update token registrations. In summary, these operations are directed to managing information related to payment tokens and coordinating modification of token records in a payment system. The recited elements are merely used to perform the abstract idea and the claims do not recite any specific improvement to any of these elements or any other computer technology. As a whole the claims are directed to registering, exchanging and updating token records used in payment transactions which constitute to managing financial or commercial information and therefore fall under certain methods of organizing human activities as stated on the claim rejection.
Second, regarding the applicant’s assertion that “the amended claims integrate any alleged abstract idea into a practical application”, the examiner also finds it not persuasive and respectfully disagrees. The additional elements of a communication interface, one or more processors, a secure transaction unit and an electronic payment transaction do not integrate the abstract idea into a practical application because they are merely use to implement the token registration and modification process using generic computer components. The claim does not recite any specific improvement to the functioning of the secured transaction units, token reference register, processors or any other computer technology. Therefore, the claim does not recite any technological advancement or inventive integration beyond applying these tools to an abstract concept and thus fail to impose any meaningful limit that would transform the abstract idea into a practical application under the second prong of step 2A of the subject matter eligibility framework
As such the claims remain within an abstract idea and rejection is maintained based on the
newly amended claims and applicants assertions.
Claim Rejections – 35 U.S.C. § 102
Applicant submits remarks and arguments geared toward the amendments. Examiner has carefully reviewed and considered Applicant’s remarks, however they are not persuasive in light of the fact that:
they are geared towards the newly added claimed expression in the amendments
(2) the claimed limitation “configured to…” in “the common registration request being configured to cause the token reference register to process the modifications as an atomic operation such that either all of the modifications are registered or none of the modifications are registered.” consists of language disclosing an intended use, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
(3) the claimed limitations “wherein a modification-command of a common registration request is related to a modification of a token stored in another secure transaction unit” and “wherein another modification-command of the common registration request is related to a modification of a token stored in the secure transaction unit.” only describe characteristics of the modification-commands which are non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
As such the claim rejection is maintained in light of the on the newly amended claims and applicants arguments .
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20180034642 A1 to Kaehler discloses: The method involves receiving receiver individual record from record receiver device. The receiver individual record has sender individual record and receiver signature of receiver individual record. The sender signature is created using sender private key of record sender device. The receiver signature is created using receiver private key of record receiver device. The receiver public key and receiver private key form a receiver public-key cryptographic pair. The receiver individual record is verified. The record receiver device is performed as instructed by receiver individual record
US 10652019 B1 to Nicolas et. al discloses: Disclosed herein are system, method, and computer program product embodiments for performing transactions or atomic swaps using zero-knowledge proofs (“ZKPs”). A first system may propose a transaction between with a second system. The first system may generate a first ZKP indicating that the first system has possession of an asset desired by the second system and that the first system is committing the asset to the transaction. The second system may also similarly generate a second ZKP. These ZKPs may be encrypted and exchanged. The second system may receive an encrypted version of the first ZKP, perform a decryption using a key specific to the second system, and verify the ZKP. When the parties verify the ZKPs, this confirms that each party has committed the requested asset and that the transaction may proceed. The transaction may be committed to a blockchain.
US 20230103038 A1 to Fritzhanns et. al discloses The invention relates to a method for directly transmitting electronic coin datasets between terminals, wherein a first terminal has at least one electronic coin dataset, and the at least one electronic coin dataset has a monetary value and a concealment value. The method has the steps of: determining a masking mode from at least two masking modes, a first masking mode consisting of: masking the electronic coin dataset, preferably in the first terminal, by applying a one-way function to the first coin dataset in order to obtain a completely masked electronic coin dataset; and registering a masked electronic coin dataset in a monitoring entity. The invention additionally relates to a payment system with a monitoring layer using a database, which is controlled in a decentralized manner and in which masked electronic coin datasets are stored, and a direct transaction layer, which uses at least two terminals and in which the method can be carried out.
ES 2833552 T3 to Cui et. al discloses: A computer-implemented method for information protection, comprising: committing (301) a transaction amount t of a transaction with a commitment scheme to obtain a transaction commitment value T, the commitment scheme comprising at least one transaction hiding factor r_t; encrypting (302) a combination of the transaction hiding factor r_t and the transaction amount t with a public key PK_B of a recipient of the transaction; transmitting (303) the transaction commitment value T and the encrypted combination to a recipient node associated with the recipient for the recipient node to verify the transaction; receiving (205) a SIGB signature from the receiver representing that the receiving node has approved the transaction by signing the transaction with a private key SK_B from the receiver; approving (206) the transaction by signing the transaction with an issuer's private key SK_A to generate an issuer's signature SIGA; and send (207) the sender and receiver approved transaction to one or more nodes in a blockchain network for one or more nodes to verify the transaction through consensus verification, the sender approved transaction and the receiver comprising the encrypted combination, the transaction commitment value T, the sender's signature SIGA and the receiver's signature SIGB.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JANICE LOZA whose telephone number is (571)270-3979. The examiner can normally be reached Monday - Friday 7:30am - 5:00pm.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/J.L./Examiner, Art Unit 3698
/STEVEN S KIM/Primary Examiner, Art Unit 3698
Prosecution Insights