DETAILED ACTION
1. Claims 1-2, 5-12 and 16-17 are pending in this examination.
Notice of Pre-AIA or AIA Status
2. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
3. 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.
Election/Restrictions
4.1. Applicant’s election with traverse of claims 1-2, 5-12 and 16-17 in the reply filed on 12/15/2025 is acknowledged.
4.2. Restriction for examination purposes as indicated is proper because all these inventions listed in this action are independent or distinct for the reasons given above and there would be a serious search and examination burden if restriction were not required because one or more of the following reasons apply:
(a) the inventions have acquired a separate status in the art in view of their different classification;
(b) the inventions have acquired a separate status in the art due to their recognized divergent subject matter;
(c) the inventions require a different field of search (for example, searching different classes/subclasses or electronic resources, or employing different search queries);
(d) the prior art applicable to one invention would not likely be applicable to another invention;
Claim Rejections - 35 USC § 103
5.1. 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.
Independent claims 1, 5
5.2. Claims 1-2, 5-12 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application No. 20220394468 to Avetisov et al (“Avetisov”) in view of US Patent No. 10728044 issued to Melo et al (“Melo”).
As per claim 1, Avetisov discloses a computer-implemented method for authenticating smart contracts, the method comprising:
obtaining ([0221], the user may generate a key-pair including a private key and a public key and sign a request for a certificate with the private key. In some embodiments, the request also includes one or more other credentials and identity proofs, which the user may establish in association with the Net ID 271 for proving ownership (which should not be taken to suggest that users cannot establish different or other credentials later on). In some embodiments, the authentication server 155 acts as a certificate authority and generates certificates for users. For example, the authentication server 155 may store a root certificate (e.g., a self-signed public key certificate supporting X.590-based public key infrastructure) and generate user digital certificates responsive to requests for distribution based in part on the root certificate. Thus, for example, a user digital certificate may be considered valid by virtual of its generation by the authentication server 155 for use within the identity management system and a user providing ownership of a Net ID 271 also proves ownership of a valid digital certificate authorizing the user to use the system, also see [0339], [0377], also see [0205]);
generating a signature derived from signing a message using the private key of the existing cryptographic key pair ([0194], … to verify a data signed with corresponding private keys of a key-pair. For example, a user might claim ownership of an existing user identity enumerated within the identity management system in a transaction record in the directed acyclic graph 205 by supplying an address of the transaction record, a representation of a credential, and a signature of the credential with a private key as arguments to a smart contract. The smart contract may verify the ownership claim by accessing the transaction record based on the address, identifying corresponding credential information associated with the transaction record (e.g., stored in the hash digest), and verify the signature with a public key associated with the transaction record. Verification of the signature indicates user ownership of the user identity enumerated in the transaction record by virtue of the user proving ownership of the private key. In practice, such as for an authentication function performed by a smart contract, the representation of the credential may be provided in a string that includes other or different data, like a time stamp or a randomly generated
identifier, like a token, supplied to the user device, according to a schema of the smart contract. The signature by the private key may be performed over the whole string such that the resulting verification confirms one or more of temporal proximity of signing to verification of the signature or generation of the token (and also ownership of the token). The transaction record may also be verified as being untampered with, such as by a process for recalculating values along a chain of cryptographic hash pointers from a node storing the transaction record to a root node of a block, and then for the block in blockchain, etc., thus indicating that the transaction record can be authenticated along with the user claim to ownership of the transaction record. Where the transaction record includes cryptographic hash pointers to other transaction records in a hash digest, those other transaction records may also be verified. Thus, for example, when an ownership claim by a user to a given transaction record is authenticated, that authentication may also confirm ownership to one or more additional transaction records included in the hash digest (also see [0220]-[0221], [0348]).
storing the signature, the message, the public key, and a ([0351, stored on the relying device 140. Offline policy may provide for use of an offline value for a user login to a relying device 140 (which may communicate the offline values for persistence with the policy on a mobile device when registered and when performing an online enabled mobile initiated login). Offline values may be a PIN, numerical or alphanumeric, or other value which may be input to the relying device by the user or obtained by the relying device from the mobile device (e.g., value may be provided by NFC, Bluetooth beacon, optical code, or other communication means). A given offline value may be single use, such that is cannot be captured for reuse, and a limited number of offline values may be persisted to a user device. For example, after registration or online login, the relying device may generate 1, 5, 10, 15, 25 etc. offline values (e.g., according to a policy) which may be persisted to the mobile device. In some embodiments, the offline values are generated based on the signed user certificate, or other deterministic data, like a public key of the mobile device, or a value associated with the relying device, such as a value or values of one or more registers, or a combination of values. Offline values may be generated in other ways in other embodiments. The relying device 140 may store data, such as the offline values, or data by which a received offline value may be verified. Additionally, the relying device 140 may store the policy, which may optionally include one or more rules for offline value verification. In some cases, the rules may be based on the capabilities of the mobile device and configuration of the relying device. Additionally, the relying device 140 may sign transmitted data, such as offline values or other data described herein, and an entity receiving the data may verify a signature of the relying device 140 based on public key associated with the relying device. In some case, the private key by which the relying device 140 signs data is associated with a given mobile device or user having registered to access the relying device. Thus, for example, an entity receiving signed data from the relying device 140, which may be in association with a request, challenge, access attempt, or login pertaining to a particular mobile device of a particular user, may verify the signature based on a corresponding public key distributed by the relying device or other entity in association with registration of the mobile device of the user., also see , [0170], [0308], [0339] ).
verifying that the signature was signed with the same cryptographic key pair associated with the [0360], the credential is a token, like a user certificate, which may be signed by a certificate service, like an SSL certificate service, or other certificate or ticketing service. Thus, for example, the certificate may be an active directory SSL certificate, [0194], … to verify a data signed with corresponding private keys of a key-pair), and
deploying the smart contract on a blockchain based on the verifying ([0265], … one or more authentication operations as the results of those records stored in the directed acyclic graph 205 may be considered authoritative by virtue of determining whether the transaction records corresponding to those results are unmodified (e.g., by computing one or more cryptographic hashes) because a majority of the computing nodes reached consensus on verification of the results for publication according to a given smart contract…) .
Avetisov does not explicitly disclose however in the same field of endeavor, Melo discloses obtaining an existing cryptographic key pair associated with a website digital certificate (Col. 8, lines 15-20 -a Client Application is a software module downloaded to and running on a user's device which is in possession of a leaf certificate signed by the Personal Certificate Authority for the purpose of authenticating the user when connecting to a Verifying Party (e.g., a web resource)…Col. 12, lines 63 to col 13, lines 12 – the Signing Application 224 signs a Certificate Signing Request (CSR) 234 using intermediate 2 private key 226. Using the available Rendezvous Mechanisms 232, the Client Application sends the CSR 234 to a Signing Application 212 running on one of the user's Trusted Devices 210. The Signing Application 212 signs the new CSR using its intermediate certificate 220 and returns a Personal Certificate Chain 236 to the Signing Application 224 on New Device 222. The Signing Application 224 installs the Personal Certificate Chain (118, 220, 230) into its Secure Enclave 228 and can now use it to present the user's credentials to a Verifying Party. New device 222 is now a Trusted Device. The resulting Personal Certificate Chain 236 on the new Trusted Device 222 is longer by one intermediate certificate than the chain found on the Signing Application 212 of the original Trusted Device 210.
Furthermore, it is also well known that as describe by Melo in col 2, lines 20-45 - Currently, a Public Key Infrastructure (PKI) exists to allow users to verify the identity of a website, to make sure they are communicating with the correct entity. Public/Private key encryption is used for site authentication. A trusted, third-party Certificate Authority (CA) can be used to authenticate the identity of a website. In this process, the owner of a domain generates a public/private key pair. The public key of the website is wrapped in a Certificate Signing Request (CSR) along with other information, and it is signed with the private key. This CSR is submitted to the CA for the creation of a Certificate. The trusted CA validates the ownership of the website's web address using whatever means determined by that CA to be necessary and sufficient. The CA then uses the private key of an intermediate certificate, which was itself signed by a root certificate, to sign a Certificate for the website. … . The website leaf Certificate thus links to the trusted CA's own trusted certificate, referred to as a root certificate, by way of intermediate certificate that signed it, forming a chain of certificates. By trusting the CA's root certificate, any client connecting to the website can trust the leaf certificate presented by the site as a valid identity of the website. Let's Encrypt® is the most common root certificate CA today).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Avetisov with the teaching of Melo by including the feature of signing, in order for Avetisov’s system to verify the user to a verifying party, with the verifying party able to follow the chain to find the user's public key in the signed root certificate. In embodiments, an authentication server interfaces between a user device with a self-signed certificate and a verifying computer that accepts a user name and password. The user device generates a self-signed certificate signed by a private key on the user device. The self-signed certificate is transmitted to a verifying party computer over a network. The verifying party stores the self-signed certificate with user identification data. The user migrates trust to another device by providing the root certificate and intermediate certificate as a certificate chain to a second device, which then adds a new intermediate certificate to create a longer certificate chain with the same root certificate. In subsequent communications, the verifying party receives a certificate chain including the self-signed certificate from the second user device, and matches that with the user identification data stored in a database. (Melo, abstract).
As per claim 2, the combination of Avetisov and Melo discloses the method of claim 1, where the website digital certificate comprises a Secure Sockets Layer (SSL)/ Transport Layer Security (TLS) digital certificate (Avetisov, [0360], the credential is a token, like a user certificate, which may be signed by a certificate service, like an SSL certificate service, or other certificate or ticketing service. Thus, for example, the certificate may be an active directory SSL certificate).
As per claim 5, Avetisov discloses a computer-implemented method for authenticating smart contracts comprising: obtaining a digital certificate ([0377], … obtain another token, or a certificate…);
verifying the digital certificate was signed with a private key associated with the digital certificate ([0360], the credential is a token, like a user certificate, which may be signed by a certificate service, like an SSL certificate service, or other certificate or ticketing service. Thus, for example, the certificate may be an active directory SSL certificate, [0194], … to verify a data signed with corresponding private keys of a key-pair); and
deploying a smart contract on a blockchain based on the verifying the digital certificate was signed ([0265], … one or more authentication operations as the results of those records stored in the directed acyclic graph 205 may be considered authoritative by virtue of determining whether the transaction records corresponding to those results are unmodified (e.g., by computing one or more cryptographic hashes) because a majority of the computing nodes reached consensus on verification of the results for publication according to a given smart contract…, also see [0360]) ..
Furthermore, Avetisov discloses … to verify a data signed with corresponding private keys of a key-pair, but does not explicitly disclose however in the same field of endeavor, Melo discloses signed with a private key associated with the digital certificate (Col. 12, lines 63 to col 13, lines 12) , Note: Further it is also well known as describe by Melo in col 2, lines 20-45 (8) Currently, a Public Key Infrastructure (PKI) exists to allow users to verify the identity of a website, to make sure they are communicating with the correct entity. Public/Private key encryption is used for site authentication. A trusted, third-party
Certificate Authority (CA) can be used to authenticate the identity of a website. In this process, the owner of a domain generates a public/private key pair. The public key of the website is wrapped in a Certificate Signing Request (CSR) along with other information, and it is signed with the private key. This CSR is submitted to the CA for the creation of a Certificate. The trusted CA validates the ownership of the website's web address using whatever means determined by that CA to be necessary and sufficient. The CA then uses the private key of an intermediate certificate, which was itself signed by a root certificate, to sign a Certificate for the website. … . The website leaf Certificate thus links to the trusted CA's own trusted certificate, referred to as a root certificate, by way of the intermediate certificate that signed it, forming a chain of certificates.
By trusting the CA's root certificate, any client connecting to the website can trust the leaf certificate presented by the site as a valid identity of the website. Let's Encrypt® is the most common root certificate CA today).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Avetisov with the teaching of Melo by including the feature of signing, in order for Avetisov’s system to verify the user to a verifying party, with the verifying party able to follow the chain to find the user's public key in the signed root certificate. In embodiments, an authentication server interfaces between a user device with a self-signed certificate and a verifying computer that accepts a user name and password. The user device generates a self-signed certificate signed by a private key on the user device. The self-signed certificate is transmitted to a verifying party computer over a network. The verifying party stores the self-signed certificate with user identification data. The user migrates trust to another device by providing the root certificate and intermediate certificate as a certificate chain to a second device, which then adds a new intermediate certificate to create a longer certificate chain with the same root certificate. In subsequent communications, the verifying party receives a certificate chain including the self-signed certificate from the second user device, and matches that with the user identification data stored in a database. (Melo, abstract).
As per claim 6, the combination of Avetisov and Melo discloses the method of claim 5, where: the digital certificate is associated with a website, and obtaining the digital certificate comprises obtaining the digital certificate using an existing cryptographic key pair used to obtain the digital certificate, the existing cryptographic key pair comprising the private key and a public key (Avetisov, [0320]-[0321]).
As per claim 7, the combination of Avetisov and Melo discloses the method of claim 6, further comprising inserting the digital certificate, the existing cryptographic key pair, and a website address associated with the website in a smart contract (Avetisov, [0367]).
As per claim 8, the combination of Avetisov and Melo discloses the method of claim 5, where obtaining the digital certificate comprises: generating a new pair of cryptographic keys, the new pair of cryptographic keys comprising the private key and a public key; and requesting a digital certificate from a certificate authority based on the new pair of cryptographic keys (Avetisov, [0223]-[0224], also see [0110]).
As per claim 9, the combination of Avetisov and Melo discloses the method of claim 8, inserting the digital certificate and the new pair of cryptographic keys in the smart contract (Avetisov, [0377]).
As per claim 10, the combination of Avetisov and Melo discloses the method of claim 5, where obtaining the digital certificate comprises: generating a request for the digital certificate, the request comprising a public key and identifying information of an entity associated with the public key; and receiving the digital certificate from a certificate authority (Avetisov, [0109]).
As per claim 11, the combination of Avetisov and Melo discloses the method of claim 10, where the request comprises a certificate signature request (CSR) (Avetisov, [0276]-[0278], [0221],).
As per claim 12, the combination of Avetisov and Melo discloses the method of claim 10, where the identifying information comprises at least one of a domain name, personal identifier, a name, an organization name, and a country (Avetisov, [0110]).
5.3. Claims 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov and Melo as applied to claim above, and in view of US Patent Application No. 20220066751 to YAN et al (“YAN”).
As per claim 16, the combination of Avetisov and Melo discloses the invention as described above. Avetisov and Melo do not explicitly disclose however, In the same field of endeavor, YAN discloses the method of claim 1, wherein the smart contract has not been compiled and not yet been deployed on a blockchain ([0066], compilation if the machine code of the smart contract is not locally stored, [0005]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Avetisov with the teaching of Melo/YAN by including the feature of a compile, in order for Avetisov’s system to increase a speed of executing a smart contract, and reduce storage overheads on the blockchain node. The present specification provides a method for executing a smart contract, a blockchain node, and a storage medium. An implementation of a method for executing a smart contract includes: receiving, by a blockchain node, a request for creating a smart contract, the request including a bytecode of the smart contract; starting, by the blockchain node after completing deployment of the smart contract, to compile the bytecode of the smart contract into a machine code by using ahead of time and storing the machine code; and during execution of the deployed smart contract, executing, by the blockchain node, the machine code of the smart contract in response to the machine code being locally stored. According to the above implementations of the present application, the blockchain node can greatly increase a speed of executing a smart contract, and reduce storage overheads on the blockchain node (YAN, abstract).
As per claim 17, the combination of Avetisov, Melo and YAN disclose the method of claim 1, wherein the smart contract has been compiled and not yet been deployed on a blockchain (YAN, [0044] After the contract is created, a contract account corresponding to the smart contract appears on the blockchain and has a specific address, and a contract code and account storage are stored in the contract account. Behavior of the smart contract is controlled by the contract code, and the account storage of the smart contract keeps a contract status. In other words, the smart contract causes a virtual account including the contract code and account storage to be generated on the blockchain). The motivation regarding the obviousness of claim 16 is also applied to claim 17.
##################################################
Independent claims 1, 5
5.2. Claims 1-2, 5-12 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application No. 20220394468 to Avetisov et al (“Avetisov”) in view of “TeSC: TLS/SSL-Certificate Endorsed Smart Contracts” by Gallersdorfer et al., (“Gallersdorfer”).
As per claim 1, Avetisov discloses a computer-implemented method for authenticating smart contracts, the method comprising:
obtaining ([0221], the user may generate a key-pair including a private key and a public key and sign a request for a certificate with the private key. In some embodiments, the request also includes one or more other credentials and identity proofs, which the user may establish in association with the Net ID 271 for proving ownership (which should not be taken to suggest that users cannot establish different or other credentials later on). In some embodiments, the authentication server 155 acts as a certificate authority and generates certificates for users. For example, the authentication server 155 may store a root certificate (e.g., a self-signed public key certificate supporting X.590-based public key infrastructure) and generate user digital certificates responsive to requests for distribution based in part on the root certificate. Thus, for example, a user digital certificate may be considered valid by virtual of its generation by the authentication server 155 for use within the identity management system and a user providing ownership of a Net ID 271 also proves ownership of a valid digital certificate authorizing the user to use the system, also see [0339], [0377], also see [0205]);
generating a signature derived from signing a message using the private key of the existing cryptographic key pair ([0194], … to verify a data signed with corresponding private keys of a key-pair. For example, a user might claim ownership of an existing user identity enumerated within the identity management system in a transaction record in the directed acyclic graph 205 by supplying an address of the transaction record, a representation of a credential, and a signature of the credential with a private key as arguments to a smart contract. The smart contract may verify the ownership claim by accessing the transaction record based on the address, identifying corresponding credential information associated with the transaction record (e.g., stored in the hash digest), and verify the signature with a public key associated with the transaction record. Verification of the signature indicates user ownership of the user identity enumerated in the transaction record by virtue of the user proving ownership of the private key. In practice, such as for an authentication function performed by a smart contract, the representation of the credential may be provided in a string that includes other or different data, like a time stamp or a randomly generated
identifier, like a token, supplied to the user device, according to a schema of the smart contract. The signature by the private key may be performed over the whole string such that the resulting verification confirms one or more of temporal proximity of signing to verification of the signature or generation of the token (and also ownership of the token). The transaction record may also be verified as being untampered with, such as by a process for recalculating values along a chain of cryptographic hash pointers from a node storing the transaction record to a root node of a block, and then for the block in blockchain, etc., thus indicating that the transaction record can be authenticated along with the user claim to ownership of the transaction record. Where the transaction record includes cryptographic hash pointers to other transaction records in a hash digest, those other transaction records may also be verified. Thus, for example, when an ownership claim by a user to a given transaction record is authenticated, that authentication may also confirm ownership to one or more additional transaction records included in the hash digest (also see [0220]-[0221], [0348]).
storing the signature, the message, the public key, and a ([0351, stored on the relying device 140. Offline policy may provide for use of an offline value for a user login to a relying device 140 (which may communicate the offline values for persistence with the policy on a mobile device when registered and when performing an online enabled mobile initiated login). Offline values may be a PIN, numerical or alphanumeric, or other value which may be input to the relying device by the user or obtained by the relying device from the mobile device (e.g., value may be provided by NFC, Bluetooth beacon, optical code, or other communication means). A given offline value may be single use, such that is cannot be captured for reuse, and a limited number of offline values may be persisted to a user device. For example, after registration or online login, the relying device may generate 1, 5, 10, 15, 25 etc. offline values (e.g., according to a policy) which may be persisted to the mobile device. In some embodiments, the offline values are generated based on the signed user certificate, or other deterministic data, like a public key of the mobile device, or a value associated with the relying device, such as a value or values of one or more registers, or a combination of values. Offline values may be generated in other ways in other embodiments. The relying device 140 may store data, such as the offline values, or data by which a received offline value may be verified. Additionally, the relying device 140 may store the policy, which may optionally include one or more rules for offline value verification. In some cases, the rules may be based on the capabilities of the mobile device and configuration of the relying device. Additionally, the relying device 140 may sign transmitted data, such as offline values or other data described herein, and an entity receiving the data may verify a signature of the relying device 140 based on public key associated with the relying device. In some case, the private key by which the relying device 140 signs data is associated with a given mobile device or user having registered to access the relying device. Thus, for example, an entity receiving signed data from the relying device 140, which may be in association with a request, challenge, access attempt, or login pertaining to a particular mobile device of a particular user, may verify the signature based on a corresponding public key distributed by the relying device or other entity in association with registration of the mobile device of the user., also see , [0170], [0308], [0339] ).
verifying that the signature was signed with the same cryptographic key pair associated with the [0360], the credential is a token, like a user certificate, which may be signed by a certificate service, like an SSL certificate service, or other certificate or ticketing service. Thus, for example, the certificate may be an active directory SSL certificate, [0194], … to verify a data signed with corresponding private keys of a key-pair), and
deploying the smart contract on a blockchain based on the verifying ([0265], … one or more authentication operations as the results of those records stored in the directed acyclic graph 205 may be considered authoritative by virtue of determining whether the transaction records corresponding to those results are unmodified (e.g., by computing one or more cryptographic hashes) because a majority of the computing nodes reached consensus on verification of the results for publication according to a given smart contract…) .
Avetisov does not explicitly disclose however in the same field of endeavor, Gallersdorfer discloses obtaining an existing cryptographic key pair associated with a website digital certificate (page 95, right col., also see page 96, right col. TeSC enables the endorsement of smart contracts with a private/public key pair of a previously existing TLS certificate issued by a certificate authority (CA). This approach allows wallets or other software that directly interact with smart contracts to verify their authenticity and binding to the respective domain… 2. Certificate Retrieval: Afterward, it connects to the respective domain given in the smart contract (or that pre viously known by the website) and obtains the certificate. If the optional certfingerprint is set, the certificate is directly retrieved from Certificate Transparency. 3. Smart Contract Endorsement Verification: The soft ware validates whether the private key of the certificate signed).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Avetisov with the teaching of Gallersdorfer by including the feature of signing, in order for Avetisov’s system to reduces the risk of address replacement attacks by removing web applications from the threat model and enables the detection and prevention of maliciously issued TLS endorsed smart contracts (TeSC). (Gallersdorfer, page 95).
As per claim 2, the combination of Avetisov and Gallersdorfer discloses the method of claim 1, where the website digital certificate comprises a Secure Sockets Layer (SSL)/ Transport Layer Security (TLS) digital certificate (Avetisov, [0360], the credential is a token, like a user certificate, which may be signed by a certificate service, like an SSL certificate service, or other certificate or ticketing service. Thus, for example, the certificate may be an active directory SSL certificate).
As per claim 5, Avetisov discloses a computer-implemented method for authenticating smart contracts comprising: obtaining a digital certificate ([0377], … obtain another token, or a certificate…);
verifying the digital certificate was signed with a private key associated with the digital certificate ([0360], the credential is a token, like a user certificate, which may be signed by a certificate service, like an SSL certificate service, or other certificate or ticketing service. Thus, for example, the certificate may be an active directory SSL certificate, [0194], … to verify a data signed with corresponding private keys of a key-pair); and
deploying a smart contract on a blockchain based on the verifying the digital certificate was signed ([0265], … one or more authentication operations as the results of those records stored in the directed acyclic graph 205 may be considered authoritative by virtue of determining whether the transaction records corresponding to those results are unmodified (e.g., by computing one or more cryptographic hashes) because a majority of the computing nodes reached consensus on verification of the results for publication according to a given smart contract…, also see [0360]) ..
Furthermore, Avetisov discloses … to verify a data signed with corresponding private keys of a key-pair, but does not explicitly disclose however in the same field of endeavor, Gallersdorfer discloses signed with a private key associated with the digital certificate (section II, page 96, The En dorsement (Section II-A) holds information about the ap proval of a smart contract by the domain owner signed with the TLS certificate’s private key. The On-Chain TLS Endorsed Smart Contract (Section II-B).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Avetisov with the teaching of Gallersdorfer by including the feature of signing, in order for Avetisov’s system to reduces the risk of address replacement attacks by removing web applications from the threat model and enables the detection and prevention of maliciously issued TLS endorsed smart contracts (TeSC). (Gallersdorfer, page 95).
As per claim 6, the combination of Avetisov and Gallersdorfer discloses the method of claim 5, where: the digital certificate is associated with a website, and obtaining the digital certificate comprises obtaining the digital certificate using an existing cryptographic key pair used to obtain the digital certificate, the existing cryptographic key pair comprising the private key and a public key (Avetisov, [0320]-[0321]).
As per claim 7, the combination of Avetisov and Gallersdorfer discloses the method of claim 6, further comprising inserting the digital certificate, the existing cryptographic key pair, and a website address associated with the website in a smart contract (Avetisov, [0367]).
As per claim 8, the combination of Avetisov and Gallersdorfer discloses the method of claim 5, where obtaining the digital certificate comprises: generating a new pair of cryptographic keys, the new pair of cryptographic keys comprising the private key and a public key; and requesting a digital certificate from a certificate authority based on the new pair of cryptographic keys (Avetisov, [0223]-[0224], also see [0110]).
As per claim 9, the combination of Avetisov and Gallersdorfer discloses the method of claim 8, inserting the digital certificate and the new pair of cryptographic keys in the smart contract (Avetisov, [0377]).
As per claim 10, the combination of Avetisov and Gallersdorfer discloses the method of claim 5, where obtaining the digital certificate comprises: generating a request for the digital certificate, the request comprising a public key and identifying information of an entity associated with the public key; and receiving the digital certificate from a certificate authority (Avetisov, [0109]).
As per claim 11, the combination of Avetisov and Gallersdorfer discloses the method of claim 10, where the request comprises a certificate signature request (CSR) (Avetisov, [0276]-[0278], [0221],).
As per claim 12, the combination of Avetisov and Gallersdorfer discloses the method of claim 10, where the identifying information comprises at least one of a domain name, personal identifier, a name, an organization name, and a country (Avetisov, [0110]).
5.3. Claims 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov and Gallersdorfer as applied to claim above, and in view of US Patent Application No. 20220066751 to YAN et al (“YAN”).
As per claim 16, the combination of Avetisov and Gallersdorfer discloses the invention as described above. Avetisov and Gallersdorfer do not explicitly disclose however, In the same field of endeavor, YAN discloses the method of claim 1, wherein the smart contract has not been compiled and not yet been deployed on a blockchain ([0066], compilation if the machine code of the smart contract is not locally stored, [0005]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Avetisov with the teaching of Gallersdorfer /YAN by including the feature of a compile, in order for Avetisov’s system to increase a speed of executing a smart contract, and reduce storage overheads on the blockchain node. The present specification provides a method for executing a smart contract, a blockchain node, and a storage medium. An implementation of a method for executing a smart contract includes: receiving, by a blockchain node, a request for creating a smart contract, the request including a bytecode of the smart contract; starting, by the blockchain node after completing deployment of the smart contract, to compile the bytecode of the smart contract into a machine code by using ahead of time and storing the machine code; and during execution of the deployed smart contract, executing, by the blockchain node, the machine code of the smart contract in response to the machine code being locally stored. According to the above implementations of the present application, the blockchain node can greatly increase a speed of executing a smart contract, and reduce storage overheads on the blockchain node (YAN, abstract).
As per claim 17, the combination of Avetisov, Gallersdorfer and YAN disclose the method of claim 1, wherein the smart contract has been compiled and not yet been deployed on a blockchain (YAN, [0044] After the contract is created, a contract account corresponding to the smart contract appears on the blockchain and has a specific address, and a contract code and account storage are stored in the contract account. Behavior of the smart contract is controlled by the contract code, and the account storage of the smart contract keeps a contract status. In other words, the smart contract causes a virtual account including the contract code and account storage to be generated on the blockchain). The motivation regarding the obviousness of claim 16 is also applied to claim 17.
7.1. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure as the prior art discloses many of the claim features (See PTO-form 892).
7.2. a). US Patent Application No. 20150156024 to DE LOS SANTOS et al., discloses a computer implemented method including a software distributor signing via a first server at least one software file using a digital certificate with a digital signature and at least one user via a computing device acquiring a copy of the signed software file. The digital certificate to be used is previously recorded in a second server in communication with the first server, the digital certificate to be recorded being provided by the software distributor upon a registration of the latter in the second server and including information obtained from a trust certificate chain associated to the digital certificate when performing the registration. The second server generates, upon a request made by the software distributor, a hash stamp of the signed software file.
b). US Patent Application No. 20240214228 to Huntley et al., discloses are various embodiments for blockchain based public key infrastructure. A public key associated with a network address and an identifier of a certifying smart contract for a certifying entity associated with the public key can be obtained from an identity smart contract hosted by a blockchain network. Then, a certifying public key and a signature for the public key associated with the network address are obtained from the certifying smart contract. Subsequently, the signature of the public key associated with the network address can be verified using the certifying public key.
Conclusion
8. Any inquiry concerning this communication or earlier communications from the examiner should be directed to HARUNUR RASHID whose telephone number is (571)270-7195. The examiner can normally be reached 9 AM to 5PM.
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, Eleni A. Shiferaw can be reached at (571) 272-3867. 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.
HARUNUR . RASHID
Primary Examiner
Art Unit 2497
/HARUNUR RASHID/Primary Examiner, Art Unit 2497