Smart contract

Abstract

To provide a system that creates, negotiates, and approves a smart contract.SOLUTION: A system for a smart contract incorporates a server that is connected to an internet that runs software that provides web presence with a two-way interface, a data repository that stores a template and a completed contract, a port to a block chain service, a plurality of registered users, each associated with a wallet, and a communication service for the user. A registered user initiates the smart contract either manually or by accessing the template from the data repository, and a new contract is associated with a Mithra token that defines a clause.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims priority to Provisional Application No. 62 / 738,848, filed September 28, 2018, the entire disclosure of which is incorporated by reference at a minimum. FIELD OF THEINVENTION

[0002] The present invention relates to technology of processes for negotiating and implementing compliance regulations, contracts, and transactions, and more particularly to new types of smart contracts and systems for integrating parties involved in such contract types and their associated transactions into a collaborative and secure system and distributing this new type of contract across business and consumer networks. [Background technology]

[0003] Legal contracts have evolved slowly over the last few millennia, and the technology to produce, manage, and enforce them continues to become outdated.

[0004] Traditional contract systems that create, vet, negotiate, sign, execute, publish, and store compliance rules and contracts are time-consuming and wasteful. Contracts are presented in structured data formats, which is the majority of how so-called "digital" contracts are handled, making them difficult to track, verify, find the terms therein, audit, or transfer. Additionally, this impedes progress in the world of contracts by not being able to properly apply technologies such as artificial intelligence and analytics.

[0005] In the 1990s, a new type of contract, called a smart contract, was born. A smart contract is a computer protocol intended to digitally facilitate, verify, or enforce the negotiation or execution of a contract. A smart contract allows for the execution of trusted transactions without a third party. Many clauses of a smart contract can be self-executing. For example, a smart contract may specify that a certain amount of digital currency should be transferred upon the occurrence of a certain condition, and the smart contract may detect the occurrence of a certain condition and, once the occurrence is detected, transfer the digital currency. These transactions are traceable and irreversible. In addition, the encryption used by smart contracts ensures security, a key requirement for contract management in a digitalized world.

[0006] Smart contracts use a scripting language to define the rights and obligations of the parties. One exemplary scripting language for smart contracts is Solidity. Solidity is an object-oriented, high-level language that can control the behavior of accounts in the Ethereum blockchain. Solidity has been used to create smart contracts that are used to implement voting, crowdfunding, blind auctions, and multi-signature wallets.

[0007] While smart contracts in the art undoubtedly offer some distinct advantages over traditional contract technology, they fall short by not being presented in a manner that is human readable. Since contracts are legally binding agreements that govern the rights and obligations of the parties to the agreement, human readability is the most important attribute of any contract technology. Without human readability, the applications of smart contracts are very limited.

[0008] There was an attempt to combine cryptography and contracts when renowned financial cryptographer Ian Grigg invented Ricardian contracts in 1996. Ricardian contracts are a way to record documents as legal contracts and securely link these to other systems, such as accounting for contracts, as an emission of value.

[0009] According to Grigg, "A Ricardian contract can be defined as a single document that: a) is a contract offered by an issuer to a holder; b) is for valuable rights held by the holder and controlled by the issuer; c) is easily readable by people (like a paper contract); d) is readable by computer programs (is parsable like a database); e) is digitally signed; f) contains key and server information; and g) is bound to a unique and secure identifier."

[0010] An important difference exists between smart contracts and Ricardian contracts: although it is possible to implement a Ricardian contract as a smart contract, this does not mean that all Ricardian contracts are smart contracts. Thus, not all smart contracts are Ricardian contracts. A smart contract refers to a type of digital compliant agreement that has already been agreed upon and can be executed automatically. On the other hand, Ricardian contracts follow a contract model that records the so-called "intention" of a particular contract and its "actions", whether they have been executed or not. Ricardian contracts can refer to code as well, using hashes that refer to external documents.

[0011] The advantages offered by Ricardian contracts include security, transparency, efficiency, and reliability, which are lacking in traditional written contracts, as well as human readability, which is lacking in smart contracts.

[0012] However, Ricardian contracts are not known by the general public and only a few projects have attempted to implement them. One of the main challenges of Ricardian contracts is their lack of usability, consumability, and transferability. Like many great inventions, if there is no use or profitable activity built around them, they will be forgotten or abandoned very quickly. Thus, the following is clearly needed:

[0013] A new type of contract that uses smart contract techniques and is human readable and consumable.

[0014] A high performance and robust monetization collaboration that enables this new type of contract to be easily usable, consumable, and transferable by users within the monetization collaboration. Summary of the Invention [Means for solving the problem]

[0015] In one embodiment of the present invention, a system for creating, negotiating, and approving smart contracts is provided, the system comprising: a server connected to the internet running software (SW) on a processor, the SW providing a web presence with a two-way interface; a data repository coupled to the server storing user information, contract templates, and completed contracts; a port to a blockchain service; a registration interface for registering users, each user in the registration being issued a digital blockchain wallet for either a personal account or a business account; and a communication service by which registered users communicate. A registered user initiates a smart contract either by manually writing it with an online editor or by accessing a smart contract template from a data repository; the new contract is submitted to the blockchain and associated with a Mithra token that defines all of the contract terms; with the issued token in effect, the contract issuer engages one or more counterparties to join the smart contract; the counterparties, upon active engagement, create counter tokens that define the rights and obligations under the contract for the counterparties; through the communication service, the initiator and counterparties negotiate the contract terms to reach an agreement; the contract is signed and published to either a public or private store.

[0016] In one embodiment, the contract is both human readable and machine readable. Also, in one embodiment, the counterparties are invited to join the contract by direct email or text invitation from the initiator. Also, in one embodiment, the issuer assigns user permissions to each invited counterparty, including, but not limited to, administrative privileges, view only, edit and / or comment, or sign only. In one embodiment, upon receiving the invitation via email or SMS, the invitee signs into the system or registers if they are a first-time user.

[0017] In one embodiment, the initiator and the counterparty negotiate the contract terms via a chat communication system, and the terms are codified in their respective Mithra tokens. Also, in one embodiment, the initiator and the counterparty are each provided with a human-readable version of the smart contract presented side-by-side so that each party may propose changes to the terms, which may be vetted and accepted or challenged by the other party until an agreement is reached. In one embodiment, the system further comprises a search function, whereby a user may search for templates in a data repository and select a template for initiating a contract. In one embodiment, the system further comprises a search function, whereby a user may search for published contracts and join the selected contract by submitting an offer or proposal. In one embodiment, once the user selects a contract in the search results, the user is presented with a submission form, whereby the user may enter the terms to be entered into the smart contract, and negotiation begins between the issuer and the submitting user. In one embodiment, a submitting user is issued a counter Mithra token that defines the rights and obligations for that user, where they are allowed to participate in the negotiation process.

[0018] In another aspect of the invention, a method for creating, negotiating, and approving smart contracts includes the steps of initiating a smart contract, either by manually writing it with an online editor operated by software execution on a processor of an internet-connected server providing a system of two-way interfaces, or by accessing a smart contract template from a data repository coupled to the server; associating the new smart contract with a Mithra token that defines all of the contract terms by submitting the contract to a blockchain service; engaging counterparties to join the smart contract, who have issued counter Mithra tokens that define rights and obligations for the counterparties; negotiating the smart contract terms towards agreement by the initiator and the counterparties using an online communication service; and signing the smart contract and publishing it to a public or private store.

[0019] In one embodiment, the method includes providing the contract to be human readable and machine readable. Also, in one embodiment, the method includes inviting counterparties to join the contract via direct email or text invitation from the initiator. In one embodiment, the method includes assigning user permissions to each invited counterparty, including, but not limited to, administrative privileges, view only, edit and / or comment, or sign only.

[0020] In one embodiment of the method, upon receiving the invitation via email or SMS, the invitee signs in or registers with the system. In one embodiment, the method also includes negotiating contract terms between the initiator and the counterparty via a chat communication system, where the terms are codified in the respective Mithra tokens. In one embodiment, the method includes providing human-readable versions of the smart contract presented side-by-side for the initiator and the counterparty in a two-way interface, where each party may propose changes to the terms, which may be reviewed and accepted or challenged by the other party until an agreement is reached.

[0021] In one embodiment, the method further includes a step of a user searching for templates in a data repository by a search function and selecting a template for initiating a contract. In one embodiment, the method further includes a step of a user searching for published contracts by a search function and joining the selected contract by submitting an offer or proposal. In one embodiment, the method includes a step of presenting the user with a submission form, whereby the user may enter clauses to be entered into the smart contract, whereby a negotiation is initiated between the issuer and the submitting user. Also, in one embodiment, the method includes a step of issuing a counter Mithra token that defines rights and obligations for the submitting user, where the submitting user is now admitted to participate in the negotiation process. The present invention provides, for example, the following items. (Item 1) 1. A system for creating, negotiating, and approving smart contracts, the system comprising: a server connected to the internet running software (SW) on a processor, said SW providing a web presence with an interactive interface; a data repository coupled to the server that stores user information, contract templates, and completed contracts; Ports to blockchain services, a registration interface for registering users, each user being issued a digital blockchain wallet upon registration; Communication services and Equipped with The communication service allows registered users to communicate, A registered user initiates a smart contract by manually writing the smart contract with an online editor or by accessing a smart contract template from the data repository, and a new contract is submitted to a blockchain and associated with a token that defines the contract terms of the smart contract; Once an issued token is issued, a contract issuer engages one or more counterparties to join the smart contract, the counterparties, upon active participation, create counter tokens that define the rights and obligations under the smart contract for the counterparties, and through the communication service, the initiator and the counterparties negotiate contract terms towards an agreement, and the smart contract is signed. (Item 2) 2. The system of claim 1, wherein the smart contract is linked to a human-readable representation of the contract terms of the smart contract. (Item 3) 2. The system of claim 1, wherein the counterparties are invited to join the smart contract by direct email or text invitation from the initiator. (Item 4) 4. The system of claim 3, wherein the publisher assigns user permissions to each invited contract partner, including, but not limited to, administrative privileges, view only, edit and / or comment, or sign only. (Item 5) 4. The system of claim 3, wherein upon receiving the invitation via email or SMS, the invitee signs into the system or, if a first-time user, registers. (Item 6) 6. The system of claim 5, wherein the initiator and the counterparty negotiate contract terms via a chat communication system, the terms being codified in respective tokens. (Item 7) Item 6. The system of item 5, wherein the initiator and each of the counterparties are provided with a human-readable version of the smart contract presented side-by-side, whereby each party may propose changes to the terms, which may be vetted and accepted or challenged by the other party until an agreement is reached. (Item 8) 2. The system of claim 1, further comprising a search function whereby a user can search for templates within the data repository and select a template for initiating a contract. (Item 9) 2. The system of claim 1, further comprising a search function whereby a user can search published contracts and join a selected contract by submitting an offer or proposal. (Item 10) 10. The system of claim 9, wherein when a user selects a contract within the search results, a submission form is presented to the user, whereby the user may enter terms, which are entered into the smart contract, and negotiation begins between the issuer and the submitting user. (Item 11) Item 11. The system of item 10, wherein the submitting user is issued a counter token that defines rights and obligations for that user, whereby participation in the negotiation process is permitted. (Item 12) 1. A method for creating, negotiating, and approving a smart contract, the method comprising: Initiating a smart contract by manually authoring it using an online editor operated by software running on a processor of a server connected to the Internet providing the system of interactive interfaces or by accessing a smart contract template from a data repository coupled to said server; Associating the new smart contract with a Mithra token that defines all of the contract terms by submitting the contract to a blockchain service; Engaging a counterparty in joining the smart contract, the counterparty issuing a counter token that defines rights and obligations for the counterparty; negotiating smart contract terms for agreement by the initiator and the counterparty using an online communication service; Signing the smart contract and publishing it to a public or private store; A method comprising: (Item 13) Item 13. The method of item 12, comprising providing the contract to be both human readable and machine readable. (Item 14) 13. The method of claim 12, further comprising inviting counterparties to join the contract via a direct email or text invitation from the initiator. (Item 15) 15. The method of claim 14, including assigning user permissions to each invited contract partner, including, but not limited to, administrative privileges, view only, edit and / or comment, or sign only. (Item 16) Item 15. The method of item 14, comprising, upon receiving the invitation via email or SMS, signing in or registering with the system, by the invitee. (Item 17) Item 17. The method of item 16, comprising negotiating contract terms between the initiator and the contracting counterparty via a chat communication system, the terms being codified in respective Mithra tokens. (Item 18) 17. The method of claim 16, further comprising providing a human-readable version of the smart contract presented side-by-side for the initiator and the counterparty in a two-way interface so that each party may propose changes to terms that can be reviewed and accepted or challenged by the other party until an agreement is reached. (Item 19) Item 12. The method of item 11, further comprising a user searching for templates in the data repository via a search function and selecting a template for initiating a contract. (Item 20) Item 12. The method of item 11, further comprising a user searching for published contracts via a search function and joining a selected contract by submitting an offer or proposal. (Item 21) 21. The method of claim 20, further comprising presenting a submission form to a user whereby the user may enter terms, the terms being entered into the smart contract, and negotiation being initiated between the issuer and the submitting user. (Item 22) 22. The method of claim 21, further comprising issuing a counter Mithra token that defines rights and obligations for the submitting user, the submitting user then being granted participation in the negotiation process. (Item 23) 1. A method of creating a human readable smart contract, the method comprising: generating a smart contract comprising code in a scripting language, said code specifying terms defining rights and obligations of at least two parties; generating human readable text describing the terms of the smart contract; linking a first address defining a location of the smart contract with a second address defining a location of the human readable text on the World Wide Web, whereby said linking enables readability of the smart contract; A method comprising: (Item 24) receiving, from a user, a selection of a template describing at least one clause, the template including a fixed portion and a variable portion; receiving a value for said variable portion from said user; Further comprising: 24. The method of claim 23, wherein generating the human readable text includes generating the code such that the code defines the at least one clause according to the value, and generating the smart contract includes generating the human readable text to explain the at least one clause according to the value. (Item 25) receiving an edit to the human readable text from one of the at least two parties, the edit modifying the value for the variable portion; amending the smart contract to define the at least one clause with the modified value; and 25. The method of claim 24, further comprising: [Brief description of the drawings]

