Prosecution Insights
Last updated: April 19, 2026
Application No. 18/968,784

SMART CONTRACT DIRECTORY SERVICES

Non-Final OA §103
Filed
Dec 04, 2024
Examiner
MADAMBA, CLIFFORD B
Art Unit
3692
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Tokenform LLC
OA Round
1 (Non-Final)
43%
Grant Probability
Moderate
1-2
OA Rounds
3y 2m
To Grant
59%
With Interview

Examiner Intelligence

Grants 43% of resolved cases
43%
Career Allow Rate
278 granted / 640 resolved
-8.6% vs TC avg
Strong +15% interview lift
Without
With
+15.4%
Interview Lift
resolved cases with interview
Typical timeline
3y 2m
Avg Prosecution
40 currently pending
Career history
680
Total Applications
across all art units

Statute-Specific Performance

§101
40.0%
+0.0% vs TC avg
§103
36.2%
-3.8% vs TC avg
§102
4.5%
-35.5% vs TC avg
§112
15.8%
-24.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 640 resolved cases

Office Action

§103
DETAILED ACTION Status of Claims 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. This action is in reply to Application 18/968,874 filed on 4 December 2024. Claims 1-20 are currently pending and have been examined. Information Disclosure Statement The Information Disclosure Statement filed 15 December 2023 has been considered. An initialed copy of the Form 1449 is enclosed herewith. 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 of this title, 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. Claims 1-3, 5-6, 8-14, and 16-19 are rejected under U.S.C. 103 as being unpatentable over Lan et al., US 2023/0289782 A1 (“Lan”) in view of Dowling, US 11,816,453 B1 (“Dowling”). Claim 1: Lan discloses the system, comprising: a non-transitory storage medium that stores instructions; (FIG. 5A {30d: “Data Storage”}; [0005] “Embodiments of this disclosure provide a smart contract-based data processing method and … a computer-readable storage medium”; [0041] “Relevant information of these local contracts may be stored in a node memory 20d of the service node 20b, and may also be stored in other storage modules of the service node 20b”; [0174] “… computer program includes program instructions. When the processor executes the program instructions, the smart contract-based data processing method according to the foregoing embodiment of this disclosure can be performed”) a processor that executes the instructions to: [0174] “… computer program includes program instructions. When the processor executes the program instructions, the smart contract-based data processing method according to the foregoing embodiment of this disclosure can be performed”) generate a mapping between a first address at which a first smart contract references a second smart contract and a second address at which the second smart contract is stored on at least one blockchain; (FIG. 2A {“Obtain local contract 20Sb based on contract identifier 10c and a mapping relationship 201e”}; FIG. 3 {S101: “the service node storing a first mapping relationship between the first contract identifier and a second contract identifier”, S102: “Query, based on the first contract identifier and the first mapping relationship, the second contract identifier …”}; [0009] “… a first mapping relationship between a first contract identifier and a second contract identifier corresponding to the target local contract is set”; [0003] “In a blockchain system, a smart contract is a code that may be understood and executed by each node on a blockchain … The smart contract may be understood to be an executable program, while the blockchain may be understood to be an operating system that provides a program running environment”; [0004] “In the blockchain network, a service object may invoke smart contracts already deployed on the blockchain … All the smart contracts are deployed and run on consensus nodes in the blockchain network”) receive a request to execute the second smart contract at the first address in response to execution of the first smart contract; ([0007] “obtaining … a target contract invocation request for executing a transaction service. The target contract invocation request indicates that a service node in a service network executes a local service associated with the transaction service to obtain a local transaction execution result in response to an initial contract invocation request. The method further includes invoking a target chain contract based on a first contract identifier in the target contract invocation request to execute a consensus service associated with the transaction service to obtain a chain transaction execution result”; [0008] “The target contract invocation request causes the consensus node to invoke the target chain contract that executes a consensus service associated with the transaction service”; [0009] “In the embodiments of this disclosure, a target local contract is deployed on a service node in a service network independent of a core consensus network, and a first mapping relationship between a first contract identifier and a second contract identifier corresponding to the target local contract is set”) route the request to execute the second smart contract from the first address to the second address using the mapping; (FIG. 1 {“Routing Network 1-3”, “Routing Node 10D”}; [0031] “routing node 10D may be an independent physical server, a server cluster or a distributed system composed of a plurality of physical servers …”; [0043] “… service node 20b may forward the contract invocation request D to the consensus node … through a routing node in a routing network”; [0075] “… service node may forward the target contract invocation request to the consensus node through the routing node in the routing network”; [0138] The forwarding module 13 is further configured to transmit the target contract invocation request to the consensus node through a routing node in the routing network based on the local transaction execution result and the initial contract invocation request”; [0042] “For example, the mapping relationship between contract identifier 3c and contract identifier 1b indicates that chain contract 203c is associated with local contract 201b. The mapping relationship between contract identifier 20c and contract identifier 2b indicates that chain contract 220c is associated with local contract 202b”; [0043] “When receiving the contract invocation request B transmitted by the user terminal 20a, the service node 20b may query a contract identifier having the mapping relationship 201e with contract identifier 10c in the relationship mapping table 20e, may determine the queried contract identifier 5b as the second contract identifier, and may obtain local contract 205b based on contract identifier 5b. Next, the service node 20b may invoke local contract 205b to execute a local service indicated by the transaction service”) Regarding the limitation feature(s) comprising: change the mapping to map the first address to a third address in response to an authorized change request received via at least one communication network. Dowling, however, makes these teachings in a related endeavor (C5 L5-11: “the BAAPI system may monitor the blockchain platform of the deployed smart contract and, in response to determining that the address of a deployed smart contract has changed, automatically update the stored address for the smart contract in the BAAPI system. In this way, the BAAPI system always identifies the correct address of the contract …”; C7 L10-12: “the smart contract operations system 120 may interact with each other to perform various actions based on the user inputs”; C7 L42-52: “network listener circuits 110 may receive from the blockchain platform 124 an indication that the address of a deployed smart contract has changed and accordingly instruct the internal naming circuits 106 to update the 45 assigned name/address association”; C12 L20-23: “smart contract deployment circuits 300 may use the call name for the smart contract provided by the user to find the smart contract byte code associated with the call name in the byte code and metadata storage 206”; C14 L61-66: “an input from the user may identify a smart contract deployed on the blockchain platform 124 by its assigned name”; C15 L49-54: “modification management circuits 350 send a command to the smart contract deployment system 116 to deploy the smart contract modification byte code to the blockchain platform 124 on which the smart contract is deployed, so as to modify the terms of the deployed smart contract”; C16 L60-66: “smart contract operations circuits 400 start the process of performing a smart contract operation in response to receiving an input, instruction, command etc. from the user via the user interface 112. The input instructs the BAAPI computing system 101 to perform an operation defined in smart contract code of a deployed smart contract”; C18 L62-65: “smart contract address storage 208 and the smart contract naming directory 306 to determine the address of the deployed smart contract from the assigned name provided by the user”). 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 invention of Dowling to incorporate the teachings of Lan for the motivation of automatic execution of smart contracts in a faster manner upon fulfillment of a condition and/or receipt of an input or instruction from a user. Claim 2: Lan in view of Dowling discloses the system of claim 1. Lan further discloses: wherein the first smart contract is stored on the at least one blockchain. ([0003] “In a blockchain system, a smart contract is a code that may be understood and executed by each node on a blockchain … The smart contract may be understood to be an executable program, while the blockchain may be understood to be an operating system that provides a program running environment”; [0004] “In the blockchain network, a service object may invoke smart contracts already deployed on the blockchain … All the smart contracts are deployed and run on consensus nodes in the blockchain network”) Claim 3: Lan in view of Dowling discloses the system of claim 1. Lan further discloses: wherein the mapping comprises a third smart contract that references the second address. (FIG. 2A {“Obtain local contract 20Sb based on contract identifier 10c and a mapping relationship 201e”}; FIG. 3 {S101: “the service node storing a first mapping relationship between the first contract identifier and a second contract identifier”, S102: “Query, based on the first contract identifier and the first mapping relationship, the second contract identifier …”}; [0009] “… a first mapping relationship between a first contract identifier and a second contract identifier corresponding to the target local contract is set”) Claim 5: Lan in view of Dowling discloses the system of claim 1. Regarding the limitation feature comprising: wherein the second smart contract implements at least one of an application programming interface or a service. Dowling, however, makes these teachings in a related endeavor (C6 L12-13: “BAAPI computing system 101 includes smart contract management API circuits 102 …”). 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 invention of Dowling to incorporate the teachings of Lan for the motivation of automatic execution of smart contracts in a faster manner upon fulfillment of a condition and/or receipt of an input or instruction from a user. Claim 6: Lan in view of Dowling discloses the system of claim 1. Lan further discloses: wherein the first smart contract and the second smart contract are stored on different blockchains. ([0033] “A blockchain node system (namely, a second blockchain node system) corresponding to the core consensus network 1-2 shown in FIG. 1 may also include one or more blockchain nodes”) Claim 8: Lan in view of Dowling discloses the system of claim 1. Regarding the limitation feature comprising: wherein the first smart contract and the second smart contract are code compatible. Dowling, however, makes these teachings in a related endeavor (C5 L59-65: “BAAPI system is capable of interfacing with multiple blockchain platforms on the developer's behalf. As such, developers can send smart contracts to one source, BAAPI, and BAAPI can deploy the smart contracts onto various blockchain platforms. In doing so, BAAPI takes care of, for example, compiling the smart contract code such that the compiled code is compatible with the various blockchain platforms”). 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 invention of Dowling to incorporate the teachings of Lan for the motivation of automatic execution of smart contracts in a faster manner upon fulfillment of a condition and/or receipt of an input or instruction from a user. Claim 9: Claim 9, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 1. Accordingly, claim 9 is rejected in the same or substantially the same manner as claim 1. Claim 10: Claim 10, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 5. Accordingly, claim 10 is rejected in the same or substantially the same manner as claim 5. Claim 11: Lan in view of Dowling discloses the method of claim 9. Lan further discloses: instructing the directory service to update the second address of the directory service mapping to a third address. ([0025] “An invoke transaction is used for adding a record of a transaction in a blockchain by invoking a smart contract, and performing operations on a state database of the blockchain, including an update operation”; [0077] service node may also update relevant fields in the initial contract invocation request according to the local transaction execution result to obtain the target contract invocation request containing updated fields, and may then forward the target contract invocation request ( through the routing node or not) to the consensus node, so that the consensus node may invoke the target chain contract to parse the updated fields into updated request parameters”). Claim 12: Lan in view of Dowling discloses the method of claim 11. Regarding the limitation feature comprising: moving the second smart contract from the second address to the third address. Dowling, however, makes these teachings in a related endeavor (C5 L5-11: “the BAAPI system may monitor the blockchain platform of the deployed smart contract and, in response to determining that the address of a deployed smart contract has changed, automatically update the stored address for the smart contract in the BAAPI system. In this way, the BAAPI system always identifies the correct address of the contract …”; C7 L10-12: “the smart contract operations system 120 may interact with each other to perform various actions based on the user inputs”; C7 L42-52: “network listener circuits 110 may receive from the blockchain platform 124 an indication that the address of a deployed smart contract has changed and accordingly instruct the internal naming circuits 106 to update the 45 assigned name/address association”; C12 L20-23: “smart contract deployment circuits 300 may use the call name for the smart contract provided by the user to find the smart contract byte code associated with the call name in the byte code and metadata storage 206”; C14 L61-66: “an input from the user may identify a smart contract deployed on the blockchain platform 124 by its assigned name”; C15 L49-54: “modification management circuits 350 send a command to the smart contract deployment system 116 to deploy the smart contract modification byte code to the blockchain platform 124 on which the smart contract is deployed, so as to modify the terms of the deployed smart contract”; C16 L60-66: “smart contract operations circuits 400 start the process of performing a smart contract operation in response to receiving an input, instruction, command etc. from the user via the user interface 112. The input instructs the BAAPI computing system 101 to perform an operation defined in smart contract code of a deployed smart contract”; C18 L62-65: “smart contract address storage 208 and the smart contract naming directory 306 to determine the address of the deployed smart contract from the assigned name provided by the user”). 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 invention of Dowling to incorporate the teachings of Lan for the motivation of automatic execution of smart contracts in a faster manner upon fulfillment of a condition and/or receipt of an input or instruction from a user. Claim 13: Lan in view of Dowling discloses the method of claim 11. Lan further discloses: storing a third smart contract at the third address. ([0035] “blockchain system may include one or more smart contracts. These smart contracts may be differentiated by a contract identifier (for example, an identity document (ID) or a name, or a contract address … In the contract invocation request initiated by the client, the ID or name of the smart contract may also be carried, thereby specifying a smart contract required to be run by the blockchain”) Claim 14: Claim 14, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 3. Accordingly, claim 14 is rejected in the same or substantially the same manner as claim 3. Claim 16: Claim 16, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 8. Accordingly, claim 16 is rejected in the same or substantially the same manner as claim 8. Claim 17: Claim 17, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 1. Accordingly, claim 17 is rejected in the same or substantially the same manner as claim 1. Claim 18: Claim 18, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 11. Accordingly, claim 18 is rejected in the same or substantially the same manner as claim 11. Claim 19: Claim 19, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 11. Accordingly, claim 19 is rejected in the same or substantially the same manner as claim 11. Claims 4, 7, 15, and 20 are rejected under U.S.C. 103 as being unpatentable over Lan et al., US 2023/0289782 A1 (“Lan”) in view of Dowling, US 11,816,453 B1 (“Dowling”), as applied to claims 1-3, 5-6, 8-14, and 16-19 as described, further in view of Simu et al., US 2022/0210061 A1 (“Simu”). Claim 4: Lan in view of Dowling discloses the system of claim 1. Lan doesn’t explicitly disclose: wherein the mapping comprises at least one non-fungible token (NFT) or an asset associated with the at least one NFT. Simu, however, makes this teaching in a related endeavor ([0056]: “In some implementations, the digital instrument can be a non-fungible token (NFT), where a token ID of the NFT is a unique entry in a hash map that links … to the user's address on the blockchain”). 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 invention of Lan to incorporate the teachings of Simu for the motivation of facilitating access control of a digital content-related resource using a ledger. Claim 7: Claim 7, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 4. Accordingly, claim 7 is rejected in the same or substantially the same manner as claim 4. Claim 15: Claim 15, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 4. Accordingly, claim 15 is rejected in the same or substantially the same manner as claim 4. Claim 20: Claim 20, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 4. Accordingly, claim 20 is rejected in the same or substantially the same manner as claim 4. Conclusion The prior art(s) made of record and not relied upon is/are considered pertinent to applicant's disclosure. Feola et al. (US 12,184,758 B2) discloses a peer-to-peer (P2P) distributed data management system. A peer-to-peer (P2P) distributed data management system (DDMS) may operate as an operating system on which P2P distributed applications are utilized to manage data on distributed ledgers, such as blockchains. The DDMS may enable fast development of secure and scalable enterprise P2P distributed applications that support permanent control of every piece of data on a distributed ledger, synchronization, normalization of the data, and encryption of the data. Security of the data in the distributed ledger means that even if someone hacks into the distributed ledger, access is only gained to one block of data (e.g., single email) and not all blocks of data (e.g., entire email account). The DDMS may be integrated into Internet-of-Things (IoT) devices. The DDMS further automatically supports sequential smart contracts on the distributed ledger. Tedesco et al. (US 2022/0253866 A1) discloses systems and methods for monitoring services using smart contracts. Examples of the present disclosure describe systems and methods for monitoring services provided by a service provider to a consumer using a smart contract architecture. In one example, smart contract terms are provided to a DeFi application running on a blockchain, and a smart contract (e.g., a SLA smart contract) is constructed on the blockchain. Once the service provider begins providing service to the consumer, the system may monitor the service performance of the service. If the service performance dips below a certain agreed-upon threshold based on the smart contract, a trigger event may occur. Additionally, the analysis of the service performance data may indicate a service deficiency, wherein a remedial action is suggested to the service provider to be applied. The service deficiency and remedial action may be stored on the blockchain for future review. Claims 1-20 are rejected. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Clifford Madamba whose telephone number is 571-270-1239. The examiner can normally be reached on Mon-Thu 7:30-5:00 EST Alternate Fridays. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ryan Donlon, can be reached at 571-272-3602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /CLIFFORD B MADAMBA/Primary Examiner, Art Unit 3692
Read full office action

Prosecution Timeline

Dec 04, 2024
Application Filed
Nov 29, 2025
Non-Final Rejection — §103
Mar 05, 2026
Applicant Interview (Telephonic)
Mar 05, 2026
Examiner Interview Summary

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12597035
SYSTEMS AND METHODS FOR MERCHANT LEVEL FRAUD DETECTION BASED IN PART ON EVENT TIMING
2y 5m to grant Granted Apr 07, 2026
Patent 12591868
TICKETING VALIDATION AND FULFILLMENT SYSTEM AND METHOD
2y 5m to grant Granted Mar 31, 2026
Patent 12567054
SYSTEMS AND METHODS FOR EXECUTING ELECTRONIC TRANSACTIONS AND FILTERING WITH CATEGORIZATION ENGINE
2y 5m to grant Granted Mar 03, 2026
Patent 12567058
SYSTEMS AND METHODS FOR ISSUING PROCESSOR AGGREGATION
2y 5m to grant Granted Mar 03, 2026
Patent 12567055
METHOD FOR ORDERED EXECUTION OF CROSS-CHAIN TRANSACTIONS, AND CROSS-CHAIN SYSTEM
2y 5m to grant Granted Mar 03, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
43%
Grant Probability
59%
With Interview (+15.4%)
3y 2m
Median Time to Grant
Low
PTA Risk
Based on 640 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month