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 .
Response to Amendment
The amendment filed on August 19, 2025 has been entered.
Claims 1-8 have been amended.
Applicant’s amendment and response to the claims are sufficient to overcome the 35 USC § 101 rejection and claim objection set forth in the previous office action. The examiner has withdrawn the rejection/objection.
Response to Arguments
Applicant's arguments filed on August 19, 2025 have been fully considered but they are moot in view of the new grounds of rejection.
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)(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-8 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Eom et al. (Pub. No. US 2023/0060347), hereinafter Eom.
Claim 1. Eom discloses a multi-party computation based digital signature apparatus comprising:
generate a first private key corresponding to a first user (See Parag. [0082]; authentication terminal 100 of the user included in the user group may generate a private key and a public key of the corresponding user (S610));
divide the first private key into a first plurality of private key pieces (See Parag. [0084]; the authentication terminal 100 of each of the plurality of users may generate a plurality of private key fragments by dividing the private key of the corresponding user into the number corresponding to the plurality of users (S620).);
generate a first distribution key corresponding to the first user by using a first private key piece corresponding to the first user among the first plurality of private key pieces, a second private key piece among a second plurality of private key pieces of a second private key corresponding to a user, and a third private key piece among a third
plurality of private key pieces of a third private key corresponding to a third user (See Parag. [0085-0088]; each authentication terminal 100 may generate an encoding key and a decoding key of the corresponding user by using one private key fragment among the plurality of private key fragments. Each authentication terminal 100 may distribute the public key and the encoding key of the corresponding user to other authentication terminals through the authentication management server 200. Each authentication terminal 100 may retain one of the plurality of private key fragments, and encode each of the rest private key fragments with the encoding keys of other users to distribute the encoded private key fragment to the other corresponding user (S650). Each authentication terminal 100 may receive the other user's private key fragments encrypted with the encoding key of the corresponding user (S660). For example, user A may receive a user B's private key fragment and a user C's private key fragment each encoded with the user A's encoding key. In this case, user A may decode the received private key fragments with his/her own decoding key that is being stored); and
generate a common public key based on the first distribution key, a second distribution key, and a third distribution key, the second distribution key corresponding tothe second user generated using a fourth private key piece corresponding to the second user among the second plurality of private key pieces, a fifth private key piece corresponding to the first user among the first plurality of private key pieces, and a sixth private key piece corresponding to the third user among the third plurality of private key pieces, and the third distribution key corresponding to the third user generated using a seventh private key piece corresponding to the third user among the third plurality of private key pieces, an eight private key piece corresponding to the first user among the firstplurality of private key pieces, and a ninth private key piece corresponding to the second user among the second plurality of private key pieces (See Parag. [0041]; the key generation module 110 may be configured to generate a common public key by recombining of public keys of all users participating in the multi-signature. The key generation module 110 may be configured to further generate a private key for multi-signature, an encoding key, a decoding key, and the like in addition to the private key of the user. See Parag. [0054]; authentication terminals may generate a common public key of a multi-signature wallet through the communication channel. In this case, the common public key may be used as a representative address of the multi-signature wallet. These addresses may be used to send and receive digital assets on the blockchain network. See also Parag. [0089-0093]).
Claim 2. Eom discloses the multi-party computation based digital signature
apparatus of claim 1,
Eom further discloses wherein the processor is configured to encrypt the first distribution key with a separate encryption key (See Parag. [0041-0042]; the key generation module 110 may be configured to further generate a private key for multi-signature, an encoding key, a decoding key, and the like in addition to the private key of the user. The encryption module 120 may be configured to encode the corresponding information so that the specific information is not exposed according to the progress of the multi-signature procedure and the authentication procedure).
Claim 3. Eom discloses the multi-party computation based digital signature
apparatus of claim 1,
Eom further discloses wherein the processor is configured to encrypt the first distribution key through an input encryption value or personal biological information of the first user (See Parag. [0041-0042]; the key generation module 110 may be configured to further generate a private key for multi-signature, an encoding key, a decoding key, and the like in addition to the private key of the user. The encryption module 120 may be configured to encode the corresponding information so that the specific information is not exposed according to the progress of the multi-signature procedure and the authentication procedure).
Claim 4. Eom discloses the multi-party computation based digital signature apparatus of claim 1,
Eom further discloses wherein the processor is configured to generate the common public key by using a first computation result value computed by a first computation process on the first distribution key, a second computation result value computed by using a second computation process on the second distribution key, and a third computation result value computed by using a third computation process on the third distribution key (See Parag. [0041]; the key generation module 110 may be configured to generate a common public key by recombining of public keys of all users participating in the multi-signature. The key generation module 110 may be configured to further generate a private key for multi-signature, an encoding key, a decoding key, and the like in addition to the private key of the user. See Parag. [0054]; authentication terminals may generate a common public key of a multi-signature wallet through the communication channel. In this case, the common public key may be used as a representative address of the multi-signature wallet. These addresses may be used to send and receive digital assets on the blockchain network. See also Parag. [0089-0093]).
Claim 5. Eom discloses the multi-party computation based digital signature apparatus of claim 1,
Eom further discloses wherein the processor is configured to: receive a request for a transaction signature from an external server to sign a transaction (See Parag. [0040]; the authentication terminal 100 may be configured to support private key/public key management and to perform multiple signatures on a signature target, such as a transaction. See Parag. [0048]; the verification module 160 may also be configured to request the virtual user to authenticate the validity of the multi-signature or multi-signer authentication information), and
combine a first signature value of the transaction signed with the first distribution key and at least one of a second signature value signed by a second distribution key corresponding to the second user and a third signature value of the transaction signed by a third distribution key corresponding to the third user to derive a joint signature value of the transaction (See Parag. [0090-0091]; each authentication terminal 100 may generate a local signature by using the multi-signature private key, and share the generated local signature with other authentication terminals through the authentication management server 200 (S680). Each authentication terminal 100 may generate a single signature by reconstructing the shared user-specific local signatures through the Threshold Elliptic Curve Digital Signature Algorithm (T-ECDSA) (S690)…),
wherein the joint signature value is verified by using the common public key to confirm a validity of the transaction (See Parag. [0092-0093]; each authentication terminal 100 may encode the generated local signature with an encoding key generated with the time stamp and the one private key fragment, and share the encoded local signature. Meanwhile, t of T-ECDSA is defined as a threshold value at which t+1 users complete multi-signature. In T-ECDSA, t+1 multi-user local signature is performed, and a single signature is generated by using local signatures that are encoded and shared for each user. For the generated single signature, the validity of the signature may be validated with the common public key).
Claim 6. Eom discloses a multi-party computation based digital signature method comprising:
generating a first private key corresponding to a first user (See Parag. [0082]; authentication terminal 100 of the user included in the user group may generate a private key and a public key of the corresponding user (S610));
dividing the first private key into a first plurality of private key pieces (See Parag. [0084]; the authentication terminal 100 of each of the plurality of users may generate a plurality of private key fragments by dividing the private key of the corresponding user into the number corresponding to the plurality of users (S620));
generating a first distribution key corresponding to the first user by using a first private key piece corresponding to the first user among the first plurality of private key pieces, a second private key piece among a second plurality of private key pieces of a
second private key corresponding to a second user, and a third private key piece among a
third plurality of private key pieces of a third private key corresponding to a third user (See Parag. [0085-0088]; each authentication terminal 100 may generate an encoding key and a decoding key of the corresponding user by using one private key fragment among the plurality of private key fragments. Each authentication terminal 100 may distribute the public key and the encoding key of the corresponding user to other authentication terminals through the authentication management server 200. Each authentication terminal 100 may retain one of the plurality of private key fragments, and encode each of the rest private key fragments with the encoding keys of other users to distribute the encoded private key fragment to the other corresponding user (S650). Each authentication terminal 100 may receive the other user's private key fragments encrypted with the encoding key of the corresponding user (S660). For example, user A may receive a user B's private key fragment and a user C's private key fragment each encoded with the user A's encoding key. In this case, user A may decode the received private key fragments with his/her own decoding key that is being stored); and
generate a common public key based on the first distribution key, a second distribution key, and a third distribution key, the second distribution key corresponding to the second user generated using a fourth private key piece corresponding to the second user among the second plurality of private key pieces, a fifth private key piece corresponding to the first user among the first plurality of private key pieces, and a sixth private key piece corresponding to the third user among the third plurality of private key
pieces, and the third distribution key corresponding to the third user generated using a seventh private key piece corresponding to the third user among the third plurality of
private key pieces, an eight private key piece corresponding to the first user among the firstplurality of private key pieces, and a ninth private key piece corresponding to the second
user among the second plurality of private key pieces (See Parag. [0041]; the key generation module 110 may be configured to generate a common public key by recombining of public keys of all users participating in the multi-signature. The key generation module 110 may be configured to further generate a private key for multi-signature, an encoding key, a decoding key, and the like in addition to the private key of the user. See Parag. [0054]; authentication terminals may generate a common public key of a multi-signature wallet through the communication channel. In this case, the common public key may be used as a representative address of the multi-signature wallet. These addresses may be used to send and receive digital assets on the blockchain network. See also Parag. [0089-0093]).
Claim 7. The applicant is directed to the rejections to claim 5 set forth above, as they are rejected based on the same rationale.
Claim 8. Eom discloses a non-transitory computer-readable recording medium having a program recorded thereon for executing a multi-party based digital signature method, the method comprising:
generating a first private key corresponding to a first user (See Parag. [0082]; authentication terminal 100 of the user included in the user group may generate a private key and a public key of the corresponding user (S610));
dividing the first private key into a first plurality of private key pieces (See Parag. [0084]; the authentication terminal 100 of each of the plurality of users may generate a plurality of private key fragments by dividing the private key of the corresponding user into the number corresponding to the plurality of users (S620));
generating a first distribution key corresponding to the first user by using a first
private key piece corresponding to the first user among the first plurality of private key
pieces, a second private key piece among a second plurality of private key pieces of a
second private key corresponding to a second user, and a third private key piece among a
third plurality of private key pieces of a third private key corresponding to a third user (See Parag. [0085-0088]; each authentication terminal 100 may generate an encoding key and a decoding key of the corresponding user by using one private key fragment among the plurality of private key fragments. Each authentication terminal 100 may distribute the public key and the encoding key of the corresponding user to other authentication terminals through the authentication management server 200. Each authentication terminal 100 may retain one of the plurality of private key fragments, and encode each of the rest private key fragments with the encoding keys of other users to distribute the encoded private key fragment to the other corresponding user (S650). Each authentication terminal 100 may receive the other user's private key fragments encrypted with the encoding key of the corresponding user (S660). For example, user A may receive a user B's private key fragment and a user C's private key fragment each encoded with the user A's encoding key. In this case, user A may decode the received private key fragments with his/her own decoding key that is being stored); and
generate a common public key based on the first distribution key, a second
distribution key, and a third distribution key, the second distribution key corresponding to the second user generated using a fourth private key piece corresponding to the second
user among the second plurality of private key pieces, a fifth private key piece
corresponding to the first user among the first plurality of private key pieces, and a sixth
private key piece corresponding to the third user among the third plurality of private key
pieces, and the third distribution key corresponding to the third user generated using a
seventh private key piece corresponding to the third user among the third plurality of
private key pieces, an eight private key piece corresponding to the first user among the firstplurality of private key pieces, and a ninth private key piece corresponding to the second user among the second plurality of private key pieces (See Parag. [0041]; the key generation module 110 may be configured to generate a common public key by recombining of public keys of all users participating in the multi-signature. The key generation module 110 may be configured to further generate a private key for multi-signature, an encoding key, a decoding key, and the like in addition to the private key of the user. See Parag. [0054]; authentication terminals may generate a common public key of a multi-signature wallet through the communication channel. In this case, the common public key may be used as a representative address of the multi-signature wallet. These addresses may be used to send and receive digital assets on the blockchain network. See also Parag. [0089-0093]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure (see PTO-form 892).
The following Patents and Papers are cited to further show the state of the art at the time of Applicant’s invention with respect to Digital Signature Based on Multi-party Computation.
Beery et al. (Patent No. US 12,192,381); “System and Method for Secure Multi-party Computation Based Blockchain Transaction;” related to systems and methods for secure multi-party computation based blockchain transactions
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, 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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GHIZLANE MAAZOUZ whose telephone number is (571)272-8118. The examiner can normally be reached Telework M-F 7:30-5 PM.
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, Philip J Chea can be reached on 571-272-3951. 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.
/GHIZLANE MAAZOUZ/Examiner, Art Unit 2499
/PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499