[0022] [Figure 1] FIG. 1 is a schematic diagram of a Mithra contract 101.

[0023] [Diagram 2]FIG. 2 is an architecture diagram illustrating, at a high level, the system for the Mithra platform in one embodiment of the present invention.

[0024] [Diagram 3] FIG. 3 illustrates one of many bidirectional interfaces that may be provided within a system domain in one embodiment of the invention.

[0025] [Figure 4] FIG. 4 is a simplified example of an interactive interface within the system for creating, selecting, and editing templates in one embodiment of the present invention.

[0026] [Diagram 5] FIG. 5 illustrates an interactive interface that allows a user to search contracts, templates, and outstanding contracts stored in various collections within the system in one embodiment of the invention.

[0027] [Figure 6] FIG. 6 illustrates an exemplary project overview dashboard for a user in one embodiment of the present invention.

[0028] [Figure 7] FIG. 7 is an example of a project details dashboard in one embodiment of the present invention.

[0029] [Figure 8] FIG. 8 illustrates a window that a user may invoke to invite others to join a contract in one embodiment of the invention.

[0030] [Figure 9] FIG. 9 illustrates the results of a search for contracts in one embodiment of the present invention.

[0031] [Figure 10] FIG. 10 illustrates an interface that allows users to submit offers and enter into contracts in one embodiment of the invention.

[0032] [Figure 11] FIG. 11 illustrates the side-by-side presentation of the same contract to two participants in one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0033] The present invention consists of two main components: 1. A new type of smart contract referred to herein as a Mithra contract.

[0034] 2. A system for integrating the parties involved in Mithra contracts and their associated transactions into a collaborative and secure system, and for distributing this new type of contract across business and consumer networks. (Mithra Contract)

[0035] Figure 1 is a schematic diagram of a Mithra Contract 101. Mithra Contracts (MC) are a new type of smart contract that allows users to create, negotiate, and approve contracts that are both human-readable and machine-readable, legally binding, machine-executable and shareable by humans, and tokenized to enable transferability, traceability, tradeability, and portability.

[0036] Unlike Ricardian contracts, human readability of Mithra contracts is achieved by creating a human-readable representation on the World Wide Web (WWW) of the smart contract underlying the MC. The smart contract underlying the MC is accessible through a link. A link is shown in FIG. 1, at the left of the figure. A link is a unique, shareable address, which may be human-readable. A human-readable address can be resolved into a smart contract address, which identifies a location on a distributed ledger or blockchain. In contrast to a human-readable address, a contract address may be a long alphanumeric or hexadecimal number. In one embodiment, the human-readable address may identify the location on the WWW of a human-readable version of the MC, for example, by including a uniform resource locator.

[0037] The human-readable address can be decomposed into a smart contract address using the Ethereum blockchain standard EIP / ERC181.8. Similarly, a reverse solution that allows a lookup of a human-readable address into a smart contract address may be possible using the EIP / ERC181.8 standard. Thus, with Mithra contracts, an authorized user can read a representation of a smart contract that is already presented on the blockchain in human-readable form by opening it in a compatible editor. Mithra contracts further tokenize the contract by representing each clause or set of clauses defined in the contract between the parties to the contract according to a special form of token called Mithra Token (MT). MT may specify both a section of code that defines the terms of the smart contract and human-readable text that explains the terms. Each party involved in the contract, i.e., not only the parties to the contract but also legal representatives, multiple attorneys, agents, and other authorized parties, will hold a Mithra token with their respective obligations, permissions, and rights. In Figure 1, a registered member 102a owns a MT 103a that defines certain terms associated with that person. Another member 102b owns a MT 103b that defines certain permissions and rights. An arrow joining the two illustrates that the permissions and rights are related. As a simple example, MT 103a may define a right for member 102a to collect monthly rent from member 1102b, so that MT 103b would define the terms of the obligation to pay monthly rent imposed by MT 103a on member 102a.

