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 .
Priority
Examiner acknowledges applicants’ claim of priority to Korean Patent Application KR10-2022/0068036, filed June 3, 2022, as supported by certified copies.
Remarks
Claims 1 – 12 are currently pending, of which claims 1 and 7 are independent.
Information Disclosure Statement
The information disclosure statements (IDS) were submitted on December 2, 2024, and November 17, 2025. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
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 – 6 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter because they are directed to software, per se.
Independent claim 1 recites, in part, “A system for inter-shard transaction in a blockchain network on a first node… the first node comprises: a home shard calculation unit… a working shard information request unit… a working shard information reception unit…; and a transaction transmission unit…” These elements are not recited as bearing any physical structure, and appear to be a list of software modules. The Specification indicates (at [120]) that these “units” exist as software within the node, and that the node may ([56]) be computers; however, the claim itself is silent regarding the physical structure of these elements. The claim is therefore determined to be reciting merely software, per se, and is rejected for that reason.
Claims 2 – 6 depend from claim 1, either directly or indirectly, and therefore inherit the deficiency of the claim from which they depend. These claims do not include any limitations that cure the deficiency of the parent claim and are therefore similarly rejected.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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 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 – 12 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Huang, U.S. PG-Pub. No. 2023/0205573, claiming a priority date of July 20, 2018, (hereafter, “Huang”).
As to Claim 1, Huang discloses: a system for inter-shard transaction in a blockchain network on a first node that manages a first sender account that performs a first transaction, wherein:
the first node comprises:
a home shard calculation unit that computes home shard information of a first receiver account that performs the first transaction based on information on an address of the first receiver account and information on a total number of shards ([0078], “A miner receives the request and dispatches (410) the request to corresponding shard. A sender pay (445) or receiver pay operation (450) is performed if the signature is valid (415) and the dApp name is valid (420) based on receiver pay support (425), policy compliance (430), and if fee is sufficient (435, 440).”);
a working shard information request unit that requests working shard information of the first receiver account to a second node that has a home shard of the first receiver account as a working shard ([0079], “The dApp run transaction is encapsulated into the proposed block and broadcast (460) to the network. A validator, e.g., miner, receives (465) the block and verifies all transactions.”);
a working shard information reception unit that receives the working shard information of the first receiver account from the second node ([0080], “A miner receives (510) the request and dispatches the request to the corresponding shard.”); and
a transaction transmission unit that requests the first transaction to a node that manages the first receiver account ([0081], “… a destination dApp owner creates a link approval transaction and broadcast (572) the transaction to the network.”).
As to Claim 2, Huang discloses: the inter-shard transaction system of claim 1, wherein the first node further comprises a receiver account search unit that searches whether the first receiver account is included in an account belonging to a working shard of the first sender account ([0064], “Shards includes system shards and user shards. For example, system shards start with “sys.” The owner of the system shards is all the users of the entire system. According to the shard transaction rule, all users in the system shard can perform transactions to each other. In the system shard, user can transfer asset or send messages to another user without a fee.”).
As to Claim 3, Huang discloses: the inter-shard transaction system of claim 1, wherein the working shard of the first node is a home shard of a second receiver account that performs a second transaction ([0040], “The transactions for different shards are then executed in parallel by different software threads of the same blockchain node software process.”), and
wherein the first node further comprises:
an account directory management unit that updates working shard information of the second receiver account with the latest information and stores it in an account directory ([0064] – [0065], referring to shard ownership and system users);
an account directory search unit that searches the account directory for the working shard information of the second receiver account when the working shard information of the second receiver account is requested from a third node that manages a second sender account that performs the second transaction ([0064], “Shards includes system shards and user shards. For example, system shards start with “sys.” The owner of the system shards is all the users of the entire system. According to the shard transaction rule, all users in the system shard can perform transactions to each other. In the system shard, user can transfer asset or send messages to another user without a fee.”); and
a working shard information transmission unit that transmits the searched working shard information of the second receiver account to the third node ([0081], “… a destination dApp owner creates a link approval transaction and broadcast (572) the transaction to the network.”).
As to Claim 4, Huang discloses: the inter-shard transaction system of claim 1, wherein the first node is a node that manages a third receiver account that performs a third transaction ([0040], “The transactions for different shards are then executed in parallel by different software threads of the same blockchain node software process.”), and
wherein the first node further comprises a transaction reception unit that when the third transaction is requested from a fourth node that manages a third sender account that performs the third transaction, receives and processes the requested third transaction ([0080], “A miner receives (510) the request and dispatches the request to the corresponding shard.”).
As to Claim 5, Huang discloses: the inter-shard transaction system of claim 1, wherein the working shard information request unit generates a working shard information request message requesting the working shard information of the first receiver account, and transmits the working shard information request message to communication target nodes based on an intra-shard communication node list and an inter-shard communication list through peer-to-peer communication to be received by the second node (Figs. 5A and 5B, showing flow charts illustrating methods of connecting shards and approving connection requests; and [0164], “… the machine 2100 may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.”), and
wherein the transaction transmission unit generates a transaction request message requesting the first transaction to the node that manages the first receiver account (Fig. 5A, item 510), and transmits the transaction request message to communication target nodes based on the intra-shard communication node list and the inter-shard communication list through peer-to-peer communication to be received by the node that manages the first receiver account ([0164], “… the machine 2100 may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.”).
As to Claim 6, Huang discloses: the inter-shard transaction system of claim 3, wherein the working shard information transmission unit generates a receiver account working shard information message including the working shard information of the second receiver account (Fig. 5A, item 510), and transmits the receiver account working shard information message to communication target nodes based on an intra-shard communication node list and an inter-shard communication list through peer-to-peer communication to be received by the third node ([0164], “… the machine 2100 may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.”).
As to Claim 7, Huang discloses: a method for inter-shard transaction in a blockchain network, which is implemented by at least one processor, on a first node that manages a first sender account that performs a first transaction, the method comprising: computing home shard information of a first receiver account that performs the first transaction based on information on an address of the first receiver account and information on a total number of shards ([0078], “A miner receives the request and dispatches (410) the request to corresponding shard. A sender pay (445) or receiver pay operation (450) is performed if the signature is valid (415) and the dApp name is valid (420) based on receiver pay support (425), policy compliance (430), and if fee is sufficient (435, 440).”);
requesting working shard information of the first receiver account to a second node that has a home shard of the first receiver account as a working shard ([0079], “The dApp run transaction is encapsulated into the proposed block and broadcast (460) to the network. A validator, e.g., miner, receives (465) the block and verifies all transactions.”);
receiving the working shard information of the first receiver account from the second node ([0080], “A miner receives (510) the request and dispatches the request to the corresponding shard.”); and
requesting the first transaction to a node that manages the first receiver account ([0081], “… a destination dApp owner creates a link approval transaction and broadcast (572) the transaction to the network.”).
As to Claim 8, Huang discloses: the inter-shard transaction method of claim 7, comprising searching whether the first receiver account is included in an account belonging to a working shard of the first sender account ([0064], “Shards includes system shards and user shards. For example, system shards start with “sys.” The owner of the system shards is all the users of the entire system. According to the shard transaction rule, all users in the system shard can perform transactions to each other. In the system shard, user can transfer asset or send messages to another user without a fee.”).
As to Claim 9, Huang discloses: the inter-shard transaction method of claim 7, wherein the working shard of the first node is a home shard of a second receiver account that performs a second transaction ([0040], “The transactions for different shards are then executed in parallel by different software threads of the same blockchain node software process.”), and wherein the method further comprises:
updating working shard information of the second receiver account with the latest information and storing it in an account directory ([0064] – [0065], referring to shard ownership and system users);
searching the account directory for the working shard information of the second receiver account when the working shard information of the second receiver account is requested from a third node that manages a second sender account that performs the second transaction ([0064], “Shards includes system shards and user shards. For example, system shards start with “sys.” The owner of the system shards is all the users of the entire system. According to the shard transaction rule, all users in the system shard can perform transactions to each other. In the system shard, user can transfer asset or send messages to another user without a fee.”); and
transmitting the searched working shard information of the second receiver account to the third node ([0081], “… a destination dApp owner creates a link approval transaction and broadcast (572) the transaction to the network.”).
As to Claim 10, Huang discloses: the inter-shard transaction method of claim 7, wherein the first node is a node that manages a third receiver account that performs a third transaction ([0040], “The transactions for different shards are then executed in parallel by different software threads of the same blockchain node software process.”), and
wherein the method further comprises, when the third transaction is requested from a fourth node that manages a third sender account that performs the third transaction, receiving and processing the requested third transaction ([0080], “A miner receives (510) the request and dispatches the request to the corresponding shard.”).
As to Claim 11, Huang discloses: the inter-shard transaction method of claim 7, wherein the requesting the working shard information of the first receiver account to the second node that has the home shard of the first receiver account as the working shard, includes generating a working shard information request message requesting the working shard information of the first receiver account, and transmitting the working shard information request message to communication target nodes based on an intra-shard communication node list and an inter-shard communication list through peer-to-peer communication to be received by the second node (Figs. 5A and 5B, showing flow charts illustrating methods of connecting shards and approving connection requests; and [0164], “… the machine 2100 may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.”), and
wherein the requesting the first transaction to the node that manages the first receiver account includes generating a transaction request message requesting the first transaction to the node that manages the first receiver account (Fig. 5A, item 510),, and transmitting the transaction request message to communication target nodes based on the intra-shard communication node list and the inter-shard communication list through peer-to-peer communication to be received by the node that manages the first receiver account ([0164], “… the machine 2100 may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.”).
As to Claim 12, Huang discloses: the inter-shard transaction method of claim 9, wherein the transmitting the searched working shard information of the second receiver account to the third node includes generating a receiver account working shard information message including the working shard information of the second receiver account (Fig. 5A, item 510), and transmitting the receiver account working shard information message to communication target nodes based on an intra-shard communication node list and an inter-shard communication list through peer-to-peer communication to be received by the third node ([0164], “… the machine 2100 may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.”).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NIRAV K KHAKHAR whose telephone number is (571)270-1004. The examiner can normally be reached Monday through Friday.
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, Tony Mahmoudi can be reached at (571) 272-4078. 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.
/NIRAV K KHAKHAR/Examiner, Art Unit 2163
/TONY MAHMOUDI/Supervisory Patent Examiner, Art Unit 2163
