DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to the application filed October 24, 2023.
Claims 1-20 are pending.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “transaction monitor” and “generative artificial intelligence system” in claim 18.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 (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 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, 16-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over “Zhang” (US PG Pub 2020/0278958) in view of “Anderson” (US PG Pub 2019/0034404).
Regarding Claim 1, Zhang teaches:
1. A method for generating a bridge to facilitate transactions between a first blockchain and a second blockchain, the method comprising: monitoring transactions on a first blockchain and a second blockchain; (Zhang See e.g. Fig. 7, ¶50 describing receiving transaction payload for a blockchain transaction and further see e.g. 204, 205 Fig. 2 ¶44 teaches first and second blockchains for receiving transactions)
classifying the monitored transactions into one or more transaction types; (Zhang Each transaction in Fig. 7, -¶¶50-52 is classified as a native or cross-chain transaction type)
for each classified transaction type of the one or more transaction types:
a smart contract defining a bridge to link the first blockchain with the second blockchain based on the classified transaction type; (Zhang See e.g. Smart Contracts Fig. 4, ¶¶47,55 defining the smart contract for the bridge in the cross-chain bridge between blockchains e.g. A and B of Fig. 2)
and deploying the smart contract defining the bridge. (Zhang See Smart Contracts of Fig. 4 as part of the cross-chain bridge, configured for a bridge instance as in Fig. 9, ¶52 for using in bridging for cross-chain transactions).
Zhang does not teach, but Anderson teaches:
generating, with a generative artificial intelligence model, (Anderson 314, Fig 3, ¶¶29-30 teaches a cognitive blockchain mediator which generates and deploys a requested smart contract to the block chain, where the mediator includes a machine learning component).
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Anderson as each is directed to blockchain smart contract deployment systems and Anderson recognized the need for a system that “leverages NLP and other cognitive technologies to capture natural interaction between parties, extract relevant features from the interactions, identify the most relevant smart contract template, and dynamically modify a draft smart contract, based on the identified template, to match the needs of the parties.” (¶16).
Regarding Claim 16, Zhang teaches:
16. A system comprising:
a processor; (See processors ¶69 of Zhang)
memory (See Zhang e.g. hardware of ¶67, nodes of ¶52 etc) storing instructions which, when executed by the processor, cause the system to: monitor transactions on a first blockchain and a second blockchain; (Zhang See e.g. Fig. 7, ¶50 describing receiving transaction payload for a blockchain transaction and further see e.g. 204, 205 Fig. 2 ¶44 teaches first and second blockchains for receiving transactions)
classify the monitored transactions into one or more transaction types; (Zhang -¶¶50-52, 63 Each transaction in Fig. 7 is classified as a native or cross-chain transaction type)
for each classified transaction type of the one or more transaction types: a smart contract defining a bridge to link the first blockchain with the second blockchain based on the classified transaction type; (See Zhang e.g. Smart Contracts Fig. 4, ¶¶47,55 defining the smart contract for the bridge in the cross-chain bridge between blockchains e.g. A and B of Fig. 2)
and deploy the smart contract defining the bridge. (Zhang See Smart Contracts of Fig. 4 as part of the cross-chain bridge, configured for a bridge instance as in Fig. 9, ¶52 for using in bridging for cross-chain transactions).
Zhang does not teach, but Anderson teaches:
generate, with a generative artificial intelligence model, (Anderson 314, Fig 3, ¶¶29-30 teaches a cognitive blockchain mediator which generates and deploys a requested smart contract to the block chain, where the mediator includes a machine learning component).
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Anderson as each is directed to blockchain smart contract deployment systems and Anderson recognized the need for a system that “leverages NLP and other cognitive technologies to capture natural interaction between parties, extract relevant features from the interactions, identify the most relevant smart contract template, and dynamically modify a draft smart contract, based on the identified template, to match the needs of the parties.” (¶16).
Regarding Claim 18, Zhang teaches:
18. A cross-chain bridge creation and management system comprising: a transaction monitor configured to:
monitor transactions on a first blockchain and a second blockchain; and (Zhang See e.g. Fig. 7, ¶50 describing receiving transaction payload for a blockchain transaction and further see e.g. 204, 205 Fig. 2 ¶44 teaches first and second blockchains for receiving transactions)
classify the monitored transactions by transaction type; (Zhang -¶¶50-52, 63 Each transaction in Fig. 7 is classified as a native or cross-chain transaction type)
a smart contract defining a bridge to link the first blockchain and the second blockchain based on the transaction type. (See e.g. Smart Contracts Fig. 4, ¶¶47,55 defining the smart contract for the bridge in the cross-chain bridge between blockchains e.g. A and B of Fig. 2)
Zhang does not teach, but Anderson teaches:
and a generative artificial intelligence system configured to generate (Anderson 314, Fig 3, ¶¶29-30 teaches a cognitive blockchain mediator which generates and deploys a requested smart contract to the block chain, where the mediator includes a machine learning component).
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Anderson as each is directed to blockchain smart contract deployment systems and Anderson recognized the need for a system that “leverages NLP and other cognitive technologies to capture natural interaction between parties, extract relevant features from the interactions, identify the most relevant smart contract template, and dynamically modify a draft smart contract, based on the identified template, to match the needs of the parties.” (¶16).
Regarding Claim 17, Zhang further teaches:
17. The system of claim 16, wherein the instructions further cause the system to store a bridge digital asset associated with the smart contract defining the bridge. (See e.g. Fig. 6, ¶49 of Zhang describing storing a bridge registry identifying the bridges, which include the smart contracts on the blockchain to carryout the cross-chain bridge technique)
Regarding Claim 20, Zhang does not further teach, but Anderson teaches:
20. The cross-chain bridge creation and management system of claim 18, wherein the generative artificial intelligence system includes:a language model configured to generate a smart contract logic description based on the classified transaction type; (Anderson e.g. cognitive blockchain mediator 116 as in ¶¶23-33 describes first processing a natural language request into structure features of the request to be analyzed in comparison to available smart contract templates) and a generative artificial intelligence model configured to generate smart contract code based on the smart contract logic description output by the language model. (Anderson e.g. cognitive blockchain mediator 116 as in ¶¶23-33 describes drafting the smart contract code based on analyzing request features and available contract templates to create and implement the requested smart contract on the block chain). In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Anderson as each is directed to blockchain smart contract deployment systems and Anderson recognized the need for a system that “leverages NLP and other cognitive technologies to capture natural interaction between parties, extract relevant features from the interactions, identify the most relevant smart contract template, and dynamically modify a draft smart contract, based on the identified template, to match the needs of the parties.” (¶16).
Claim(s) 2,3,8, 11-15 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Zhang” (US PG Pub 2020/0278958) in view of “Anderson” (US PG Pub 2019/0034404) as applied above and further in view of “Padmanabhan” (US PG Pub 2019/0236598).
Regarding Claim 2, Zhang et a do not further teach, but Padmanabhan teaches:
2. The method of claim 1, a second artificial intelligence system is used to monitor the transactions on the first blockchain and the second blockchain. (See Padmanabhan ¶¶432, 456 describing a machine learning platform for observing and processing blockchain transactions including processing by transaction type for respective smart contracts). In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Padmanabhan as each is directed to blockchain smart contract deployment systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment as is described herein.” (¶9).
Regarding Claim 3, Zhang et a do not further teach, but Padmanabhan teaches:
3. The method of claim 1, wherein a model is used to classify the monitored transactions into the one or more transaction types. (See Padmanabhan ¶¶432, 456 describing a machine learning platform for observing and processing blockchain transactions including processing by transaction type for respective smart contracts). In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Padmanabhan as each is directed to blockchain smart contract deployment systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment as is described herein.” (¶9).
Regarding Claim 8, Zhang et a do not further teach, but Padmanabhan teaches:
8. The method of claim 1, wherein parameters used by the generative artificial intelligence model to generate the smart contract are encrypted and stored in a secured database. (Padmanabhan e.g. ¶373 describes the machine learning platform used for implementing smart contracts on the block chain is highly encrypted on a IPFS/Distributed ledger file system as encrypted JSON.)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Padmanabhan as each is directed to blockchain smart contract deployment systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment as is described herein.” (¶9).
Regarding Claim 11, Zhang et a do not further teach, but Padmanabhan teaches:
11. The method of claim 1, the method further comprising:determining the bridge should be cloned based on monitored transactions with the first blockchain and the second blockchain; (Padmanabhan ¶¶257-258 describes copying smart contracts to distributed block chain nodes to carry out blockchain transaction processing in the distributed nodes). and cloning the smart contract defining the bridge to generate a cloned smart contract defining a cloned bridge. (Padmanabhan ¶¶257-258 describes copying smart contracts to distributed block chain nodes to carry out blockchain transaction processing in the distributed nodes).
Regarding Claim 12, Zhang et a do not further teach, but Padmanabhan teaches:
12. The method of claim 11, wherein determining the bridge should be cloned occurs in response to receipt of a request to clone the bridge. (Padmanabhan ¶¶247-249 teaches the system receiving request for provision of blockchain services, such as the cloned contracts of ¶¶257-258). In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Padmanabhan as each is directed to blockchain smart contract deployment systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment as is described herein.” (¶9).
Regarding Claim 13, Zhang et a do not further teach, but Padmanabhan teaches:
13. The method of claim 12, wherein the request to clone the bridge is sent based on a smart contract condition being met. (Padmanabhan ¶¶257-258 describes copying smart contracts to distributed block chain nodes to carry out blockchain transaction processing in the distributed nodes). In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Padmanabhan as each is directed to blockchain smart contract deployment systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment as is described herein.” (¶9).
Regarding Claim 14, Zhang et a do not further teach, but Padmanabhan teaches:
14. The method of claim 11, wherein the cloned smart contract defining the cloned bridge includes a copy of the smart contract defining the bridge with modified parameters based on a context of an environment in which the cloned smart contract is to be deployed. (Padmanabhan ¶¶257-258 describes copying smart contracts to distributed block chain nodes to carry out blockchain transaction processing in the distributed nodes; further inherent in the discussion of ¶114 of configuration parameters for deployed smart contracts would be that parameters would be adjusted as needed for deployment of copied smart contracts). In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Padmanabhan as each is directed to blockchain smart contract deployment systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment as is described herein.” (¶9).
Regarding Claim 15, Zhang et a do not further teach, but Padmanabhan teaches:
15. The method of claim 1, wherein the smart contract defining the bridge is generated on-demand based on the monitored transactions with the first blockchain and the second blockchain. (Padmanabhan e.g. ¶¶289,372 describe on-demand deployment of services including the transaction-processing smart contracts described previously) In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Padmanabhan as each is directed to blockchain smart contract deployment systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment as is described herein.” (¶9).
Regarding Claim 19, Zhang et a do not further teach, but Padmanabhan teaches:
19. The cross-chain bridge creation and management system of claim 18, wherein the transaction monitor includes a deep learning model designed to consume the monitored transactions and classify the monitored transactions into groups corresponding to transaction types. (See Padmanabhan ¶¶432, 456 describing a machine learning platform for observing and processing blockchain transactions including processing by transaction type for respective smart contracts). In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Padmanabhan as each is directed to blockchain smart contract deployment systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment as is described herein.” (¶9).
Claim(s) 4-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Zhang” (US PG Pub 2020/0278958) in view of “Anderson” (US PG Pub 2019/0034404) as applied above and further in view of “Padmanabhan” (US PG Pub 2019/0236598) and “Rodler” (US PG Pub 2022/0318399).
Regarding Claim 4, Zhang et a do not further teach, but Padmanabhan teaches:
4. The method of claim 1 further comprising: monitoring interactions with the smart contract defining the bridge;(See e.g. Padmanabhan ¶432,456 describing monitoring the transactions processed in the smart contracts of the bridge as part of the machine learning platform) In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Padmanabhan as each is directed to blockchain smart contract deployment systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment as is described herein.” (¶9).
Zhang et al further do not teach, but Rodler teaches:
detecting an issue in the monitored interactions; (See Rodler ¶43, Fig. 1, teaches detect vulnerabilities in the smart contract) and sending a request to destroy the smart contract defining the bridge upon detecting the issue. (Rodler teaches rewriting of vulnerable smart contracts as in fig. 1 but also teaches destruction of some smart contracts as needed for vulnerabilities, unuse etc in e.g. ¶137). In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Rodler as each is directed to blockchain smart contract deployment systems and Rodler recognized a need for deletion, re-writing, repair tools for smart contracts as “several recent attacks exploited errors in smart contract code and had devastating consequences thereby questioning the benefits of this technology.” (¶20).
Regarding Claim 5, Zhang et a do not further teach, but Padmanabhan teaches:
5. The method of claim 4, wherein the request to destroy the smart contract defining the bridge is sent to an artificial intelligence system which is configured to destroy the smart contract. (See e.g. Padmanabhan ¶432,456 describing monitoring the transactions processed in the smart contracts of the bridge as part of the machine learning platform including managing the smart contracts for security etc) In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Padmanabhan as each is directed to blockchain smart contract deployment systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment as is described herein.” (¶9).
Regarding Claim 6, Zhang et a do not further teach, but Padmanabhan teaches:
6. The method of claim 4, wherein the monitored interactions with the smart contract defining the bridge are monitored with an artificial intelligence system trained to detect security threats for deployed bridges. (See e.g. Padmanabhan ¶432,456 describing monitoring the transactions processed in the smart contracts of the bridge as part of the machine learning platform including managing the smart contracts for security etc) In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Padmanabhan as each is directed to blockchain smart contract deployment systems and Padmanabhan recognized “present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon distributed ledger technologies and providing such capabilities via an on-demand cloud based computing environment as is described herein.” (¶9).
Claim(s) 7,9,10 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Zhang” (US PG Pub 2020/0278958) in view of “Anderson” (US PG Pub 2019/0034404) as applied above and further in view of “Iftemi” (US PG Pub 2021/013603).
Regarding Claim 7, Zhang et a do not further teach, but Iftemi teaches:
7. The method of claim 1, wherein the smart contract defining the bridge is destroyed in response to determining that the bridge is no longer being used. (Iftemi ¶¶199-206 teaches a smart contract management system that allows enable/disable or permanently deleting a smart contract in the system, which inherently allows for temporary disabling or permanent destruction of the smart contract based on e.g. security vulnerabilities or non-use)
Regarding Claim 9, Zhang et a do not further teach, but Anderson teaches:
9. The method of claim 1, retrieving parameters used by the generative artificial intelligence model to generate the destroyed smart contract; (Anderson e.g. cognitive blockchain mediator 116 as in ¶¶23-33 describes first processing a natural language request into structure features of the request to be analyzed in comparison to available smart contract templates)
and generating the smart contract defining the bridge using the retrieved parameters with the generative artificial intelligence model. (Anderson e.g. cognitive blockchain mediator 116 as in ¶¶23-33 describes drafting the smart contract code based on analyzing request features and available contract templates to create and implement the requested smart contract on the block chain). In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Anderson as each is directed to blockchain smart contract deployment systems and Anderson recognized the need for a system that “leverages NLP and other cognitive technologies to capture natural interaction between parties, extract relevant features from the interactions, identify the most relevant smart contract template, and dynamically modify a draft smart contract, based on the identified template, to match the needs of the parties.” (¶16).
Zhang et a do not further teach, but Iftemi teaches:
wherein generating the smart contract defining the bridge further comprises:determining that the classified transaction type corresponds to a transaction type of a destroyed smart contract defining a destroyed bridge; (Iftemi ¶¶199-206 teaches a smart contract management system that allows enable/disable or permanently deleting a smart contract in the system, which inherently allows for temporary disabling or permanent destruction of the smart contract based on e.g. security vulnerabilities or non-use, and includes a history with the parameters of historic smart contracts such as those destroyed) In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Iftemi as each is directed to blockchain smart contract deployment systems and Iftemi recognized “blockchain technology that underlies the Bitcoin application has become extremely appetizing, and it has been proven that the benefits it offers can also be used at in industrial software applications.” (¶10).
Regarding Claim 10, Zhang et al does not teach, but Iftemi teaches:
10. The method of claim 9, wherein the parameters are not retrieved or used when it is determined that the destroyed smart contract was destroyed due to a detected security issue. (Iftemi ¶¶199-206 teaches a smart contract management system that allows enable/disable or permanently deleting a smart contract in the system, which inherently allows for temporary disabling or permanent destruction of the smart contract based on e.g. security vulnerabilities or non-use, and includes a history with the parameters of historic smart contracts such as those destroyed; and further teaches destroying or disabling smart contracts in response to non-positive security test results) In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zhang and Iftemi as each is directed to blockchain smart contract deployment systems and Iftemi recognized “blockchain technology that underlies the Bitcoin application has become extremely appetizing, and it has been proven that the benefits it offers can also be used at in industrial software applications.” (¶10).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The Prior art cited in the attached PTO-892 form includes prior art relevant to applicant’s disclosures related to smart contract creation and management.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW J BROPHY whose telephone number is (571)270-1642. The examiner can normally be reached Monday-Friday, 9am-4:30pm.
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, Wei Zhen can be reached at 571-272-3708. 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.
MJB
5/15/2026
/MATTHEW J BROPHY/Primary Examiner, Art Unit 2191
Prosecution Insights