[0038] The complete set of terms represented by Mithra tokens are grouped together to form a Mithra group (MG). Thus, a Mithra contract can consist of a finite number of Mithra groups, each of which can consist of a finite number of Mithra tokens until it reaches a final state, which is triggered either by signatures from all required parties or when the contract terms are met between a single pair of tokens in the group. Each MT represents an asset that can have value, since it is a set of rights and obligations, and thus the owner of the MT can demand or pay money to change the ownership of the MT. In FIG. 1, several Mithra groups 104 are illustrated. Note that the members and tokens represented by 102x and 103x are not necessarily separate from the group, but are grouped together.

[0039] To further define, a contract governs the rights and obligations of the parties to the governing provisions. Rights on one side of the contract equate to relative obligations on the other side, and vice versa. Thus, the provisions represented by Mithra tokens can sometimes be further categorized as rights, obligations, or other. This is particularly useful when Mithra tokens possess intrinsic value for which rights can be transferred or monetized. A Mithra contract consists of the entire set of negotiated rights and obligations represented by tokens and associated with persons.

[0040] As a result, the Mithra Token will become a fully tradable token that can be transferred to another entity in its own right, along with all of its rights and obligations with respect to the Mithra Family within the Mithra Contract.

[0041] Mithra contracts provide various technical features that may improve the distributed computing platform on which they operate. For example, the way in which the human-readable version is linked to the smart contract on the Ethereum blockchain allows for more efficient lookups between the two. Instead of having to cross-reference various different databases, a resolver is employed, which requires secure computing resources. In another example, by grouping contract clauses into tokens, memory may be used more efficiently. Instead of having common clauses repeated over and over across many different contracts, tokenization allows for the centralization and reuse of common clauses. Thus, Mithra contracts provide various technical and technological improvements. (Mithra Platform - Revenue Activity Collaboration for Mithra Contracts)

[0042] The Mithra Platform is comprised of a range of novel technological components that are highly consumable and can be integrated by individuals and businesses alike to generate revenue-generating collaboration for Mithra contracts. The Mithra Platform constitutes a concrete application that enables the generation of smart contracts and corresponding human-readable forms of smart contracts.

[0043] FIG. 2 is an architecture diagram illustrating the system for the Mithra platform at a high level. Line 209 represents the well-known Internet network, including all of the interconnected networks and sub-networks. Mithra domain 200 comprises a server 201 running software 203 on a processor. The software 203 provides a website and a user dashboard with multiple interactive interfaces for users to interact with the system. A data repository 202 provides storage for user data and contacts, as well as other data storage as required by server 201. Those skilled in the art will recognize that there may be multiple servers and data repositories, and that the system intelligence may be distributed in many ways. The simplified architecture shown is deemed sufficient to explain the functionality of the system of the present invention.

[0044] Third party server 204 is meant to represent virtually any number of servers and domains within the Internet network with which Mithra domain 200 may interact that are implementations of services for registered members. One such service is, for example, Ethereum. TM It may be a connection to a blockchain service such as

[0045] Users 205(1-n) are users who connect to the Mithra domain 200 through computers, such as pad devices, laptop computers, tower systems, and integrated systems, having an internal LAN. The connection is typically through one or another type of Internet Provider (ISP) 207. Users 206(1-n) represent users who connect through mobile devices, such as smartphones and the like, for example, via a wireless network through network hub 208.

[0046] In one embodiment, Mithra domain 200 is configured to allow users to interact with Mithra domain 200 through a computerized device running a web browser. In an alternative embodiment, each user platform may download and execute an application that communicates with a compatible application running Mithra domain 200.

[0047] Exemplary bidirectional interfaces are described below for various purposes. (User wallet and account management) (User wallet management)

[0048] To join the system, a user must first register or sign in by either importing a seed phrase assigned to the user's existing wallet or having a new blockchain wallet created by the system. The system assigns a highly secure private key (seed phrase) to the new wallet address, allowing them to join and access the new wallet. The system also provides helpful hints on how to securely derive the private key. The User Wallet will be used for two main purposes:

[0049] · Manage system access as described above.

[0050] Manage utility tokens that are required to use the system, such as purchasing more tokens, transferring tokens to another wallet, or making payments. (User, Account and Wallet Management)

[0051] Due to the enterprise nature of the system and its business and consumer target markets, the system must overcome existing distributed ledger models that lack meaningful structure and permission controls for implementing compliance regulations, contracts, and transaction processes. For example, as a business user, the contracts and transactions created by the user belong to their respective organization, not to that person personally.

[0052] Thus, in one embodiment of the system, two user account types are provided: one business account and one personal account. (Business accounts vs. personal accounts)

[0053] FIG. 3 illustrates one of many interactive interfaces that may be provided by SW 203 executing on server 201 in Mithra domain 200. The services provided by the interactive interface illustrated by FIG. 3 are for registration of new members and, in some cases, for editing registration information. Although the registration interface is selected in this example, various interfaces for different purposes may be selected in menu column 302 found at the bottom left side of the registration interface. This menu column remains for substantially all interfaces that may be accessed by the user, allowing the user to easily navigate from one interface to another. Command line 301 provides links to various other functions enabled by SW 203, as seen in FIG. 2. Those skilled in the art will appreciate that SW 203 may be a wide variety of programs and executable code providing many different functions and running on many different platforms.

[0054] The interface shown is operable for a new user to register and provide the necessary information to the system to instantiate the registration of a person or business as a registered user. As is common in this type of interface, input fields for name, address, email, etc. are provided in area 303 of the interface. Other functionality related to registration, including, for example, personal information, email, and connected accounts, security, notifications, etc., are provided by menu listings in the left vicinity in area 303. These are links that redirect the user to other interfaces.

[0055] At the time of registration with the Mithra revenue activity collaboration, users are asked to create a business account or a personal account. If a new user selects a business account, the system will issue a new wallet for the user instead of allowing the user to use an existing wallet, even if it may be compatible. The intent is that the wallet associated with the business account will remain within the business and be used only for the business. An individual can hold two system accounts with two separate wallets, one for the business and one for their personal use. The business and personal account types share some common features, both of which include the following: User Information Email and connected accounts like LinkedIn or Facebook Security Settings Proof of identity or KYC (Know Your Customer) Notification settings Preferences such as Project View, Project Sorter By, etc. Wallet information such as wallet address The following settings distinguish between business and personal accounts: (Account Type-Business vs. Personal)

[0056] For business accounts, some additional fields will be required, such as user role, which can be administrator, user, or other required role. Also, for the organizational unit identifier (which can be retrieved from the registered organizations list), users from the same organization should have the same value in this field.

[0057] A first person creating a business account for a specific organization fills in the organization's details such as its name, address, contact details, and industry. This person is automatically granted the administrator role. In addition, the system will automatically generate an organizational unit identifier. (Business Manager User Dashboard)

[0058] An administrator user is provided with a purposeful administrator dashboard for performing a set of actions. The dashboard is a set of interactive interfaces, each of which provides input fields and links to other interfaces as necessary, the functionality of which is described herein without explicitly illustrating the individual fields and links within the interfaces.

[0059] Invite a new user: Invite a new user from the same organizational unit into the system via email and / or SMS invitation. The new user must create a new wallet on the platform instead of reusing an existing compatible wallet. The default role of the new user is set to "User", but an admin user can select a different role at the time of invitation.

[0060] · Change User Role: Upgrade or downgrade a user role.

[0061] Revoke a User: When a user leaves an organization or is no longer required to hold a system license, an admin user can revoke the user's access to the user's account and any wallets associated with the revoked account.

[0062] · Restore a User: If a user's access is accidentally revoked or if the user is required to regain use of the system, an admin user can restore the user's access to their account and wallet.

[0063] The system will not allow wallet access associated with a revoked account. However, the possibility exists that a revoked user will attempt to port and use the wallet on another compatible blockchain network. A global system switch is in place to ensure that revoked business wallets do not regain access to data associated with any Mithra system. (Template Management)

[0064] A template in Mithra Contracts implies a structured digital document that defines the nature of a clause, contract, or project as a clause. A template may have fixed narrative parts that can be adjusted, and variable parts. The variable parts allow the template to be adapted to a particular situation and may provide flexibility for the parties to negotiate the clause.

[0065] As an example, to create a contract for the sale of a commercial building, the nature of the contract is that there will be some fixed language and some variables. The fact that the transaction represented by the sale of the building is a sale with rights being transferred from one party or organization to another is fixed. Who the parties to the transaction are, the sale price, the means and terms of payment, etc., are all variables to be negotiated and concluded in the development of the contract. However, once such a contract is concluded, a template may be created that defines the location of the fixed and variable elements. When developing such a contract, one may own the rights in the template and may claim the use of the template to create a contract for the sale of a different building by another person where the variables to be negotiated may be the same.

[0066] Mithra revenue collaboration heavily relies on the use of templates. There are three hierarchical levels of templates available: clause templates, contract templates, and project templates.

[0067] By providing templates, embodiments may provide technical advantages in terms of memory and processing power usage. Allowing frequently used contract clauses to be reused in templates may use memory more efficiently than having to repeat or re-generate the same wording each time. FIG. 4 is a simplified example of an interactive interface in the Mithra system for creating, selecting, and editing templates. The dashboard link shown as element 302 in FIG. 3 is, of course, present as it is in virtually all interactive interfaces presented to users in the system. Command line 401 provides an active link to navigate to an alternative collection of templates. The "Create new link 402" navigates to an interactive interface that allows the user to create a new template. A collection 403 of existing templates of various kinds and for various uses is displayed.

[0068] Each project template consists of one or more contract templates, which are made up of one or more clause templates. Templates can be defined in the following hierarchy: General Templates Industry-specific templates, e.g., Medical, Oil & Gas, Real Estate Geography-specific templates, e.g. California, Singapore, London Organization-specific templates, e.g., government departments, associations, private companies ·Personal template

[0069] All templates are reusable, searchable, and analyzable. Breaking down templates to the clause level allows digital clauses to be reused in multiple contracts and contract templates, and makes templates searchable via keywords and / or other search criteria. More importantly, clauses can be analyzed and become valuable to contract users. For example, the system now has a way to analyze how many times one particular clause is used across a revenue activity collaboration. This allows contract users to gain insights such as whether a clause is a standard clause used by many users, or a customized clause that needs special attention. The system provides a green light for standard clauses and a red light for clauses that require careful scrutiny.

[0070] Templates can be created by simply adding a new template via the user's library, or alternatively, this can occur via the template save feature when a project, contract, or clause is created or updated.

[0071] All templates will appear in the user's library dashboard, allowing the user to organize them into various categories such as Recent, Favorites, Downloads, Archives, and Published.

[0072] Templates are stored in the user's library on the dashboard and can be organized into various categories such as recent, favorites, downloads, archives, and published.

[0073] Template owners can choose to publish templates to either a private environment or a public store. Once made available to the public, the template becomes searchable, downloadable, and usable by other users within the template marketplace on the Mithra platform. Template owners can decide whether payment is required for the public to download their template. The system facilitates the payment process for template purchases.

[0074] Users may choose any suitable payment method. On the Mithra platform, the ShelterZoom Mithra Coin (SMC) utility token is typically used for template transactions. Thus, SMC will be paid from the buyer's wallet to the template seller's wallet.

[0075] In a scenario where a template is published to a private store, all users with access to the private store can also download the template and use it. For example, it is common for companies or associations to publish templates for their respective employees or members to use their organization's default templates. This would significantly reduce template duplication across organizations. Once a digital template is created once, all authorized users can download it from the same source without having to create it again by each individual.

