DETAILED ACTION
This final office action is in response to claims 1-20 filed on 03/16/2026 for examination. Claims 1-20 are being examined and are pending.
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 .
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.
Response to Amendment
The amendment filed March 16, 2016 has been entered. Claims 1-20 remain pending in the application. The claims have been amended. Applicant’s arguments and amendments to the claims are directed to the 35 U.S.C. 103 rejection(s) previously set forth in the Non-Final Office Action mailed February 4, 2026. Claims 1 and 18 have been amended and have necessitated a new ground(s) of rejection in this Office Action. Further, applicant’s arguments regarding claims 1-20 have been fully considered but are not persuasive to differentiate over the prior art. Particularly:
Applicant opines that the combination of Zhao et al. (NPL: “Blockchain based Privacy-Preserving Software Updates with Proof-of-Delivery for Internet of Things”; February 11, 2019) in view of Payeras-Capella et al. (NPL: “Blockchain-Based System for Multiparty Electronic Registered Delivery Services; August 2, 2019) and Chen et al. (CN110223064) fails to teach “sending, by the sender, […] an address of the transmission contract to a first transmission node of a transmission network, […] sending, by the first transmission node […] the address of the transmission contract to a second transmission node of the transmission network; […] receiving, by the second transmission node, […] the address of the transmission contract; sending, by the second transmission node, […] the address of the transmission contract to the receiver”. Remarks, pgs. 12-13. Applicant appears to argue that “Applicant has carefully reviewed Chen in its entirely and respectfully submits that Chen mentions “an address of a smart contract” only once, namely in paragraph [0035] of the description […]”. Remarks, pg. 13. Examiner notes that this is not the case in presently cited Chen (CN110223064B). In Chen, references to (and associated teachings for) the smart contract address appear throughout, e.g., in [0009], [0013-15], [0018-020], [0022], [0026], [0042-044], [0047-051], and [0054]. Additionally, Applicant appears to have approached Chen individually in lieu of the applied combination. See Remarks, pgs. 13-15 – discussing the transmission methods. In response to Applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). In the mapping, Zhao and Payeras-Capella are relied upon for the routed delivery of the ciphertext/update information – while Chen is relied upon for the teaching that a deployed smart contract has an address that is also provided to participating parties, and used to initiate transactions/query historical transaction information. See particularly as presented hereinbelow with regards to 35 U.S.C. 103. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the two-hop combination of Zhao and Payeras-Cappela with the teachings of Chen (as detailed hereinbelow) so the first transmission node, second transmission node, and receiver can find the transmission contract on the blockchain (see, e.g., Zhao at § 4.2; with Chen at [0040], [0004]). Applicant’s associated remarks are unpersuasive.
Additionally: Applicant opines Zhao teaches away from any combination because a goal of Zhao is reducing computation and processing burdens on the devices. Remarks, pgs. 15-16. However, Zhao’s resource-limited device discussions/processing reductions concern reducing complex attribute-based-signature computation – and has nothing to do with devices avoiding receiving receipts of address identifiers (and similarly, the devices participate in the protocols/processing/receive other associated routing/routed information such as the ciphertext, receiver address, etc.). See, e.g., Zhao at abstract, § 4.2 and 3.3; with Payeras-Capella at § VII and VIII. Accordingly, Applicant’s associated remarks are unpersuasive.
In view of the foregoing, as well as hereinbelow with regards to 35 U.S.C. 103, applicant’s arguments and amendments regarding claims 1-20 have been fully considered but are not persuasive to differentiate over the prior art.
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.
Claim(s) 1, 13, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhao et al. (NPL: “Blockchain based Privacy-Preserving Software Updates with Proof-of-Delivery for Internet of Things”; February 11, 2019; Hereinafter “Zhao”) in view of Payeras-Capella et al. (NPL: “Blockchain-Based System for Multiparty Electronic Registered Delivery Services; August 2, 2019; Hereinafter “Payeras-Capella”) and Chen et al. (CN110223064B; Hereinafter “Chen”).
Regarding claim 1, Zhao teaches an information transmission method based on blockchain (abstract), comprising:
creating, by a sender, a transmission contract on a blockchain (§ 4.2 – the vendor <i.e., sender> generates a smart contract <i.e., transmission contract> on a blockchain);
submitting, by the sender, a digest of to-be-transmitted information to the transmission contract (§ 4.2 – D_ID <i.e., digest> is generated by hashing D <i.e., to-be-transmitted information>, and then D_ID <i.e., digest> is added to the smart contract <i.e., transmission contract> by the vender <i.e., sender>); and
sending, by the sender, a ciphertext of the to-be-transmitted information (§ 4.2 – the vender <i.e., sender> generates C <i.e., ciphertext> by encrypting D <i.e., to-be-transmitted information>. The vendor <i.e., sender> sends the ciphertext C/associated information to the transmission node <i.e., first transmission node>), [[an address of a receiver and an address of the transmission contract to a first transmission node of a transmission network,]] wherein the sender is registered at the first transmission node of the transmission network (§ 4.2 – registration is created between vendor <i.e., sender> and the transmission node <i.e., first transmission node>, and the vendor <i.e., sender> is provided a public key pk_t of the transmission node <i.e., first transmission node>);
sending, by the first transmission node, the ciphertext of the to-be-transmitted information, [[the address of the receiver and the address of the transmission contract]] to a second transmission node of the transmission network in a point-to-point manner (§ 4.2 – the transmission node <i.e., first transmission node> receives the ciphertext C/associated information, and directly sends <i.e., in a point-to-point manner> the ciphertext C/associated information to the IoT gateway), wherein the receiver is registered at the second transmission node of the transmission network (§ 4.2 – registration is created between IoT device <i.e., receiver> and the IoT gateway <i.e., second transmission node>, and the IoT device <i.e., receiver> is provided a public key pk_t of the IoT gateway <i.e., second transmission node>); and
receiving, by the second transmission node, the ciphertext of the to-be-transmitted information [[and the address of the transmission contract]] (§ 4.2 – the transmission node <i.e., first transmission node> has the ciphertext C/associated information, and directly sends <i.e., in a point-to-point manner> the ciphertext C/associated information to the IoT gateway <i.e., second transmission node>. The IoT Gateway <i.e., second transmission node> receives the ciphertext C/associated information);
sending, by the second transmission node, the ciphertext of the to-be-transmitted information [[and the address of the transmission contract]] to the receiver (§ 4.2 – the transmission node <i.e., first transmission node> sends the ciphertext C/associated information to the IoT gateway <i.e., second transmission node>. The IoT Gateway <i.e., second transmission node> receives the ciphertext C/associated information. The IoT Gateway <i.e., second transmission node> sends the ciphertext C/associated information to the IoT Device <i.e., receiver>); and
generating, by the second transmission node, a receipt acknowledgement confirming that the ciphertext of the to-be-transmitted information [[and the address of the transmission contract]] have been received, and submitting, by the second transmission node, the receipt acknowledgement to the transmission contract (§ 4.2 – when ciphertext C/associated information is received and verified, a proof-of-delivery <i.e., receipt acknowledgement> is generated and submitted to the smart contract <i.e., transmission contract> and a receive transaction Tr is added to the blockchain).
While Zhao teaches the sender routing to-be-transmitted information from the sender to the receiver using an attribute requirement W (see, e.g., Zhao at § 4.2 and 3.3 – the vender <i.e., sender> indicates an attribute set W, and the system routes the update <i.e., to-be-transmitted information> to an IoT Device <i.e., receiver> with the qualifying attribute set W), Zhao appears to fail to specifically disclose (1) routing using to-be-transmitted information using an address of the receiver, and (2) explicitly sharing an address of the transmission contract to the first transmission node, second transmission node, and receiver.
However, Payeras-Capella teaches an analogous system producing proof-of-delivery receipts for to-be-transmitted information with transmission contracts (see, e.g., Payeras-Capella at abstract, § VII and VII) comprising: routing to-be-transmitted information to an intended receiver using an address of a receiver (§ VII and VIII – a receiver of the ciphertext is identified via an address. The address is forwarded with the encrypted message <i.e., ciphertext>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the two-hop system of Zhao with the teachings of Payeras-Capella, comprising: sending a ciphertext of the to-be-transmitted information and an address of a receiver to a first transmission node of a transmission network; and sending, by the first transmission node, the ciphertext of the to-be-transmitted information and the address of the receiver to a second transmission node of the transmission network in a point-to-point manner, so that a specific recipient can be targeted/routed to for an update by the sender (see, e.g., Zhao at § 4.2 and 3.3; with Payeras-Capella at VI and VII).
While the combination of Zhao and Payeras-Cappela teach the first transmission node, second transmission node, and receiver interacting with the transmission contract (see, e.g., Zhao at § 4.1-4.2 – the transmission node, IoT Gateway <i.e., second transmission node>, and the IoT Device <i.e., receiver> all interact with the smart contract <i.e., transmission contract>), the combination of Zhao and Payeras-Capella appears to fail to explicitly disclose forwarding an address of the transmission contract to the first transmission node, second transmission node, and receiver (so that they can find the transmission contract they interact with). Specifically: Zhao appears to fail to disclose sending a ciphertext of the to-be-transmitted information, an address of a receiver and an address of the transmission contract to a first transmission node of a transmission network, […] sending, by the first transmission node, the ciphertext of the to-be-transmitted information, the address of the receiver and the address of the transmission contract to a second transmission node of the transmission network in a point-to-point manner […] and receiving, by the second transmission node, the ciphertext of the to-be-transmitted information and the address of the transmission contract; sending, by the second transmission node, the ciphertext of the to-be-transmitted information and the address of the transmission contract to the receiver; and generating a receipt acknowledgement confirming that the ciphertext of the to-be-transmitted information and the address of the transmission contract have been received, and submitting the receipt acknowledgement to the transmission contract.
However, Chen teaches an analogous system for producing proof-of-delivery receipts for to-be-transmitted information with transmission contracts (see, e.g., Chen at [0040-0051]), comprising sharing an address of the transmission contract with all participants interacting with the transmission contract ([0040], [0004], and [0044-0051] – a smart contract is established for providing proof-of-delivery. The sender can share the smart contract <i.e., transmission contract> address with all participants, and the participants subsequently interact with the smart contract <i.e., transmission contract> to provide the proof-of-delivery).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the two-hop combination of Zhao and Payeras-Cappela with the teachings of Chen to forward an address of the transmission contract to the first transmission node, second transmission node, and receiver. Particularly comprising: sending a ciphertext of the to-be-transmitted information, an address of a receiver and an address of the transmission contract to a first transmission node of a transmission network, […] sending, by the first transmission node, the ciphertext of the to-be-transmitted information, the address of the receiver and the address of the transmission contract to a second transmission node of the transmission network in a point-to-point manner […] and receiving, by the second transmission node, the ciphertext of the to-be-transmitted information and the address of the transmission contract; sending, by the second transmission node, the ciphertext of the to-be-transmitted information and the address of the transmission contract to the receiver; and generating a receipt acknowledgement confirming that the ciphertext of the to-be-transmitted information and the address of the transmission contract have been received, and submitting the receipt acknowledgement to the transmission contract, so the first transmission node, second transmission node, and receiver can find the transmission contract on the blockchain (see, e.g., Zhao at § 4.2; with Chen at [0040], [0004]).
Regarding claim 13, the combination of Zhao, Payeras-Capella, and Chen teach the information transmission method of claim 1, wherein the transmission network comprises an auditing protocol (Zhao at § 2.1 and 4.2 – the transmission network is a blockchain network wherein the vendors and transmission nodes act as miners to verify all transactions in the network <i.e., an auditing protocol>. Further, the smart contract <i.e., transmission contract> is used to verify submitted delivery proofs before releasing incentive funds; see additionally, e.g., Payeras-Capella at § IX – third parties may verify <i.e., audit> the transactions on the blockchain to ensure proper execution, and Chen at [0019], [0021], [0024], and [0027-029] – if the nodes in the transmission network are not following the protocol, the protocol is determined to fail and the deposits are returned to the non-offending party); and
the information transmission method further comprises: auditing transmission behavior of each of the at least two transmission nodes based on the auditing protocol using on-chain data and data of the transmission contract (Zhao at § 4.2 – smart contract/state data and submitted on-chain proofs OABS and DAPS are used to determine whether to release incentive funds; see additionally, e.g., Payeras-Capella at § IX – third parties may verify <i.e., audit> the transactions on the blockchain to ensure proper execution, and Chen at [0019], [0021], [0024], and [0027-029] – if the nodes in the transmission network are not following the protocol, the protocol is determined to fail and the deposits are returned to the non-offending party); and
when evidence is found that a transmission node does not perform transmission according to a predetermined sending and receiving protocol, removing the transmission node from the transmission network or punishing the transmission node (Zhao at § 2.1 and 4.2 – the transmission network is a blockchain network wherein the vendors and transmission nodes act as miners to verify all transactions in the network <i.e., an auditing protocol>. Further, the smart contract <i.e., transmission contract> is used to verify submitted delivery proofs before releasing incentive funds. If the transmission node does not act according to the protocol <e.g., does not submit the DAPS proof>, the miners cannot verify <i.e., evidence found>, and the funds are not released/withdrawn to the vendor <i.e., punishing the transmission node>; see additionally, e.g., Chen at [0019], [0021], [0024], and [0027-029] – if the nodes in the transmission network are not following the protocol, the protocol is determined to fail and the deposits are returned to the non-offending party <i.e., punishes>).
Regarding claim 19, the combination of Zhao, Payeras-Capella, and Chen teach an information transmission device based on blockchain, comprising: at least one processor; and a memory in communication connection to the at least one processor; wherein the memory is configured to store an instruction executable by the at least one processor, and the instruction is configured to be executed by the at least one processor (Zhao at § 4.2 and 5.2 – system is implemented by computers executing stored instructions/protocols) to perform the information transmission method of claim 1 (see hereinabove with regards to claim 1).
Regarding claim 20, the combination of Zhao, Payeras-Capella, and Chen teach a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium is configured to store a program, and the program is configured to be executed by a multi-core processor to perform the information transmission method of claim 1 (see hereinabove with regards to claim 1, as well as Zhao at § 4.2 and 5.2 – system is implemented by computers executing stored instructions/protocols).
Regarding claim 18, Zhao teaches an information transmission system (abstract) comprising: a sender; a receiver; a transmission network; and a blockchain; (§ 4.2 – system implemented via senders/receivers/network/blockchain)
wherein the sender is configured to create a transmission contract on the blockchain (§ 4.2 – the vendor <i.e., sender> generates a smart contract <i.e., transmission contract> on a blockchain), submit a digest of to-be-transmitted information to the transmission contract (§ 4.2 – D_ID <i.e., digest> is generated by hashing D <i.e., to-be-transmitted information>, and then D_ID <i.e., digest> is added to the smart contract <i.e., transmission contract>), and send a ciphertext of the to-be-transmitted information (§ 4.2 – the vender <i.e., sender> generates C <i.e., ciphertext> by encrypting D <i.e., to-be-transmitted information>. The vendor <i.e., sender> sends the ciphertext C/associated information to the transmission node <i.e., first transmission node>), [[an address of the receiver and an address of the transmission contract to a first transmission node of the transmission network,]] wherein the sender is configured to be registered at the first transmission node of the transmission network (§ 4.2 – registration is created between vendor <i.e., sender> and the transmission node <i.e., first transmission node>, and the vendor <i.e., sender> is provided a public key pk_t of the transmission node <i.e., first transmission node>);
the first transmission node is configured to send the ciphertext of the to-be-transmitted information, [[the address of the receiver and the address of the transmission contract]] to a second transmission node of the transmission network in a point to point manner (§ 4.2 – the transmission node <i.e., first transmission node> receives the ciphertext C/associated information, and directly sends <i.e., in a point-to-point manner> the ciphertext C/associated information to the IoT gateway), wherein the receiver is configured to be registered at the second transmission node of the transmission network (§ 4.2 – registration is created between IoT device <i.e., receiver> and the IoT gateway <i.e., second transmission node>, and the IoT device <i.e., receiver> is provided a public key pk_t of the IoT gateway <i.e., second transmission node>); and
the second transmission node is configured to receive the ciphertext of the to-be-transmitted information [[and the address of the transmission contract]] (§ 4.2 – the transmission node <i.e., first transmission node> has the ciphertext C/associated information, and directly sends <i.e., in a point-to-point manner> the ciphertext C/associated information to the IoT gateway <i.e., second transmission node>. The IoT Gateway <i.e., second transmission node> receives the ciphertext C/associated information), and send the ciphertext of the to-be-transmitted information [[and the address of the transmission contract]] to the receiver (§ 4.2 – the transmission node <i.e., first transmission node> sends the ciphertext C/associated information to the IoT gateway <i.e., second transmission node>. The IoT Gateway <i.e., second transmission node> receives the ciphertext C/associated information. The IoT Gateway <i.e., second transmission node> sends the ciphertext C/associated information to the IoT Device <i.e., receiver>), and generate a receipt acknowledgement and submit the receipt acknowledgement to the transmission contract (§ 4.2 – when ciphertext C/associated information is received and verified, a proof-of-delivery <i.e., receipt acknowledgement> is generated and submitted to the smart contract <i.e., transmission contract> and a receive transaction Tr is added to the blockchain).
While Zhao teaches the sender routing to-be-transmitted information from the sender to the receiver using an attribute requirement W (see, e.g., Zhao at § 4.2 and 3.3 – the vender <i.e., sender> indicates an attribute set W, and the system routes the update <i.e., to-be-transmitted information> to an IoT Device <i.e., receiver> with the qualifying attribute set W), Zhao appears to fail to specifically disclose (1) routing using to-be-transmitted information using an address of the receiver, and (2) explicitly sharing an address of the transmission contract to the first transmission node, second transmission node, and receiver.
However, Payeras-Capella teaches an analogous system producing proof-of-delivery receipts for to-be-transmitted information with transmission contracts (see, e.g., Payeras-Capella at abstract, § VII and VII) comprising: routing to-be-transmitted information to an intended receiver using an address of a receiver (§ VII and VIII – a receiver of the ciphertext is identified via an address. The address is forwarded with the encrypted message <i.e., ciphertext>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the two-hop system of Zhao with the teachings of Payeras-Capella, comprising: sending a ciphertext of the to-be-transmitted information and an address of a receiver to a first transmission node of a transmission network; and sending, by the first transmission node, the ciphertext of the to-be-transmitted information and the address of the receiver to a second transmission node of the transmission network in a point-to-point manner, so that a specific recipient can be targeted/routed to for an update by the sender (see, e.g., Zhao at § 4.2 and 3.3; with Payeras-Capella at VI and VII).
While the combination of Zhao and Payeras-Cappela teach the first transmission node, second transmission node, and receiver interacting with the transmission contract (see, e.g., Zhao at § 4.1-4.2 – the transmission node, IoT Gateway <i.e., second transmission node>, and the IoT Device <i.e., receiver> all interact with the smart contract <i.e., transmission contract>), the combination of Zhao and Payeras-Capella appears to fail to explicitly disclose forwarding an address of the transmission contract to the first transmission node, second transmission node, and receiver (so that they can find the transmission contract they interact with). Specifically: Zhao appears to fail to disclose sending a ciphertext of the to-be-transmitted information, an address of a receiver and an address of the transmission contract to a first transmission node of a transmission network, […] sending, by the first transmission node, the ciphertext of the to-be-transmitted information, the address of the receiver and the address of the transmission contract to a second transmission node of the transmission network in a point-to-point manner […] and receiving, by the second transmission node, the ciphertext of the to-be-transmitted information and the address of the transmission contract; sending, by the second transmission node, the ciphertext of the to-be-transmitted information and the address of the transmission contract to the receiver; and generating a receipt acknowledgement confirming that the ciphertext of the to-be-transmitted information and the address of the transmission contract have been received, and submitting the receipt acknowledgement to the transmission contract.
However, Chen teaches an analogous system for producing proof-of-delivery receipts for to-be-transmitted information with transmission contracts (see, e.g., Chen at [0040-0051]), comprising sharing an address of the transmission contract with all participants interacting with the transmission contract ([0040], [0004], and [0044-0051] – a smart contract is established for providing proof-of-delivery. The sender can share the smart contract <i.e., transmission contract> address with all participants, and the participants subsequently interact with the smart contract <i.e., transmission contract> to provide the proof-of-delivery).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the two-hop combination of Zhao and Payeras-Cappela with the teachings of Chen to forward an address of the transmission contract to the first transmission node, second transmission node, and receiver. Particularly comprising: sending a ciphertext of the to-be-transmitted information, an address of a receiver and an address of the transmission contract to a first transmission node of a transmission network, […] sending, by the first transmission node, the ciphertext of the to-be-transmitted information, the address of the receiver and the address of the transmission contract to a second transmission node of the transmission network in a point-to-point manner […] and receiving, by the second transmission node, the ciphertext of the to-be-transmitted information and the address of the transmission contract; and sending, by the second transmission node, the ciphertext of the to-be-transmitted information and the address of the transmission contract to the received, and submitting the receipt acknowledgement to the transmission contract, so the first transmission node, second transmission node, and receiver can find the transmission contract on the blockchain (see, e.g., Zhao at § 4.2; with Chen at [0040], [0004]).
Allowable Subject Matter
Claim(s) 2-12 and 14-16 is/are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. The following is an examiner’s statement of reasons for allowance (in accordance with MPEP 1302.14): The primary reason for allowance of the foregoing claims in the inclusion of a limitation in the independent claim which is not found in prior art references. Specifically: Claim 2 recites: wherein when or after the first transmission node sends the ciphertext of the to-be-transmitted information, the address of the receiver and the address of the transmission contract to the second transmission node in a point-to-point manner, the information transmission method further comprises: generating a sending acknowledgement confirming that the ciphertext of the to-be-transmitted information, the address of the receiver and the address of the transmission contract have been sent, and submitting the sending acknowledgement to the transmission contract; and the transmission contract further comprises a predetermined token distribution rule and tokens submitted by the sender and/or the receiver, and is configured to distribute the tokens to one or more of the first transmission node, the second transmission node and the receiver based on the predetermined token distribution rule and data submitted to the transmission contract.” Claim 3 recites wherein the sender is provided with a sender public key and a sender private key obtained based on an asymmetric encryption algorithm; and an address of the sender is identified by using the sender public key or a digest of the sender public key, the receiver is provided with a receiver public key and a receiver private key obtained based on the asymmetric encryption algorithm; and the address of the receiver is identified by using the receiver public key or a digest of the sender public key, and the transmission network comprises at least two transmission nodes comprising the first transmission node and the second transmission node, wherein each of the at least two transmission nodes has a transmission node public key and a transmission node private key obtained based on the asymmetric encryption algorithm; and a node address of each of the at least two transmission nodes is identified by using the transmission node public key or a digest of transmission node public key; wherein the address of the sender, the address of receiver and the address of each of the at least two transmission nodes are publicly available on the blockchain. Claim 14 recites managing transmission nodes in the transmission network by using one or more of the following rules: removing a transmission node that does not meet service requirements from the transmission network; punishing a transmission node with misbehavior; permitting an ordinary node that satisfies candidate conditions to be a candidate node in the transmission network; and permitting a candidate node that satisfies election conditions to be a transmission node in the transmission network; wherein the step of removing a transmission node that does not meet service requirements from the transmission network further comprises: when any one or more of the transmission nodes of the transmission network are detected to fail to perform an information transmission action as required within a specified time period, removing the any one or more transmission nodes from the transmission network.
The combination of Zhao, Payeras-Cappella, and Chen fail to disclose the aforementioned subject matter of claims 2, 3, and 14. Art made of record, e.g., Karame et al. (US20180097779) teaches a blockchain-based data forwarding service where network nodes exchange acknowledgements recorded in a smart contract, and further distributing associated rewards (see, e.g., Karame at abstract, [0006], and [00017]), yet fails to remedy the aforementioned deficiency. Li et al. (NPL: “SilentDelivery: Practical Timed-delivery of Private Information using Smart Contracts; July 19, 2021) teaches a blockchain protocol for proof-of-delivery using smart contracts (see, e.g., Li at abstract, § 4), yet similarly fails to remedy the aforementioned deficiency. Allen et al. (US20210360049) teaches a decentralized peer-to-peer streaming and content delivery network that uses blockchain and smart contracts to register nodes and reward them with tokens (see, e.g., Allen at abstract, [0008-012]), yet similarly fails to remedy the aforementioned deficiency. Fang (US20210217098) teaches a blockchain messaging system that logs acknowledgement on-chain via smart contracts (see, e.g., Fang at abstract, [0008], and [0041-045]), yet similarly fails to remedy the aforementioned deficiency. Qiu (US20200004788) teaches a system for recording a hash of off-chain data in a blockchain smart contract to verify external information without storing an on-chain full payload (see, e.g., Qiu at abstract, [0004-011]), yet fails to remedy the aforementioned deficiency.
None of the prior art of record, either taken by itself or in any combination, would have anticipated or made obvious all features of the invention of the present application claim(s) 2, 3, and 14 at or before the time it was filed. Dependent claims 10-11 (of claim 2), 4-9 and 12 (of claim 3), and 15-17 (of claim 14) incorporate the limitations of their parent claim, and are objected to for at least the same rationale.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA RAYMOND WHITE whose telephone number is (571)272-4365. The examiner can normally be reached Monday-Thursday, & Alternate Fridays.
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, Taghi Arani can be reached at 5712723787. 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.R.W./Examiner, Art Unit 2438 /TAGHI T ARANI/Supervisory Patent Examiner, Art Unit 2438
Prosecution Insights