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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on May 27, 2026 has been entered.
Response to Amendment
The amendment filed on May 27, 2026 has been entered.
Claims 1, 6 and 8 have been amended.
Response to Arguments
Applicant's arguments filed on May 27, 2026 have been fully considered but they are moot in view of the new grounds of rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-8 are rejected under 35 U.S.C. 103 as being unpatentable over Eom et al. (Pub. No. US 2023/0060347), hereinafter Eom; in view of Craige et al. (Pub. No. US 2021/0036841), hereinafter Craige.
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)); 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 first plurality 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]).
Eom doesn’t explicitly disclose combine 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 and store a combination of the first private key piece, the second private key piece, and the third private key piece as a first distribution key corresponding to the first user.
However, Craige discloses:
combine 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 and store a combination of the first private key piece, the second private key piece, and the third private key piece as a first distribution key corresponding to the first user (See Parag. [0022]; generating a signing key (message signing key), splitting the signing key into secret shares encrypted to different participants, and uploading the encrypted secret shares to a message signing system. See Parag. [0077-0078] and Fig. 2C; splitting the message signing key S221 and encrypting the shares S225. Splitting the message signing key includes splitting the message signing private key (sk) generated at S210. See Parag. [0104]; the signing secrets generated at S220 are stored at S226. In some variations, the sending system (e.g., the issuer system 111) stores the encrypted signing secrets in association with the signature verification key PK generated at S212. Additionally or alternatively, the signing secret (c.sub.i) can be stored in association with the respective participant (p.sub.i). In some variations, the sending system stores the encrypted signing secrets (c.sub.i) at the message signing system 112, or in storage accessible by the message signing system 112. In some variations, the sending system stores the encrypted signing secrets (c.sub.i) at a respective participant system p.sub.i.).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Eom, to include combining the private key pieces and storing a combination of the first private key piece, the second private key piece, and the third private key piece as a first distribution key corresponding to the first user, as taught by Craige. This would be to improve security by distributing the signing process among a plurality of systems, rather than entrusting signing to a single trusted system (Craige, Parag. [0002]).
Claim 2. Eom in view of Craige 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 in view of Craige 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 in view of Craige 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 in view of Craige 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)); 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]).
Eom doesn’t explicitly disclose combining 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 and storing a combination of the first private key piece, the second private key piece, and the third private key piece as a first distribution key corresponding to the first user.
However, Craige discloses:
combining 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 and storing a combination of the first private key piece, the second private key piece, and the third private key piece as a first distribution key corresponding to the first user (See Parag. [0022]; generating a signing key (message signing key), splitting the signing key into secret shares encrypted to different participants, and uploading the encrypted secret shares to a message signing system. See Parag. [0077-0078] and Fig. 2C; splitting the message signing key S221 and encrypting the shares S225. Splitting the message signing key includes splitting the message signing private key (sk) generated at S210. See Parag. [0104]; the signing secrets generated at S220 are stored at S226. In some variations, the sending system (e.g., the issuer system 111) stores the encrypted signing secrets in association with the signature verification key PK generated at S212. Additionally or alternatively, the signing secret (c.sub.i) can be stored in association with the respective participant (p.sub.i). In some variations, the sending system stores the encrypted signing secrets (c.sub.i) at the message signing system 112, or in storage accessible by the message signing system 112. In some variations, the sending system stores the encrypted signing secrets (c.sub.i) at a respective participant system p.sub.i.).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Eom, to include combining the private key pieces and storing a combination of the first private key piece, the second private key piece, and the third private key piece as a first distribution key corresponding to the first user, as taught by Craige. This would be to improve security by distributing the signing process among a plurality of systems, rather than entrusting signing to a single trusted system (Craige, Parag. [0002]).
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)); 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]).
Eom doesn’t explicitly disclose combining 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 and storing a combination of the first private key piece, the second private key piece, and the third private key piece as a first distribution key corresponding to the first user.
However, Craige discloses:
combining 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 and storing a combination of the first private key piece, the second private key piece, and the third private key piece as a first distribution key corresponding to the first user (See Parag. [0022]; generating a signing key (message signing key), splitting the signing key into secret shares encrypted to different participants, and uploading the encrypted secret shares to a message signing system. See Parag. [0077-0078] and Fig. 2C; splitting the message signing key S221 and encrypting the shares S225. Splitting the message signing key includes splitting the message signing private key (sk) generated at S210. See Parag. [0104]; the signing secrets generated at S220 are stored at S226. In some variations, the sending system (e.g., the issuer system 111) stores the encrypted signing secrets in association with the signature verification key PK generated at S212. Additionally or alternatively, the signing secret (c.sub.i) can be stored in association with the respective participant (p.sub.i). In some variations, the sending system stores the encrypted signing secrets (c.sub.i) at the message signing system 112, or in storage accessible by the message signing system 112. In some variations, the sending system stores the encrypted signing secrets (c.sub.i) at a respective participant system p.sub.i.).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Eom, to include combining the private key pieces and storing a combination of the first private key piece, the second private key piece, and the third private key piece as a first distribution key corresponding to the first user, as taught by Craige. This would be to improve security by distributing the signing process among a plurality of systems, rather than entrusting signing to a single trusted system (Craige, Parag. [0002]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure (see PTO-form 892).
Nara et al. (Pub. No. US 2025/0211431) – related to secret sharing multi-party computation (MPC) technology. FIG. 2 schematically illustrates an example of a conceptual structure of a system having a plurality of user apparatuses (clients) UXj (j=A, B, C) and three MPC servers (participant apparatuses) MPCXi (i=1, 2, 3). Each client (A, B, C) divides confidential information (A, B, C) to generate secret shares of the information and transmits the respective shares (A, B, C) to each MPC server (1, 2, 3). Each MPC server performs MPC processing based on the received shares (input shares) and obtains shares of each result. In this case, each client generates secret shares of the confidential information for each MPC server and directly transmits the secret shares to each MPC server. When receiving the shares of the MPC processing results, each client also directly receives them from each MPC server (See Parag. [0041-0045] and Fig. 2C).
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
Prosecution Insights