[0076] These privately published templates are often free for members to use, but may require a payment from the template users.

[0077] Template users can also subscribe to template notifications. For example, users will receive system notifications when new templates are made available for their subscribed industries or categories, or when a new version for a template the user has downloaded is published. In addition, contract templates are one of the main starting points for initiating contract creation.

[0078] 5 illustrates an interface that allows users to search for contracts, templates, and outstanding contracts stored in various collections within the system. The normal command line for the Mithra dashboard is always apparent, and the interface provides a query field 501 for users to enter queries to find low-cost contract, project, and legal clause templates. In addition, a second query field 502 allows users to search and find existing contracts for almost anything that users can use as is or edit to produce their own contracts and then save as templates. (Project (Transaction) Management)

[0079] Project management, sometimes referred to as transaction management in the system, is the starting point for creating a Mithra contract. A project can be any type of project or transaction, such as a procurement project, a real estate transaction, a financial transaction, or a supply chain project. (Project Overview Dashboard) From the project overview dashboard, users can:

[0080] · Get ​​at-a-glance insight into its recent projects, new messages, and a consolidated status overview.

[0081] View important information about each project, such as project name, start date, status, and profile pictures of project participants.

[0082] · Create a new project (transaction).

[0083] · Select an existing project.

[0084] · Sort the project list by date, status, user, or any other available sort order.

[0085] · Search for projects by defined search criteria.

[0086] Projects are presented in either a card view or a line view, depending on the user's preference.

[0087] 6 illustrates an exemplary project overview dashboard for a user, formatted in a card view. Recently accessed files may be selected in area 601. Recent messages may be visited and replied to in area 602. Status is presented in area 603. Those skilled in the art will appreciate that the interface of FIG. 6 is exemplary and much functionality may be compromised as the diagram requires certain standards regarding font sizes, etc.

[0088] All projects in the user's wallet are presented in the dashboard in a card view, with each project in a small card-sized icon, in area 604. In this example, only the subject is shown, but in some embodiments, significantly more information, status, whether it has been signed, dates, and the like, may be shown as well.

[0089] Each icon is a link to the project represented, and selection of one project redirects the user to another interface where the project can be further managed as described below.

[0090] In an alternative embodiment, the project overview dashboard is presented in a line view where each project is represented in a line rather than as a card. The functionality is the same. (Project Details Dashboard)

[0091] Once the user selects an existing project, the user is redirected to the project details dashboard. Figure 7 is an example of a project details dashboard in one embodiment of the present invention. The dashboard is divided into five main sections:

[0092] · Documents - All contracts and documents associated with the project are displayed in either a card view or a line view in area 702, which is sortable and searchable. · Selected Contracts - A quick overview of selected contracts 701

[0093] Workflow - A detailed workflow 703 for the selected contract containing all past versions of the contract and the actions and participants associated with each version. The user can click on any version in the workflow and follow it to the contract's details page. A list of participants of the selected contract in the user area 704

[0094] Chat - A chat section 705 to facilitate communication between participants with permission to chat and to view chat history. The contract issuer defines the permissions regarding user chat privileges, e.g., a seller and a buyer can chat directly if there is no proxy between them, but cannot chat directly if there is an appointed proxy. For more advanced features, see the Chat section later in this document.

[0095] The dashboard is also used to initiate the creation of new contracts for new or existing projects. (Contract Management)

[0096] Contract management is, in many embodiments, a very important feature of the present invention. (Creating a contract - issuing Mithra tokens)

[0097] The contract process starts with the creation of a new contract, based either on a predefined template or an entirely new contract. In the latter scenario, the contract writer can use an inline editor to manually add clauses one by one, or find suitable clauses via searching the clause template library and insert them into the contract. Either way, once the user selects a predefined template or finds suitable clauses using the clause template library, the selected template is retrieved and compiled into the MC. The user can then define any variables within the template or clause template.

[0098] Upon completion, the contract writer can submit the contract to the blockchain, which in turn generates a smart contract with an issued token (Mithra token) that bears all the defined clauses. (Publishing Contracts - Public vs. Private Stores)

[0099] Contract issuers can choose to publish contracts to either a public store or a private store. Contracts published to the public store are available in a global search area so that everyone can browse them and have the opportunity to join the contract. Contracts held in a private store are not publicly searchable. Users can join a contract only by invitation. (Joining the Contract - Creating Counter Mithra Tokens) With the issued token in an issued state, the contract issuer can now invite a counterparty or multiple counterparties to join the contract according to the publish method. 1. Invite your counterparty via private invitation

[0100] · The publisher can invite one or many parties to join the contract and assign different user permissions to each invitee, e.g. manage, view, edit and / or comment, or sign only.

[0101] Upon receiving the invitation via email or SMS, the Invitee may sign in to the System or register if the Invitee is a first-time user.

[0102] Invitees can create counter Mithra tokens by either formally joining the contract, signing the contract, submitting offers, or directly countering the terms of the contract.

[0103] FIG. 8 illustrates a window 801 that a user may invoke to invite others to join the contract. If a "other person" is to be invited, that person will have a username and a profile with contact information. The inviting user may select user permissions as shown in window 801, and the invited user will receive a communication, such as an email, with the invitation, according to the configuration. New users may be invited as well, and upon registration in the process will have the status of a registered user. 2. Join via the Contract Marketplace

[0104] ·Mithra's public store creates a marketplace for contracts. Referring back to FIG. 5 and the description of FIG. 5 above, the contract marketplace can be searched. The marketplace model of the present invention allows suppliers to list their contracts as well as interested parties to subscribe or search for contracts of a type. For example, an IT services company interested in government contracts can search for any government RFPs for IT services, or a property lessor who prefers short-term leases in a particular area can subscribe to alerts whenever such leases come on the market. FIG. 9 shows an example result of searching for contracts or listing by contract owner. Multiple contracts are shown, each depicted as an annotated icon in FIG. 9.

