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 Claims
This action is in reply to the amendment filed 02/17/2026.
This Office action is 2nd Non-Final Office action to the amendment filed 02/17/2026.
Claims 1 and 8 have been amended. Claims 1-5 and 8 are pending and have been examined on the merits (claims 1 and 8 being independent). Claims 6-7 have been canceled.
The amendment filed 02/17/2026 to the claims has been entered.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 02/05/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant’s arguments and amendments filed 02/17/2026 have been fully considered.
With regard to the rejections of claims under 35 U.S.C. 103, Applicant’s arguments and amendments have been considered but are not persuasive and Examiner respectfully disagrees. Examiner notes that Applicant is arguing newly amended claim language. As noted in the citation above the prior art and it is addressed by the rejections under 35 USC 103.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-5 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
In claim 1, the claimed system has two components, “a blockchain distributed ledger system” and “a utilization group system”. However, the “wherein” clause appears to describe a method step. To cure this problem, the “wherein” clause should be re-stated as a manner of configuration of one or both components of the claimed system (see MPEP 2173.05(p)(I-II)).
Claim 2 has a similar issue. First, claim 2 specifies components of “the utilization group system”. But then the last limitation, beginning with “wherein the wallet management distributed ledger is launched” reads like a method step (see MPEP 2173.05(p)(I-II)).
Dependent claims (2-5) stand rejected also, under 35 U.S.C. 112(b) by virtue of their dependency on a rejected claim.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
In the rejections below, where claims are currently amended, this is indicated by underlining.
Claims 1-5 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Sato et al. (hereinafter Sato), US Publication Number 2019/0354968 A1 in view of Saad et al. (hereinafter Saad), US Publication Number 2023/0394471 A1.
Regarding claim 1:
Sato discloses the following:
A distributed ledger data management system for managing data exchange among utilization groups for individuals and organizations participating in a distributed ledger system, comprising: (Sato: See paragraphs [0054] “In FIGS. lA and 1B, there are two tasks including a task A and a task B, and utilization groups thereof are different from each other (in the drawing, the different task groups are referred to as a channel).” And [0055] “For example, in a task A channel, at least an organization 1 (Orgl), an organization 2 (Org2), and an organization 3 (Org3) participate, and nodes are owned/mutually utilized among the respective organizations. when the Orgl issues a transaction (hereinafter, referred to as TX), execution/approval of the corresponding TX is performed not only by a node of the Orgl itself, but also by a node of another organization (Org2). In addition, a TX execution result is copied to be shared in a distributed ledger of each organization.”), and see also [0066])
a blockchain distributed ledger system which is configured to have a plurality of distributed ledger nodes and a distributed ledger network constructed from the plurality of distributed ledger nodes coupled to each other; and (Sato: See paragraph [0060] “the computer system constituting the distributed ledger system 5 described above is configured to include a one or more distributed ledger nodes 3 and one or more client nodes 4 as illustrated in FIG. 2. These devices are connected to a network 1 through a physical communication line 2.”, and see also [0066])
wherein at least one of the plurality of wallet management distributed ledger nodes generates the secret key of the organization, and the plurality of wallet management distributed ledger nodes each store the secret key in an encrypted state, and (Sato: See paragraph [0148] “The member management unit generates a set of a secret key D31 and a public key D32 and associates the set of keys with the member ID (S102).” and [0150] “The node receiving the secret key D31 stores the received secret key D31 as its own secret key D31”, and Notes: Examiner considers a data structure of a blockchain on a distributed ledger stores data (e.g., a secret key or public key) which is inherently encrypted, but the combination of Sato and Saad further discloses for “an encrypted state” as claimed above.)
wherein the least one of the plurality of wallet management distributed ledger nodes resisters a public key corresponding to the secret key in at least one of the distributed ledger nodes, (Sato: See paragraph [0148] “The member management unit generates a set of a secret key D31 and a public key D32 and associates the set of keys with the member ID (S102).”, and [0149] “Next, the member management unit 33 broadcasts the member ID as the new registration target and the generated public key D32 to another node (S103). Information of the member ID and the generated public key D32 which are broadcasted is stored in each node”)
wherein the wallet management distributed ledger client implements, through execution of a program, a workflow application unit which executes a process related to demanding issuance of a predetermined transaction, which is an application demanded by a first utilizer in the organization, and a workflow approval unit which executes a process related to approval of the application by a second utilizer in the organization different from the first utilizer, the second utilizer being selected from among a plurality of utilizers in the organization, and (Sato: See paragraphs [0055] “For example, in a task A channel, at least an organization 1 (Orgl), an organization 2 (Org2), and an organization 3 (Org3) participate, and nodes are owned/mutually utilized among the respective organizations. when the Orgl issues a transaction (hereinafter, referred to as TX), execution/approval of the corresponding TX is performed not only by a node of the Orgl itself, but also by a node of another organization (Org2). In addition, a TX execution result is copied to be shared in a distributed ledger of each organization.” And [0180] “when each acquired TX executer/approver does not coincide with the TX issuer, the distributed ledger node 3 repeats addition of 10 pt of a contribution degree by an organization to which the TX executer/approver belongs and addition of 10 pt of a consumption degree by an organization to which the TX issuer belongs. For example, in a case of a certain BizLog, when a TX issuer is a user of an "organization A", and a TX executer/approver are respective users of the "organization A", an "organization B", and an "organization C", a consumption degree by the "organization A" is 20 pt, and contribution degrees of the "organization B" and the "organization C" are 10 pt, respectively.”, and Notes: Examiner considers the “TX executer/approver” (i.e. “a second utilizer” as claimed) and “TX issuer” (i.e. “a first utilizer” as claimed) as cited disclose for choosing the approver is within the organization. So, it teaches the second utilizer in the organization different from the first utilizer as required in the claim.)
wherein the wallet management distributed ledger node implements, through execution of a program, a workflow management unit which manages a workflow from the application to the approval through data exchange between the workflow application unit and the workflow approval unit and, if the approval for the application is completed, determines the issuance of the predetermined transaction, and (Sato: See paragraph [0055] “For example, in a task A channel, at least an organization 1 (Orgl), an organization 2 (Org2), and an organization 3 (Org3) participate, and nodes are owned/mutually utilized among the respective organizations. when the Orgl issues a transaction (hereinafter, referred to as TX), execution/approval of the corresponding TX is performed not only by a node of the Orgl itself, but also by a node of another organization (Org2). In addition, a TX execution result is copied to be shared in a distributed ledger of each organization.’)
wherein a transaction issuance unit which issues the transaction to the distributed ledger system using the secret key of the organization in accordance with the determination of the issuance of the transaction by the workflow management unit. (Sato: See paragraphs [0067] “In the member management unit 33, it is assumed that authentication of a participant organization and a member belonging to the organization, signing a TX, a control of SC execution authority, or the like is performed by using a secret key and a public key in pairs. Key information handled by the member management unit 33 described above is stored and managed in the participant member management information D3.” And [0095] “The electronic signature is generated by using a secret key of each participant member (that is, an SC provider or user) which is issued by the member management unit 33, and can be verified by a public key provided with the secret key in pairs.”, and Notes: The citation of “a member belonging to the organization” and “using a secret key of each participant member” teach “using a secret key of the organization” as claimed)
Sato does not explicitly disclose the following, however Saad further teaches:
a utilization group system for an organization including a wallet management distributed ledger which is a blockchain distributed ledger configured by a plurality of wallet management distributed ledger nodes coupled to each other that construct a wallet management distributed ledger network and perform reading and writing to and from the distributed ledge nodes, (Saad: See paragraph [0026] “The cryptocurrency network 180 may include multiple computer nodes for managing transactions associated with a cryptocurrency using a decentralized and distributed ledger ( e.g., a blockchain). The decentralized and distributed ledger may store transaction data related to cryptocurrency transactions of the cryptocurrency. Each computer node within the cryptocurrency network 180 manages a copy of the distributed ledger. When the computer nodes receive transaction data associated with a cryptocurrency transaction from a device (e.g., the user device 110, etc.), the computer nodes compete against each other in solving a mathematical problem (which is part of a verification process such as a proof-of-work process or a proof-of-stake process). Once a computer node solves the mathematical problem, the computer node may record the transaction (e.g., in a block) on its copy of the distributed ledger, and broadcast the block and the solution to the mathematical problem to the other computer nodes, such that the other computer nodes can update their copies of the distributed ledger.”)
wherein the wallet management distributed ledger generates a secret key of the organization and stores the secret key in an encrypted state, and (Saad: See paragraph [0016] “Each cryptocurrency wallet is typically associated with a pair of encryption keys ( e.g., a private key and a public key), generated using a key generation algorithm associated with the corresponding cryptocurrency. For example, a private key may first be generated (e.g., randomly or using a particular algorithm, etc.). The private key may then be provided to the key generation algorithm to produce a corresponding public key. A characteristic of the private key and the public key is that data that is encrypted using the private key can only be decrypted using the corresponding public key, and vice versa.”)
wherein the plurality of wallet management distributed ledger nodes issue a transaction to the blockchain distributed ledger system by using the encrypted secret key of the organization, (Saad: See paragraph [0017] “The private key is kept as a secret by the owner of the cryptocurrency wallet and can be used by the owner of the cryptocurrency wallet to encrypt transaction request/ transaction data to be recorded on the distributed ledger (e.g., a blockchain). The cryptocurrency network (a group of computer nodes configured to maintain the distributed ledger and record transactions on the distributed ledger) or anyone who has access to the distributed ledger may verify the transaction request/transaction data generated by the owner of the cryptocurrency wallet by decrypting the data using the public key associated with the cryptocurrency wallet.”, and see also [0016])
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify a distributed ledger system constituted by respective nodes of a plurality of organizations, each of at least a predetermined plurality of nodes among the nodes executes a smart contract which manages a processing history of a transaction in the distributed ledger system in a distributed ledger of Sato to include generating a pair of encryption keys (e.g., a private key and a public key) using a key generation algorithm, as taught by Saad, in order to provide a more secure handing of sensitive information. (Saad, paragraphs [0016-0017])
Regarding claim 2:
Sato discloses the following:
The distributed ledger data management system according to claim 1, wherein the wallet management distributed ledger is coupled to the distributed ledger system, wherein the utilization group system for the organization includes a plurality of wallet management distributed ledger clients which are terminals to be manipulated by a utilizer belonging to the utilization group for the organization and are coupled to the wallet management distributed ledger, and (Sato: See paragraph [0060] “the computer system constituting the distributed ledger system 5 described above is configured to include a one or more distributed ledger nodes 3 and one or more client nodes 4 as illustrated in FIG. 2. These devices are connected to a network 1 through a physical communication line 2.”)
wherein the wallet management distributed ledger is launched in accordance with a launch demand from the wallet management distributed ledger client when the utilization group for the organization participates in the distributed ledger system. (Sato: See paragraphs [0066] “the distributed ledger node 3 receives a TX by the function of the transaction management unit 34 in response to a request from each node such as the client node 4 or the like, or acquires information such as an execution history of the corresponding TX or the like and allows the acquired information to be read in the client node 4 through a predetermined interface. the distributed ledger node 3 can issue a TX, and can issue various TXs through the transaction issuing unit 35.” and [0160] “After the consensus building described above, the consensus management unit 31 broadcasts the approved TX to all the distributed ledger nodes 3 by using a function of the approved TX distribution unit 36.”, and see also [0126-0127])
Regarding claim 3:
Sato discloses the following:
The distributed ledger data management system according to claim 2, wherein the plurality of wallet management distributed ledger nodes are launched in accordance with the launch demand from the wallet management distributed ledger client. (Sato: See paragraphs [0066] “the distributed ledger node 3 receives a TX by the function of the transaction management unit 34 in response to a request from each node such as the client node 4 or the like, or acquires information such as an execution history of the corresponding TX or the like and allows the acquired information to be read in the client node 4 through a predetermined interface. the distributed ledger node 3 can issue a TX, and can issue various TXs through the transaction issuing unit 35.” and [0160] “After the consensus building described above, the consensus management unit 31 broadcasts the approved TX to all the distributed ledger nodes 3 by using a function of the approved TX distribution unit 36.”, and see also [0073])
Regarding claim 4:
Sato does not explicitly disclose the following, however Saad further teaches:
The distributed ledger data management system according to claim 3, wherein the wallet management distributed ledger node has a secure computation function that executes an arithmetic in a concealed state and executes a process related to generation and management of the secret key of the organization by utilizing the secure computation function. (Saad: See paragraph [0016] “The mechanism to verify the ownership of a cryptocurrency wallet can be implemented in one of two ways-a synchronous method and an asynchronous method. Each cryptocurrency wallet is typically associated with a pair of encryption keys (e.g., a private key and a public key), generated using a key generation algorithm associated with the corresponding cryptocurrency. For example, a private key may first be generated (e.g., randomly or using a particular algorithm, etc.). The private key may then be provided to the key generation algorithm to produce a corresponding public key”)
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify a distributed ledger system constituted by respective nodes of a plurality of organizations, each of at least a predetermined plurality of nodes among the nodes executes a smart contract which manages a processing history of a transaction in the distributed ledger system in a distributed ledger of Sato to include generating a pair of encryption keys (e.g., a private key and a public key) using a key generation algorithm, as taught by Saad, in order to provide a more secure handing of sensitive information. (Saad, paragraphs [0016-0017])
Regarding claim 5:
Sato discloses the following:
The distributed ledger data management system according to claim 4, wherein the wallet management distributed ledger node manages, in a concealed state, the secret key of the organization generated in the concealed state and a public key paired with the secret key and issues a transaction to the distributed ledger system by using the concealed secret key. (Sato: See paragraphs [0067] “In the member management unit 33, it is assumed that authentication of a participant organization and a member belonging to the organization, signing a TX, a control of SC execution authority, or the like is performed by using a secret key and a public key in pairs. Key information handled by the member management unit 33 described above is stored and managed in the participant member management information D3.” And [0095] “The electronic signature is generated by using a secret key of each participant member (that is, an SC provider or user) which is issued by the member management unit 33, and can be verified by a public key provided with the secret key in pairs.”)
Regarding claim 8: it is similar scope to claim 1, and thus it is rejected under similar rationale.
Conclusion
The prior art made of record but not relied upon herein but pertinent to Applicant’s disclosure is listed in the enclosed PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YONG S PARK whose telephone number is (571)272-8349. The examiner can normally be reached M-F 9:00-5:00 PM, EST.
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, Bennett M. Sigmond can be reached on (303)297-4411. 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.
/YONGSIK PARK/Examiner, Art Unit 3694 April 15, 2026
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights