DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed 10/21/2025 with respect to the rejection(s) of claim(s) 1-20 have been fully considered but are not persuasive. The rejection (and corresponding rejections to its dependent claims, if applicable) is maintained.
The rejection of pending claims 1-20 under 35 U.S.C. 101 as directed to an abstract idea without significantly more, is maintained in view of MPEP 2106.04(d). Applicant argument of the claims provide a technical improvement are not persuasive because the claims do not recite any improvements or enhancements to technology that is already implemented. Instead, the claims recites to managing data definitions, access rights, and assign values through registries and smart contracts, which falls under the abstract idea of certain methods of organizing human activity. Under certain methods of organizing human activity is fundamental economic practices (mitigating risk) –which this claim is directed to. There is no improvement to decentralized computer platform, processor and memory, the claims are only managing data through registries and smart contracts. Therefore, the mere implementation of the steps above does not integrate the abstract idea into a practical application. See remarks on page 7-17.
The applicant states that Sardesai in view of Wright does not teach "the value registry mapping at least one class to the property; and accessing the at least one value using at least one key associated with an object identifier or the property." The examiner states that Wright describes “the value registry mapping at least one class to the property; and accessing the at least one value using at least one key associated with an object identifier or the property” at “Para. 0025, The invention may provide a method/system which enables the storage of a contract in a repository (registry), where a hash of the contract can be used as a look-up key for finding the contract.; and Para. 0011, The contract may be a document, file or other mechanism which defines a set of behaviour(s) that can be triggered under specified conditions. The control condition may be publically fulfilled. The invention should not be regarded as being limited to use within legal or commercially-oriented contexts, and the term ‘contract’ should not be construed in such a limiting sense. For example, the contract may be a ticket for a train or airline, or for a concert venue, and on which is printed an access code such as a machine readable barcode for providing unlocking a barrier.; and Claim 1, (d) generating a sub-contract derived from the contract, wherein the sub-contract is associated with a deterministic address and is generated by: iii) using a new public key derived using a seed; iv) storing the sub-contract in or on the repository with a reference to the contract, and broadcasting a transaction to the blockchain comprising a script which includes the reference; and/or v) adding a reference to the sub-contract to the metadata of the contract.; and Para. 0019-0021, generating a new key using data relating to a previous key associated with the contract; generating a script comprising the new key, the location of the contract and a hash of the contract; and paying an amount of currency to the script.; and Para. 0049, The metadata may comprise i) an address or representation of an address of where the contract is stored in the computer-based repository; and/or ii) a hash of the contract.” Under broad reasonable interpretation, “the value registry mapping at least one class to the property; and accessing the at least one value using at least one key associated with an object identifier or the property” is interpreted as “The invention may provide a method/system which enables the storage of a contract in a repository (registry), where a hash of the contract can be used as a look-up key for finding the contract…The metadata may comprise i) an address or representation of an address of where the contract is stored in the computer-based repository; and/or ii) a hash of the contract… generating a new key using data relating to a previous key associated with the contract” in the cited prior art. Modifying the method to include the value registry mapping at least one class to the property: and accessing the at least one value using at least one key associated with an object identifier or the property results in an improved invention because applying said technique ensures that the registry is securely stored and the data can be automatically verified, thus improving the overall security of the invention. See remarks on page 18-27.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Subject Matter Eligibility Criteria – Step 1:
Claims 1-9 and 16-20 are directed to a method (process) and claims 10-15 are directed to a system. Therefore, these claims fall within the four statutory categories of invention.
Subject Matter Eligibility Criteria – Step 2A – Prong One:
Regarding Prong One of Step 2A of the Alice/Mayo test, the claim limitations are to be analyzed to determine whether, under their broadest reasonable interpretation, they “recite” a judicial exception or in other words whether a judicial exception is “set forth” or “described” in the claims. MPEP 2106.04(II)(A)(1). An “abstract idea” judicial exception is subject matter that falls within at least one of the following groups: a) certain methods of organizing human activity, b) mental processes, and/or c) mathematical concepts. MPEP 2106.04(a).
Representative independents claims 1, 10, and 16 include limitations that recite at least one abstract idea.
Claim 1 is directed to the abstract idea of “creating a property registry on a decentralized computer platform including a processor and a memory, wherein the computer platform is implemented on a distributed ledger; the property registry storing at least one data definition, wherein a property including a name, a data type, and a source is defined by the at least one data definition, wherein the property is stored in the property registry; a source registry executing a smart contract to access the property stored in the property registry; adding the property to the source registry, the source registry deploying a smart contract assigning authorization to a smart contract address to enable the smart contract address to access, edit, and/or delete the property; the source registry executing a smart contract for verifying authorization to access, edit, and/or delete the property; assigning at least one value to the property and storing the at least one value in a memory of a value registry; the value registry mapping at least one class to the property: and accessing the at least one value using at least one key associated with an object identifier or the property .” Under its broadest reasonable interpretation, this claim is managing data definitions, access rights, and assign values through registries and smart contracts, and hence falls under organizing human activity (i.e., as fundamental economic practices).
Claim 10 is directed to the abstract idea of “a decentralized computer platform including a processor and a memory; wherein the decentralized computer platform accesses a distributed ledger; wherein the decentralized computer platform includes an attestation registry comprising a property registry, a source registry, a value registry, an option registry, and a unit conversion registry; wherein the property registry defines at least one property including a name, data, a data type, and a source, wherein the at least one property is stored in the property registry; wherein the source registry governs access to the property stored in the property registry by deploying a smart contract for verifying authorization to access, edit, and/or delete the property; wherein the value registry includes at least one value associated with the property, wherein the at least one value is accessed by an authorized party using at least one key associated with an object identifier and/or the property; wherein the options registry stores a list of constraint options, wherein the constraint options are enumerations of the at least one value stored in the value registry; and wherein the unit conversion registry includes a list of one or more smart contracts for converting the data from a first unit format into a second unit format.” Under its broadest reasonable interpretation, this claim is organizing and managing data access and usage for controlling access and permissions, and hence falls under organizing human activity (i.e., as fundamental economic practices).
Claim 16 is directed to the abstract idea of “creating a property registry on a decentralized computer platform including a processor and a memory, wherein the computer platform is implemented on a distributed ledger; the property registry storing at least one data definition, wherein a property including a name, data, a data type, and a source is defined by the at least one data definition, wherein the property is stored in the property registry; the property registry using a primary key of the property registry to indicate the location of the name, the data type, and the source within the property registry; a source registry executing a smart contract to access the property stored in the property registry, wherein the source registry uses a foreign key of the source registry to access the property, wherein the foreign key of the source registry indicates the location of the name, the data type, and the source within the property registry; adding the property to the source registry, the source registry deploying a smart contract assigning authorization to a smart contract address to enable the smart contract address to access, edit, and/or delete the property; the source registry executing a smart contract for verifying authorization to access, edit, and/or delete the property; assigning at least two values to the property and storing the at least two values in a memory of a value registry the value registry mapping at least one class to the property; accessing the at least two values using at least two keys associated with an object identifier or the property: an options list registry executing a smart contract for enumerating at least one combination of the at least two values stored in the value registry, wherein the enumeration is stored in the options list registry.” Under its broadest reasonable interpretation, this claim is managing data definitions, access rights, and assign values through registries and smart contracts, and hence falls under organizing human activity (i.e., as fundamental economic practices).
Dependent Claims:
Claims 2 and 11 recites: wherein the at least one value stored in the memory of the value registry is automatically updated when the at least one value is updated; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 3 and 12 recites: wherein the data type is a Boolean data type, an integer data type, a decimal data type, a string data type date and time data type, an object data type, and/or a pointer data type; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 4 recites: wherein the data type is a pointer data type, wherein the pointer data type points to a second pointer data type of a second property, wherein the second pointer data type points to a value; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 5, 13, and 17 recites: wherein authorization of the smart contract address to access, edit, and/or delete the property is granted based on a role of the smart contract address, an attribute of the smart contract address, a policy of the smart contract address, authorization granted to the smart contract address by a property owner, and/or authorization granted to the smart contract address by a property creator; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 6 recites: wherein the source registry implements an oracle smart contract for creation and/or identification of at least one complex policy; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 7 and 19 recites: wherein a property is created using a class registry, wherein the class registry stores a class template, the class template mapping at least one behavior including an event, an interface, and/or a function, wherein a class template is selected from the class registry to enable the property to inherit the at least one behavior mapped by the class template; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 8 recites: further comprising adding at least one additional behavior, including at least one additional event, at least one additional interface, and/or at least one additional function to the class template to produce a new class template, wherein the property displays the at least one behavior and the at least one additional behavior; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 9 and 20 recites: further comprising at least one developer updating the code of the smart contract for accessing the property stored in the property registry, the smart contract assigning authorization to a smart contract address, and/or the smart contract for verifying authorization; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 14 recites: further comprising an oracle, wherein the oracle accesses a third party platform to determine a rate of conversion for converting the data from the first unit format into the second unit format; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 15 recites: wherein the unit conversion registry receives an input of a plug-in conversion logic, wherein the data is in a first unit format, wherein the second unit format is the desired format of the data, wherein the plug-in conversion logic automatically converts the data from the first unit format into a second unit format; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Claims 18 recites: wherein the source registry implements an oracle smart contract for creation and/or identification of at least one complex policy, wherein a policy engine executes a policy engine smart contract to determine compliance of a proposed access, a proposed edit, and/or a proposed deletion of the property with the at least one complex policy; further describes the abstract idea of organizing human activity (i.e., as fundamental economic practices).
Subject Matter Eligibility Criteria – Step 2A – Prong Two:
Claim 1, 10, and 16 recites to a computer platform as an additional element to the judicial exception in the preamble. Viewed individually and in combination, this additional element to the identified judicial exception of Step 2A.1, amounts to no more than mere instructions for managing data definitions, access rights, assign values through registries and smart contracts, and organizing and managing data access and usage for controlling access and permissions on a generic computer. Therefore, at Step 2A.2, these additional elements do not act in combination to integrate the abstract idea into a practical application. The additional elements of claims 1, 10, and 16 considered both individually and as an ordered combination, do not amount to significantly more than the judicial exception because the additional element of a generic computer does no more than “[s]imply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry.” See MPEP 2106.05 (citing to Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225 (2014)).
Therefore claims 1, 10, and 16 is found ineligible under 35 U.S.C. 101.
Step 2B:
Viewed as a whole, instructions/method claims recite the concept of “organizing human activity” (i.e., as fundamental economic practices) in managing data definitions, access rights, assign values through registries and smart contracts, and organizing and managing data access and usage for controlling access and permissions are performed by a generic computer. The method claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field. Instead, the claims at issue amount to nothing significantly more than an instruction to apply the abstract idea using some unspecified, generic computer. See Alice Corp. Pty. Ltd., 573 U.S. 208. Mere instructions to apply the exception using a generic computer component and limitations to a particular field of use or technological environment cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The use of a computer server is to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or no obviousness.
Claims 1-2, 4-11, 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Sardesai et al. (US 20190312875 A1) in view of Wright et al. (US 20210090076 A1).
7. Regarding claim 1, Sardesai discloses a method of managing trusted data on a decentralized network, comprising: creating a property registry on a decentralized computer platform, including a processor and a memory, wherein the computer platform is implemented on a distributed ledger, (Para. 0014-0015, Implementations described herein provide distributed authentication using a blockchain database that invokes one or more smart contracts using, for example, a known programming language. Because the permissions change relatively infrequently, the rate of interaction needed from the authorization server into the blockchain database is low. According to one implementation, a node (e.g., a network device) in a distributed consensus network may receive a smart contract for permissions to access a service. The smart contract may be in an initial block for authorizations in a shared ledger. The node may receive, from an authorization server, an update to the shared ledger. The update may be a proposed block in the shared ledger requiring validation by the distributed consensus network. The node may store, in a local memory, a copy of the shared ledger with the update, when the distributed consensus network validates the update. The node may later receive, from a client device, an item request for an item associated with the service. The item request may include a client identifier. The node may determine if there is match of the client identifier and the item in the copy of the shared ledger and send the item to the client device when there is match of the client identifier and the item.; and Para. 0027, Each participating node in distributed consensus network 150 maintains a continuously-growing list of records referred to herein as a “shared ledger,” which is secured from tampering and revision. Any updates from authorization server 122 (or another trusted node) will be added into the shared ledger. Each version of the shared ledger contains a timestamp and a link to a previous version of the shared ledger. The authorization is added in chronological order to the shared ledger, and the shared ledger is presented to each of participating nodes in distributed consensus network 150 as a cryptographically secured block.)
adding the property to the source registry, the source registry deploying a smart contract assigning authorization to a smart contract address to enable the smart contract address to access, edit, and/or delete the property, the source registry executing a smart contract for verifying authorization to access, edit, and/or delete the property, (Para. 0015, According to one implementation, a node (e.g., a network device) in a distributed consensus network may receive a smart contract for permissions to access a service. The smart contract may be in an initial block for authorizations in a shared ledger. The node may receive, from an authorization server, an update to the shared ledger. The update may be a proposed block in the shared ledger requiring validation by the distributed consensus network. The node may store, in a local memory, a copy of the shared ledger with the update, when the distributed consensus network validates the update. The node may later receive, from a client device, an item request for an item associated with the service. ThDFe item request may include a client identifier. The node may determine if there is match of the client identifier and the item in the copy of the shared ledger and send the item to the client device when there is match of the client identifier and the item.; and Para. 0038, As shown in FIG. 3, authorization server 122 and/or configuration portal 124 may include a smart contract module 310, an editor 320, a verifier 330, a blockchain manager 340, and an authorization database 350.; and Para. 0040, Editor 320 may provide an interface (e.g., a text-based or graphical user interface) for creating smart contracts. Editor 320 may be implemented, for example as a software module that allows for creation of a smart contract (and a corresponding ABI) in human-readable input/output. In one implementation, editor 320 may provide structured input fields to identify, for example, users, classes, items, lists, permissions, permission templates, conditions, and/or memberships for a particular smart contract.; and Para. 0061, Process 600 may further include determining if there are any updates to the shared ledger (block 620). For example, an administrator or network technician may again use editor 320 to update the smart contract with, for example, new users or items.)
Sardesai does not explicitly disclose assigning at least one value to the property and storing the at least one value in a memory of a value registry.
However, Wright teaches assigning at least one value to the property and storing the at least one value in a memory of a value registry, (Para. 0104-0107, Smart contracts built into the Blockchain can be enforced through logic which is embedded directly into the bitcoin transaction (i.e. within the locking/unlocking scripts) and/or through external computer-based applications. Such external computer-based applications which may be referred to as ‘agents’, ‘oracles’ or ‘bots’… An invention is described herein where the contract is interpreted as remaining in effect as long as there is a valid unspent transaction output UTXO on the blockchain representing the contract. It will be appreciated that this unspent state can be influenced and altered as a result of various mechanisms (e.g. a programmed computing agent) whose behaviour is controlled by conditions or stipulations in the contract itself. For example, the contract stipulates that it will expire on a certain date, or that it will expire when a certain value reaches a specified threshold…Once the contract is terminated, this will be recorded on the blockchain as a spent output in a transaction and this available for public inspection. The blockchain transaction becomes a permanent, unalterable and public record of the contract's existence and current status. The repository (which may also be called a ‘registry’ or ‘register’) may be implemented in a variety of ways including, for example, as a distributed hash table (DHT). A hash of the contract can be generated and stored as metadata within the blockchain transaction, and can serve as the look-up key for referencing the contract from the blockchain. A reference to the location of the contract is also provided within the transaction metadata. For example, the URL for the repository may be provided. While the metadata is open to public view, the contract itself may not be, or may be partially protected.)
One of ordinary skill in the art would have recognized that applying the known technique of Wright to the known invention of Sardesai would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate property value features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include assigning at least one value to the property and storing the at least one value in a memory of a value registry results in an improved invention because applying said technique ensures that property values can be verifiable, tracked, and enforced in the blockchain, thus improving the overall security of the invention.
Sardesai does not explicitly disclose the property registry storing at least one data definition, wherein a property including a name, a data type, and a source is defined by the at least one data definition, wherein the property is stored in the property registry; a source registry executing a smart contract to access the property stored in the property registry.
However, Wright teaches the property registry storing at least one data definition, wherein a property including a name, a data type, and a source is defined by the at least one data definition, wherein the property is stored in the property registry; a source registry executing a smart contract to access the property stored in the property registry,(Para. 0025, The invention may provide a method/system which enables the storage of a contract in a repository (registry), where a hash of the contract can be used as a look-up key for finding the contract.; and Para. 0052, Access to some or all of the contents of the contract may be restricted to at least one designated authorised party. In other words, authorisation may be required in order to access or view some or all of the contract.; and Para. 0085, FIG. 2b shows metadata definition for the scenario of FIG. 2a. The metadata is carried on the (bitcoin) transaction output and which specifies the contract location and proof of validity (via the hash).; and Para. 0121- 0132, This is the structured- document or file stored within the repository and which is referenced from the Blockchain. The contract can be any type of contract or agreement. This may include, for example, financial contracts, title deeds, service contracts and more. A contract can be public or private in terms of its content. The contract is formalised in that it is expressed in a structured manner using a codification scheme. The basic elements of the contract model are as follows: A codification scheme that allows a complete description of any type of contract. The scheme may be a new construct or may use an existing facility such as XBRL, XML, JSON (etc.); A DFA (Deterministic Finite Automaton) to implement the Contract that can be fully defined within the codification scheme. This is made up of: A set of parameters, and where to source those parameters; A set of state definitions: A set of transitions between the states, including the trigger for the transition and the rules followed during the transition. Rules definition table: Definitions of the specific parameters for this instance of the Contract; Mechanisms to secure and protect the Contract; A ‘browser’ to enable the contact to be made human-readable in formal legal language; and A ‘complier’ to convert the codification scheme into oracle code and/or a script such as a Bitcoin script.)
One of ordinary skill in the art would have recognized that applying the known technique of Wright to the known invention of Sardesai would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate secure memory features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include the property registry storing at least one data definition, wherein a property including a name, a data type, and a source is defined by the at least one data definition, wherein the property is stored in the property registry; a source registry executing a smart contract to access the property stored in the property registry results in an improved invention because applying said technique ensures that only authorized users can view and interact with the registry to prevent unauthorized users from accessing sensitive data, thus improving the overall security of the invention.
Sardesai does not explicitly disclose the value registry mapping at least one class to the property: and accessing the at least one value using at least one key associated with an object identifier or the property.
However, Wright teaches the value registry mapping at least one class to the property: and accessing the at least one value using at least one key associated with an object identifier or the property, (Para. 0025, The invention may provide a method/system which enables the storage of a contract in a repository (registry), where a hash of the contract can be used as a look-up key for finding the contract.; and Para. 0011, The contract may be a document, file or other mechanism which defines a set of behaviour(s) that can be triggered under specified conditions. The control condition may be publically fulfilled. The invention should not be regarded as being limited to use within legal or commercially-oriented contexts, and the term ‘contract’ should not be construed in such a limiting sense. For example, the contract may be a ticket for a train or airline, or for a concert venue, and on which is printed an access code such as a machine readable barcode for providing unlocking a barrier.; and Claim 1, (d) generating a sub-contract derived from the contract, wherein the sub-contract is associated with a deterministic address and is generated by: iii) using a new public key derived using a seed; iv) storing the sub-contract in or on the repository with a reference to the contract, and broadcasting a transaction to the blockchain comprising a script which includes the reference; and/or v) adding a reference to the sub-contract to the metadata of the contract.; and Para. 0019-0021, generating a new key using data relating to a previous key associated with the contract; generating a script comprising the new key, the location of the contract and a hash of the contract; and paying an amount of currency to the script.; and Para. 0049, The metadata may comprise i) an address or representation of an address of where the contract is stored in the computer-based repository; and/or ii) a hash of the contract.)
One of ordinary skill in the art would have recognized that applying the known technique of Wright to the known invention of Sardesai would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate value registry features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include the value registry mapping at least one class to the property: and accessing the at least one value using at least one key associated with an object identifier or the property results in an improved invention because applying said technique ensures that the registry is securely stored and the data can be automatically verified, thus improving the overall security of the invention.
8. Regarding claims 2 and 11, Sardesai does not explicitly disclose wherein the at least one value stored in the memory of the value registry is automatically updated when the at least one value is updated.
However, Wright teaches wherein the at least one value stored in the memory of the value registry is automatically updated when the at least one value is updated, (Para. 0105-0107, An invention is described herein where the contract is interpreted as remaining in effect as long as there is a valid unspent transaction output UTXO on the blockchain representing the contract. It will be appreciated that this unspent state can be influenced and altered as a result of various mechanisms (e.g. a programmed computing agent) whose behaviour is controlled by conditions or stipulations in the contract itself. For example, the contract stipulates that it will expire on a certain date, or that it will expire when a certain value reaches a specified threshold… Effectively, the context around the unsigned transaction output UTXO and the associated metadata within the script that enables it to be spent, allows the transaction to act as a pointer or reference to an off-chain repository which contains the formal details of the contract. Herein, ‘off-chain’ means that it is not part of the blockchain itself. This provides a mechanism whereby anyone can use a software-based component or tool to determine whether the contract has been terminated or is still valid/open by inspecting the blockchain. Once the contract is terminated, this will be recorded on the blockchain as a spent output in a transaction and this available for public inspection. The blockchain transaction becomes a permanent, unalterable and public record of the contract's existence and current status. The repository (which may also be called a ‘registry’ or ‘register’) may be implemented in a variety of ways including, for example, as a distributed hash table (DHT). A hash of the contract can be generated and stored as metadata within the blockchain transaction, and can serve as the look-up key for referencing the contract from the blockchain.; and Para. 0316-0317, This enables data from intermediate steps of calculations to be stored in the all: stack, similar to the ‘memory’ function which allows data to be stored on the calculator. In one embodiment, the alt stack is used for configuring Bitcoin scripts to solve small computation tasks and returning the results in the computation. The agent also manages a registry of all the codes that it owns and runs. This registry is structured like a lookup table or dictionary that maps a specific key to a specific value. The key and value pair is represented by the hash of the code block (H.sub.1) and the IPv6 address of where the code is stored respectively. To retrieve the code block using the key H.sub.1, the lookup table is used to retrieve the associated value (this is the location where the code is stored) and retrieves the source code accordingly.)
One of ordinary skill in the art would have recognized that applying the known technique of Wright to the known invention of Sardesai would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate smart contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the at least one value stored in the memory of the value registry is automatically updated when the at least one value is updated results in an improved invention because applying said technique ensures that when values change, the system will automatically update with it, thus improving the overall performance of the invention.
9. Regarding claim 4, Sardesai does not explicitly disclose wherein the data type is a pointer data type, wherein the pointer data type points to a second pointer data type of a second property, wherein the second pointer data type points to a value.
However, Wright teaches wherein the data type is a pointer data type, wherein the pointer data type points to a second pointer data type of a second property, wherein the second pointer data type points to a value, (Para. 0106, Effectively, the context around the unsigned transaction output UTXO and the associated metadata within the script that enables it to be spent, allows the transaction to act as a pointer or reference to an off-chain repository which contains the formal details of the contract. Herein, ‘off-chain’ means that it is not part of the blockchain itself. This provides a mechanism whereby anyone can use a software-based component or tool to determine whether the contract has been terminated or is still valid/open by inspecting the blockchain. Once the contract is terminated, this will be recorded on the blockchain as a spent output in a transaction and this available for public inspection.; and Para. 0283, In this method all the nodes in the tree (public/private key pairs) are generated as a chain (or in any other way) and the logical relationships between the nodes in the tree is maintained by a table in which each node in the tree is simply associated with its parent node in the tree using a pointer. Thus the pointer may be used to determine the relevant public/private key pairs for determining the common secret key (CS) for the session.; and Para. 0321, The parameters could be populated by retrieving them directly from metadata in a transaction (e.g. bitcoin transaction) or from an external source such as an internal database or a private/public file or hash table or any combination of the above. Pointers to the external source of parameter values might be stored in metadata in a transaction.)
One of ordinary skill in the art would have recognized that applying the known technique of Wright to the known invention of Sardesai would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate blockchain features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the data type is a pointer data type, wherein the pointer data type points to a second pointer data type of a second property, wherein the second pointer data type points to a value results in an improved invention because applying said technique ensures that properties can reference to other references, thus improving the overall performance of the invention.
10. Regarding claims 5, 13, and 17, Sardesai discloses wherein authorization of the smart contract address to access, edit, and/or delete the property is granted based on a role of the smart contract address, an attribute of the smart contract address, a policy of the smart contract address, authorization granted to the smart contract address by a property owner, and/or authorization granted to the smart contract address by a property creator, (Para. 0039-0043, The smart contract has logic that allows the authorization server 122 to add or remove users. Authorization server 122 may also add or remove permissions and/or items from the user's permissions set. The items can be discrete items or lists of items. According to one implementation, the smart contract may include application binary interface (ABI) that may restrict particular nodes (e.g., service nodes 130) to read-only operations and permit read/write operations by only trusted nodes (e.g., authorization server 122). A smart contract does not require any user to be in the contract when it is created. That is, at the time of creation, a smart contract may have zero or more users…A “user” may indicate a user of the service. The user may generally be the operator of a client device (e.g., client device 140). The user's credentials identify the user uniquely for the service. A “class” may include a list of users that have the same credentials. The user can be associated with a class, granting of a set of permissions (or a permission template, as described below) to a list. “Items” are physical or digital assets associated with the service that require authorization or associated permissions before being accessed by a user. A “list” is an association of items, where the name of a list can be used as a single reference to refer to the group of items. The list can also be maintained as entries in the shared ledger or can be communicated separately, depending on frequency of updates to the list. “Permissions” are parameters associated with items or lists for a given user detailing the type of access allowed (read, read/write, add metadata, remove metadata, change metadata, update manifest tree, etc.). “Permission templates” are sets of permissions that can be copied into a class. If a class has the same permissions but possibly different conditions (described below), the permissions template can be used to reduce the amount of data entered into the shared ledger.; and Para. 0048, In one implementation, different ABI functions may be available to different nodes in network environment 100. For example, a “Read/Write Entry ABI” may be used to add, remove or modify specific entries in the shared ledger. Read/Write Entry ABIs may be limited, for example, to use by authorization server 122 or a designated trusted node. A “Node Read ABI” may be used to only read specific entries in the shared ledger. Node Read ABIs may be used, for example, by any of service nodes 130 to validate authorization for a requested item. A “Server Read ABI” may provide audit capabilities to fields in the shared ledger, including providing a tally or sum of the number of entries for a corresponding field.)
11. Regarding claim 6, Sardesai discloses wherein the source registry implements an oracle smart contract for creation and/or identification of at least one complex policy, (Para. 0039, Smart contract module 310 stores and manages smart contracts for users of client devices 140. A smart contract may apply to one or multiple users. The smart contract has logic that allows the authorization server 122 to add or remove users. Authorization server 122 may also add or remove permissions and/or items from the user's permissions set. The items can be discrete items or lists of items. According to one implementation, the smart contract may include application binary interface (ABI) that may restrict particular nodes (e.g., service nodes 130) to read-only operations and permit read/write operations by only trusted nodes (e.g., authorization server 122).; and Para. 0048] In one implementation, different ABI functions may be available to different nodes in network environment 100. For example, a “Read/Write Entry ABI” may be used to add, remove or modify specific entries in the shared ledger. Read/Write Entry ABIs may be limited, for example, to use by authorization server 122 or a designated trusted node. A “Node Read ABI” may be used to only read specific entries in the shared ledger. Node Read ABIs may be used, for example, by any of service nodes 130 to validate authorization for a requested item. A “Server Read ABI” may provide audit capabilities to fields in the shared ledger, including providing a tally or sum of the number of entries for a corresponding field.)
12. Regarding claims 7 and 19, Sardesai discloses wherein a property is created using a class registry, wherein the class registry stores a class template, the class template mapping at least one behavior including an event, an interface, and/or a function, wherein a class template is selected from the class registry to enable the property to inherit the at least one behavior mapped by the class template, (Para. 0028, According to an exemplary embodiment, customer device 160 provides access to devices in provider network 120. For example, customer device 160 includes a client, such as a web browser or other suitable software application. In one implementation, customer device 160 may include a web browser or other user interface to exchange data with configuration portal 124.; and Para. 0040-0045, Editor 320 may provide an interface (e.g., a text-based or graphical user interface) for creating smart contracts. Editor 320 may be implemented, for example as a software module that allows for creation of a smart contract (and a corresponding ABI) in human-readable input/output. In one implementation, editor 320 may provide structured input fields to identify, for example, users, classes, items, lists, permissions, permission templates, conditions, and/or memberships for a particular smart contract. A “user” may indicate a user of the service. The user may generally be the operator of a client device (e.g., client device 140). The user's credentials identify the user uniquely for the service. A “class” may include a list of users that have the same credentials. The user can be associated with a class, granting of a set of permissions (or a permission template, as described below) to a list. “Items” are physical or digital assets associated with the service that require authorization or associated permissions before being accessed by a user. A “list” is an association of items, where the name of a list can be used as a single reference to refer to the group of items. The list can also be maintained as entries in the shared ledger or can be communicated separately, depending on frequency of updates to the list. “Permissions” are parameters associated with items or lists for a given user detailing the type of access allowed (read, read/write, add metadata, remove metadata, change metadata, update manifest tree, etc.). “Permission templates” are sets of permissions that can be copied into a class. If a class has the same permissions but possibly different conditions (described below), the permissions template can be used to reduce the amount of data entered into the shared ledger. “Conditions” may indicate conditional parameters associated with permissions on a per-user or per-class basis. Conditions can include a time of day (restrict access to a certain time period, for example), a day of the week (restrict access to weekends, for example), or time duration from a given absolute or relative timestamp (hours/days/months, etc.), access frequency limits (e.g., one-time access, five times, etc.), aggregate time duration or view duration, or membership in a given sub-community. In addition to a class, users may also be described as part of a sub-community “membership” within a class. Membership may grant variable permissions regarding content specific to that membership.; and Para. 0050-0051, FIG. 4 is a diagram illustrating communications to establish a distributed ledger for permissions in a portion 400 of network environment 100. As shown in FIG. 4, network portion 400 may include authorization server 122, configuration portal 124, service nodes 130 within distributed consensus network 150, and customer device 160. An administrator, for example, may provide input 420 for a smart contract, via customer device 160, to authorization server 122. Input 420 may specify users, classes, items, lists, permissions, permission templates, conditions, and/or memberships for a particular smart contract.; and Para. 0053, Authorization server 122 may provide data from input 420 into a shared ledger update 450. Shared ledger update 450 may include, for example, actual changes to a smart contract along with a computed hash of the specification of the users, classes, items, lists, permissions, permission templates, conditions, and/or membe