[0105] Upon finding a contract within the Contract Marketplace, a participant may select the contract to be redirected to a human readable version of the contract 1001, as shown in FIG. 10. Participants are enabled to join the contract by submitting an offer or proposal, e.g., an estate offer or an RFC proposal. A submission form is provided alongside the contract such that each value typed into a field automatically appears on the digital contract. Once all fields on the submission form are filled in, the participant can preview the entire contract displayed on the other side and then submit the offer by selecting the "Submit" link 1002 at the bottom.

[0106] A counter Mithra token is then generated for each recipient that is currently in the contract workflow and can initiate the negotiation process. (Contract Negotiation)

[0107] Mithra contracts, fully digitized and tokenized contracts, create unprecedented capabilities in contract negotiation. By storing their respective contract terms on the Mithra token, each party can fully participate in real-time contract negotiations and view counter clauses as they are presented. With distributed ledger technology, parties can be assured that all changes are verifiable and immutable. This procedure creates trust among all contract participants. Additionally, the system provides an effective side-by-side scrutiny dashboard, illustrated as FIG. 11, whereby participants can collaborate to amend contract terms so that each party is visible to the trajectory change and they have the opportunity to accept the change. In FIG. 11, Victoria proposes to change the deposit from $10,000 to $15,000 in two places in the contract by striking out the $10,000 value and typing in the new $15,000 value. In Aaron's version, Aaron has accepted the first of the two changes, but not yet accepted the second.

[0108] These changes may involve removing clauses, adding clauses, or modifying variables present in the template relating to clauses. When such changes are made, the changes may be made to both the human-readable version shown in Figure 11 and to the underlying smart contract code. (Creating a candidate list - handling multiple offers)

[0109] In situations where multiple offers are received from participants, e.g., in an RFC or estate sale, the system allows the contract issuer to shortlist several offers so that the issuer can focus its negotiations on those selected offers. The issuer will further select the contract winner by signing the smart contract. (Signing the contract - Mithra token matching)

[0110] Once all the terms are met between the issued tokens and their counter tokens held by their respective holders, the smart contract can be signed and executed. (Transfer of Ownership - Transfer of Mithra Tokens)

[0111] Mithra tokens can carry the rights and obligations of an asset. Under certain circumstances, tokens can be transferred from one party to another such that all of the rights and obligations inherent in the tokens will be transferred along with them. For example, before closing an estate sale, a buyer's economic situation suddenly changes due to unemployment. The buyer can no longer purchase the estate. However, the buyer can find a new buyer who wants to take over all the rights and obligations represented by the Mithra tokens held by the buyer. Perhaps by requesting the seller's permission, the buyer can simply transfer the tokens to the new buyer, thus transferring ownership of the tokens. (Share)

[0112] Due to the Mithra contacts being presented in a human readable format via www representation, this new type of smart contract becomes shareable via a unique and verifiable link. The smart contract link of the present invention, where the smart contract is represented by a link, can now be shared privately within a group of people or shared publicly across social media or wider networks based on the visibility settings of the contract. (Search and Match)

[0113] The Mithra contract architecture opens the door for contract search and matching in a way that has never been done before.

[0114] Due to the searchable nature of Mithra contracts, combined with information searchability controlled by the contract issuer, users can now perform searches via searching open information in the Mithra contract web representation. The Mithra contract issuer will have full control over that information and will be able to control whether such information should be open, partially open, or completely hidden. (Permissions and Rights Management)

[0115] Each participant has different levels of permissions and rights to enable certain actions such as editing the contract, reviewing, signing, attaching documents, or transferring tokens. The rights are divided into two groups:

[0116] 1. Rights on existing objects - a set of permissions for users to exercise with created objects. This applies to Mithra contracts, Mithra swarms, Mithra tokens, and terms.

[0117] 2. Default Rights - A set of permissions that allows a user to act on objects that have not yet been created. Each group is divided into: Rights for specific users (accounts) Rights for everyone

[0118] The rights for a particular user (account) to a created object are configured by the user during the creation of the object, or set by another user with rights to this action.

[0119] Permissions for everyone (everyone) on a created object are configured when the object is created (false all) and may be changed by users who have the rights to do so. They can be adjusted by user actions with this object.

[0120] Default rights are granted by the user with rights to this action on objects that have not yet been created.

[0121] It is therefore possible to grant rights for users that will create groups (MG) in the Mithra contract, or that will create tokens (MT) in the Mithra group, or that will add conditions to the tokens. (default rights for a specific user (account))

[0122] Once a user who has default rights to create any object creates this object, the rights from the default are copied into the rights on this object for this user.

[0123] In the event that the address of the user to whom the default rights are desired to be granted is not known, the default rights for everyone are granted.

[0124] Each field in each structure is a specific right on a specific object. The following example illustrates the permissions associated with the Mithra contract rights structure. Permission[0]grantRevoke--the right to grant / revoke rights to actions using this MC Permission [1] viewing - the right to view the data in this MC Permission [2] editMetadata - the right to edit metadata within this MC Permission [3] createMG - the right to create an MG within this MC Permission [4] editMGDefaultRigfts - the right to edit the default rights for MGs created within this MC Permission [5] deactiveReactive - Right to delete / restore this MC Permission [6] attachDocument - the right to add a document to this MC

[0125] (Grant of Rights)

[0126] A user can acquire rights either by creating an object or by being granted rights by another user who has been given the right to grant rights. In order to grant a right to an object, the initiator of the transaction must himself possess the right.

[0127] grantRevoke on this object

[0128] A transactional(!) Msg.sender can only grant those rights to concrete objects it owns, i.e. if the initiator of a transaction does not own any rights, it cannot grant rights to other users. chat

[0129] In one embodiment, the dashboard provides enabled participants with a simplified method for creating communication channels, record keeping, and / or contracts. Participants can chat via three different types of chat methods: General chat

[0130] -This is the default chat setting. Participants use this as a communication channel regarding any subject they wish to communicate, discuss, or collaborate on. Regarding recorded chats within a contract or transaction

[0131] -Participants mutually agree to chat where the chat history will become a probative document or evidence for a particular contract or a legally binding compliance provision in itself within a transaction process. In this way, participants involved in a contract or transaction can collaborate via chat and support the process in a more complete way. Participants will be given two additional options after the chat: a. Attaching the chat history as documentation to a contract or transaction based on a specific token or where that chat is initiated.

[0132] b. Tokenize chat history as Mithra tokens. In this option, the requesting party will be prompted to enter metadata and required information to support the creation of a tokenized contract. The requesting party will be the party that issues the contract. All other participants will be issued their respective counter tokens, requiring their final digital signatures prior to smart contract execution.

[0133] -Details regarding legally binding compliance chat are illustrated in the following sections. · Legally binding compliance chat as the start of a new process or transaction

[0134] -Participants mutually agree to chat in a chat room where the chat history will become the state of a legally binding contract. In this way, the chat becomes the first step for the creation of a legally binding contract. This gives participants an easy interface for a traditionally cumbersome process.

[0135] At each step of the chat, participants will be given the option to import clause templates via keyboard search and / or other criteria search such as country, region, industry, or compliance regulation type. This will ensure that participants are guided by the appropriate legal clauses as far as the system allows.

[0136] -At the end of the chat, and upon request of any participant within the chat, the recorded chat will be tokenized into a tokenized contract. The requesting party will be prompted to enter metadata and required information to support the generation of the tokenized contract and its integration into the Mithra platform as a Mithra contract. The requesting party will become the party issuing the contract. All other participants will be issued their respective counter tokens. -All participants will be given the right to edit the terms and further negotiate the contract.

[0137] -All participants will be required to electronically sign the final smart contract before it can be executed.

[0138] The chat functionality described above is supported by messaging chat, voice chat, and video chat, however, as part of the legally binding compliance regulations for chat, all media must be converted to text. (Other features)

[0139] The system provides several other important functions to support the contract process. Manage user roles and responsibilities Adding attachments to a contract Download one of the available document types Create a PDF from your digital contract Save as a template (Common System Capabilities) There are several common foundational capabilities shared between template management and contract or project management: ·Master Data Management

[0140] o The Master Data Set is a common data set that can be used across various areas of the system. Master data is not constrained by templates, or contracts, or projects (transactions).

[0141] For example, industry, region, user role, estate, and agent master data for real estate, institution and medical practitioner master data for healthcare, university and course master data for education Metadata Management

[0142] o Metadata is a set of common data used for a specific template, project (transaction), contract or set of clauses (Mithra tokens). Metadata can be either common or industry / subject specific. It is retained across entities in the hierarchy.

[0143] For example, project name, project creation date, project template used, status, visibility flag (public or private) are a common set of metadata about projects, while property data such as real estate agent ID and property photos may be project metadata specific to the real estate industry.

[0144] ○ All project-level metadata is shared across contracts and Mithra tokens within a project. All contract-level metadata is shared across Mithra tokens within that contract. Metadata in lower levels of the hierarchy takes precedence over those in higher levels. For example, a procurement project has its visibility flag (metadata) setting at the project level set to “yes.” The project has 10 contracts, two of which have their visibility flag set to “no.” This means those two contracts are not publicly visible, while the other 8 contracts are available for public viewing or searching. Template creation

[0145] o As described in the previous sections, templates can be created either through the library or through the project area when a user saves a project template, contract template, or clause template for the first time. Template Update

[0146] o Similar to the template creation feature, templates can be updated via the user's library dashboard or within the project flow where the updated project, contract, or clause is saved. ·editor

[0147] Editors are used extensively across the system. Mithra Contracts has an in-line editor built in. This is used to create, edit, and manage templates, projects, contracts, and clauses, including metadata. ○ Both the input and output editors are in place.

[0148] ■ An example of an input editor is one where a user can load clauses for Mithra tokens from binary files such as Microsoft Office (.doc, .xls), Office Open XML (.docx, .xlsx), or OpenDocument (.odt, .ods). One of the implementations is that the document is parsed through the numbered list and headers. Each header or element of the numbered list becomes a clause. If it is a header, the header text becomes the name of the clause and the text following the header becomes the value of the clause. If there is no text following the header, the value of the clause is left empty. If the header has a numeral, this is saved as the numeral of the clause. Otherwise, this is calculated automatically. If it is a numbered list element and it is not a header, the name of the clause is left empty and only the numeral and value are assigned. The type of header (Header 1, Header 2, etc.) or the indentation of the numeral indicates the indentation of the clause. The clause ends where the next header or numbered element appears. Depending on the indentation, the numeral of the next clause is calculated. There is the ability to exclude some headers and numerals from being extracted as clauses.

[0149] ■Users can manage printable versions of contract or template outputs, either through predefined outputs where users upload their own PDF forms to be used as templates for the output, or through system-generated outputs where users can define headers, footers, styles, fonts, colors, etc. ·notification

[0150] Notifications - Email, SMS, and / or push notifications are used to alert of status changes, new invitations, new offers, revised contracts, etc. ·Clause Search Global Search · PDF generation Publish Workflow (Share)

[0151] Due to the Mithra contracts being presented in a human readable format via www representation, this new type of smart contract becomes shareable via a unique and verifiable link. The smart contract link of the present invention, where the smart contract is represented by a link, can now be shared privately within a group of people or shared publicly across social media or wider networks based on the visibility settings of the contract. (Example smart contract)

[0152] An example of a Mithra contract implementation definition is provided below. [Table 1-1] [Table 1-2] [Table 1-3] [Table 1-4] [Table 1-5] [Table 1-6] [Table 1-7] [Table 1-8] [Table 1-9] [Table 1-10] [Table 1-11] [Table 1-12] [Table 1-13] [Table 1-14]

[0153] Those skilled in the art will also understand, upon reading and understanding the many different descriptions herein, that the descriptions of specific embodiments are all illustrative and merely indicative of the many other descriptions not provided that may be within the scope of the invention enabled herein, the scope of which is limited only by the claims.

Claims

[Claim 1] The invention described in this specification.

Images