Patent Application
20220335553
The present invention relates to a system and a method for generating and managing machine executable digital data files. More specifically, the present invention relates to a system and a method for generating and managing machine executable digital contracts that comprise operative statements configured to control and/or monitor the operation of at least one contract input data source during the execution of the digital contract.
Developments in the field of decentralised computer architectures and distributed ledger technologies (DLTs) have greatly increased the need for digital contracts which can be used to define and manage the terms of a contractual agreement for the provision of services/products between at least two contractual parties. Such a digital contract would provide the capacity to assess, regulate and govern the performance of the contract. Current ‘smart contracts’ fail to achieve this as they do not in themselves have the capacity to enforce and execute the intent of the parties in contract; they are simple digital protocols that can be used to automate a small set of specific functions but not to provide governance of the contract to which they are an externality. In order to enable digital governance contracts, the digital protocol must become interchangeable with the legal contract. Only then, the digital protocol can be used interchangeably with the legal contract to automate the assessment, regulation and governance of contractual performance by monitoring and/or managing the operation of devices and/or systems involved in the provision of the services/products/transactions/settlements specified in the legal contract. The contractual parties are in general legal entities e.g. an individual, company, or organization that have legal rights and obligation. Digital contracts may be used in a variety of scenarios. For example, a digital contract may be used to monitor and manage a supply chain transaction system, with inputs from sensor devices in an Internet of Things (IoT) network, the operation of autonomous vehicles, robotic devices operating in an industry 4.0 factory facility and the like.
An electronic representation of a physical contract such as one generated by saving a PDF version of an electronically signed contract is an e-contract rather than a digital contract. It has no operative effect other than to act as a digital representation of a physical legal contract that can be stored immutably in a blockchain. In general, a digital contract can be considered as a computer digital transaction protocol that executes the terms of the underlying legal contract agreed between the parties.
Digital contracts are considered to provide a highly effective measure for enforcing and verifying the performance of a contract between at least two parties. However, this is not always the case. Digital contracts are in general a representation of the contractual terms of a contract document into an executable digital contract machine code. As such, the digital contract machine code may include software bugs introduced during the development and/or compilation phase of the digital contract, which interfere and seriously impact the performance and functionality of the digital contract with disastrous effects. For example, a software bug may introduce a security vulnerability into the digital contract, which can be exploited by unwanted parties to manipulate the functionality of the digital contract. Such a security vulnerability was exploited on The DAO in 2016, causing the loss of an estimate US$50 million, while developers were trying to find a credible solution to fix the issue. In the case, where a digital contract is used to manage the operation of a system and/or a device e.g. an autonomous vehicle, or robotic systems, the consequences resulting from a software bug in the digital contract may be of greater magnitude.
An object of the present invention is to provide a system and a method for generating digital contracts and corresponding underlying legal contracts containing the contractual terms and condition agreed between at least two parties.
The system and method of the present invention provides a solution for generating a digital contract and a corresponding underlying legal contract document, validating the executional performance of the digital contract before its execution by the intended application, and managing the executional performance of the digital contract during operation, and when necessary resolve dispute resolution issues arising between the contracting parties.
The object of the present invention is achieved according to the invention with the system and method showing the technical characteristics of the respective independent claims.
The following drawings are provided as an example to explain further and describe various aspects of the invention.
According to a first aspect of the present invention, a system for generating a digital contract is provided that executes the contractual terms of a corresponding underlying physical legal contract agreed between at least two parties. For example, the system may be in the form of a digital contract computer platform configured to generate, validate, manage, and monitor executable machine contract programmes representing corresponding digital contracts, each configured to control and monitor the operation of one or more contract input data sources.
According to embodiments of the present disclosure, the digital contract platform may be provided with
a User Interface, UI, accessible by at least one user through a computer device; and
a digital contract generation logic configured to generate and manage at least one digital contract, based on input data received from the at least one user through the User Interface, UI.
According to embodiments of the present disclosure, the digital contract generation logic may be provided with a source data file generation logic, SDFGL, configured to generate, based on input data received from the at least one user through the User Interface, a source data file representing a first version of a physical legal contract comprising a set of operative statements, each comprising operative data comprising a set of contract conditions under which the parties agree to act during the term of the digital contract and a set of contract data inputs associated with at least one contract input data source.
According to embodiments of the present disclosure, the digital contract generation logic may be provided with a parser logic configured to analyse the source digital data file and at least extract the operative data from each operative statement, the parser logic comprising a machine contract generation logic, MCGL, configured to generate, based on the extracted operative data, a machine contract programme containing a set of software programme statements representing the extracted operative data, which machine contract programme is compiled to generate an executable machine contract programme representing the digital contract executing the operative statements contained in the source digital data file.
According to embodiments of the present disclosure, the digital contract generation logic may be provided with a machine contract validation logic, MCVL, configured to validate the enforceability and/or functionality of the generated machine contract programme by at least the parser logic may comprises a machine contract generation logic, MCGL, that is configured to generate, based on the extracted operative data, a machine contract programme containing a set of software programme statements representing the operative data extracted from the source data file. For example, the software statements may be in the form of IF CLAUSES, MAIN BODY, LOOPS, CALLS, and the like. file. The machine contract programme may be validated by means of machine contract validation logic, MCVL, which is configured to check the enforceability/applicability of the operative statements and the executional performance of the digital contract during operation. The MCVL generates a set of test conditions, also referred to as test cases or test scenarios, for the machine contract programme, which may involve varying the values of variables and/or vectors in the machine contract programme and recording the corresponding output values generated from each test condition. For example, the variable and/or vectors may be the contract inputs, libraries, classes, functions, object, and the like. The output values may be associated with corresponding operative statements. For example, the output values generated may be provided as input to the parser logic, or another software programme, whereby the output values are parsed to generate operating statements. The operative statements may be generated by associating each possible output value to a machine contract programme, based on the characteristics of the machine contract programme e.g. inputs, functions, classes, libraries, objects, calls, and the like. Each generated operative statement may be assigned a risk factor value. The risk factor value may indicate the applicability of each operative statement to the legal contract, based on the output values generated from the execution of each test case. The applicability of each operative statement may be linked to how enforceable each operative statement, and the contractual conditions contained therein, may be during execution. The enforceability data may be derived from historical data collected from each operative statement during execution or may be calculated based on a risk analysis statistical model using historical data provided by the user, and/or stored in a database e.g. a knowledge graph database. Furthermore, the risk factor may indicate whether the generated machine contract programme contains any vulnerabilities, which may affect adversely the execution of the digital contract during operation. For example, the machine contract programme may not respond as expected in one of the test cases applied by the MCVL, which may indicate a potential coding issue that needs to be fixed before the digital contract becomes operational. The MCVL is configured to generate, based on the value of the risk factor assigned to the operating statements generated from each test case, a validation signal indicating the successful validation of the machine contract programme, or an alert signal indicating a potential issue with machine contract programme code. For example, if the risk factor value is within a first performance threshold range, a validation signal may be generated, while if the risk factor value is within a second performance threshold range an alert signal may be generated. the validation signal may indicate that the machine contract programme is considered e.g. up to a certain degree, to represent the contractual conditions specified in the operative statements of the source digital data file and/or expected output values for each test case. An alert signal may indicate an issue with the applicability and/or enforceability of the operative statements. An alert signal may also indicate an issue with the execution of the digital contract. For example, if the risk factor has a specific value e.g. “0”, an alert signal may be raised indicating that the digital contract contains a serious issue that needs to be fixed before execution. In the case of an alert signal, the system of the present invention enables the at least one user to review and amend the affected portions of the source data file and/or the machine contract programme. For example, the at least one user may replace and/or amend defective operative statement. The updated source data file and/or machine contract code is re-validated using the parser and/or the MCVL. Once a validation signal is received, the source data file is converted into a master digital data file representing the underlying legal contract containing the contractual terms and conditions executed and/or monitored by the digital contract. The system of the present invention may be configured to communication with the users and/or parties via other communication means, such as email, online repositories, and the like. The at least one user and parties may review the master digital data file. Upon approval, the master digital datafile and the corresponding machine contract programme are stored in a versioned database e.g. Distributed Ledger Technology (DLT). In the case the at least one user and/or parties o not approve the master digital data file or want to make amendments, then the process starts at the appropriate step. The master digital data file may be a printable document, which has been generated based on a user selected contract template. The version database may be accessible by software applications linked to the digital contract and configured to execute the digital contract. The version database may be configured to record and store the data transmitted during the execution of the machine contract programme by the parties and their respective applications.
According to embodiments of the present invention, the source data file generation logic, SDFGL, comprising
a semantic search query generation logic, SSQGL, configured to generate, based on information extracted from the user input data, at least one search query comprising a plurality of search criteria;
a knowledge database system comprising an operative statement database containing a plurality of operative statements each tagged with a set of metadata information, and a semantic search engine configured to execute the at least one search query generated by the SSQGL so as to identify and retrieve from the operative statement database a set of operative statements associated with metadata information matching the search criteria of the at least one search query; and
a document generation logic configured to present to the user for selection, through the User Interface, the operative statements retrieved from the operative statement database, and, based on the user selection, to generate the source digital data file.
It has been found that the present invention allows for the at least one user to generate a source digital data file with relative ease. The SDFGL allows the at least one user to identify and select operative statements that are relevant for the intended application of the digital contract. The system of the present invention allows for operative statements to be retrieved from an operative database based on search queries generated from input data provided by the users. The operative database contains a plurality of operative statements each one tagged with metadata information comprising among other descriptive information about the operational statement. The search queries generated contain search criteria formatted according to the operative database that is used for storing the operational statements. The operative database may be communicatively coupled to a semantic search layer, which may be responsible for executing the search queries generated by the semantic search query generation logic, SSQGL. For example, the user may input through the user interface a set of descriptive keywords which are converted into a structured search query that may be used by the semantic search layer to retrieve information from the operative database. For example, the keywords may be a set of criteria relating to the intended use of the digital contract, the type of parties involved, the desired risk factor value for operative statement, and the like. The semantic search layer, based on the keywords, may search in the operative database system to identify operative statements that match at least some of the search criteria. The semantic search engine and the operative database may be part of knowledge database system. The operative statements retrieved from the operative database may be communicated to a document generation logic, which may be configured to display the search results to the at least one user for selection. The document generation logic may categorise and/or classify the search results containing the retrieved operative statements, according to user preferences, or other parameters e.g. relevancy. The operative statements selected by the user may be collected and used by the document generation logic to generate the source digital data file. The document generation logic may generate the source digital data file based on a template, which may be selected by the user. For example, the source document data file may be generated based on a physical contract document template. In the case that the user provides a digital document e.g. a contract as input data, the source data file generation logic, SDFGL may be configured to check the compatibility of the digital document e.g. language, structure, syntax compatibility, and accordingly is either use the user digital data file as source data file, or if an compatibility issues is detected, the convert the user digital data file content into a source digital data file.
According to embodiments of the present invention, the metadata information comprising a risk factor, and/or a classification, and/or an ontology associated with each operative statement. The metadata information may be collected from a plurality of sources e.g. during the execution of the operative statement. For example, the metadata information may indicate a risk factor for each operative statement, which may have been assigned with a call to the Risk Analysis Engine or with historical data collected during the execution of the operative statement by a related process e.g. by another programme. For example, the risk factor value may be assigned based on a) a statistical computation or tagged by a user or another process, b) queries to the graph database of the knowledge database system. The metadata information may further contain information relating to the ontology of each operative statement, which provides information on the properties of each operative statement and relationship and/or dependencies with other operative statements in the operative statement database. For example, the metadata information may indicate that the selection of an operative statement requires the integration in the digital contract of other dependent and/or related operative statements. Furthermore, the metadata information may include expected output values of each operative statement for different input value combinations, which may be used by the parser logic to identify the operative statements corresponding to each output value.
According to embodiments of the present invention, the operative statement database is a graph database. The use of a graph database enables the navigation and search through complex datasets with or without structured queries. Graph databases comprises a set of nodes and the relationships that connect them. In a graph database storing operative statements, each node may be configured to store at least one operative statement together its metadata information. Graphs represent entities as nodes and the ways in which those entities relate to the world as relationships. In this way, the use of graph databases enables to express complex relationships between node, or in our case operative statements, which enables the modelling of different scenarios. For example, the use of graph database for storing operative statements enables the modelling of different scenarios with regards to the enforceability of each operative statement during the execution of the digital contract e.g. the enforceability and performance of an operative statement during execution of the digital contract for different input data values. Querying relationships between operative statements within a graph database can be retrieved quickly, since the information is stored within the database itself. The relationships and/or dependencies between the operative statements can be visualised for easier navigation of heavy interconnected datasets. related is fast because they are perpetually stored within the database itself.
According to embodiments of the present invention, the least one search query is in a graph search query language. In order to access a graph database, the search query needs to be structured in specific format, which is closer to how the data is modelled in the graph database. A graph database query language may be used to prepare the search query e.g. the search query may be prepared in Cypher, SPARQL, or another graph database language.
According to embodiments of the present invention, the knowledge database system, comprises a knowledge graph logic configured to update and/or enrich the operative statements and associated metadata information stored in the operative database with information received and/or retrieved from a plurality of knowledge data sources. For example, the plurality of knowledge data sources may comprise external connected devices and systems, and/or the output values generated from the machine contract validation logic, and/or information received from the at least one user and/or the administrator of the system. The knowledge graph logic is configured to maintain the information stored in the operative statement graph database up to date. The knowledge graph logic is communicatively coupled to the different knowledge data sources, which includes external and/or internal data sources e.g. external devices and/or data generated from system modules. The knowledge graph logic may be configured to update the content of the graph database as soon as data becomes available and/or in batches e.g. from cached content. The knowledge database system may be configured to issue an update signal each time there is an update to the content of the graph database. For example, if there is an update on the content of the operative statements and/or the metadata information e.g. a change in the risk factor assigned to an operative statement, then an update signal may be issued indicating the presence of updated data in the graph database. In the case of digital contract, an update in the content of an operative statement e.g. a change in the risk factor, may necessitate a change in the digital contract or the revalidation of the digital contract. For example, after an update, an operative statement may be considered to be not applicable or unenforceable, thus necessitating a change in the source data file.
According to embodiments of the present invention, the knowledge graph logic comprising a set of trained algorithms configured to update and enrich the operative statements and associated metadata information. The knowledge graph logic may include an artificial intelligence algorithm that continuously updates the content of the operative database with data collected and/or retrieved from the plurality of sources.
Furthermore, the knowledge graph logic algorithms may learn from the use of the operative data in different digital contract scenarios, and accordingly may enrich the content of the graph database e.g. by creating new relationship links between statements, updating the risk factor value, updating the expected output values for each operative statement, and the like.
According to embodiments of the present invention, the machine contract programme and master digital datafile are hashed and stored in the versioning database. Preferably, the system of the present invention cryptographically signs and hash the generated digital data files and corresponding machine contract programme for each digital contract, which are subsequently stored in a versioned database. In this way, it becomes difficult to alter the content and/or functionality of a digital contract.
According to embodiments of the present invention, the MCVL is configured for validating the machine code program by:
The system of the present invention enables the validation of the digital contract under different test conditions before its execution by the intended application. In this way, it becomes possibly to identify cases in which the digital contract may not perform as expected e.g. because of a software bug, or due to the enforceability of an operative statement. The MCVL executes the machine contract programme for a set of test conditions. For example, each test condition may involve applying different value combination to variable and/or vectors of the machine contract programme, which may include the contract input values, classes, libraries, functions, object, and the like. For each test condition, the system is configured to store the output values generated. The MVCL may map each output value to a corresponding operative statement. For example, the MCVL may be provided with a MCVL local database storing operative statements and expected outputs for different input value combinations. Furthermore, the MCVL may submit the output values generated to the parser logic, or another software programme, where they are processed and associated with an operative statement. For example, the parser logic may initiate queries to the operative database of the knowledge database system to identify operative statements corresponding to the output values generated. The MCVL may be provided with a risk analysis engine, which is configured to analyse the output values generated and accordingly assign a risk factor.
According to embodiments of the present invention, the risk analysis engine is configured to assign a risk factor to an operative statement, based on metadata information stored in the graph database. According to embodiments of the present invention, the risk analysis engine comprises a statistical risk calculation engine configured to calculate a risk factor based on historical information associated with an operative statement.
The risk analysis engine may assign the risk factor, based on information stored in the MCVL local database, and/or based on statistical models generated from historical information relating to the performance of specific operative statement. The historical information may be retrieved from external data sources e.g. external databases, or internal data sources e.g. MCVL local database and/or the graph database. For example, the historical information may be retrieved from the metadata information stored in the knowledge graph logic, and/or retrieved from external information sources such as external system databases.
According to embodiments of the present invention, the contract generation logic comprising a performance monitoring module communicatively coupled to contract input data sources associated with a machine contract programme, the performance monitoring module being configured for evaluating, based on input data received from connected contract input data sources, the performance of the machine contract program.
The performance monitoring module may allow the monitoring of the executional performance of a machine contract programme. The performance monitoring module may enable a user and/or a party to the contract to determine if the digital contract is executed as agreed. The performance monitoring module may be configured to receive data generated during the execution of the digital contract from the identified contract input data sources. For example, the performance monitoring module may be communicatively coupled e.g. via an Application Programming Interface (API), directly to the contract input data sources identified in the digital contract, and/or may be coupled to an information repository storing information collected from the contract input data sources during the execution of the digital contract. For example, the performance monitoring module may be configured to assess the performance of a Service Level Agreement (SLA) between a user and cloud provider based on information received from the cloud servers of the cloud provider on the use and reliability of the service agreed in the digital contract. Furthermore, the performance monitoring module may be configured to receive information directly from the digital contract parties regarding the executional performance of a digital contract. For example, a party may raise through the performance monitoring module a dispute issue relating to the incorrect execution of a digital contract or a part of the digital contract by the other party or parties.
According to embodiments of the present invention, the performance monitoring module is configured to periodically validate the performance of a machine contract programme stored in the version database by resubmitting it for validation to the machine code validation logic, MCVL. According to embodiments of the present invention, the step of resubmitting the machine contract programme to the machine code validation logic, MCVL, is triggered by an updated of the content of the operative statement database.
In this way, it is possible to evaluate the performance of the digital contract and associated operative statements over the validity period of the digital contract between the parties. An update in a company or government policy may render an operative statement unenforceable and/or invalid under certain conditions. For example, an update in the government policy with regarding the speed to be maintained by an autonomous vehicle on the road during heavy traffic, may render an operative statement invalid e.g. the operative statement does not provide a speed limit while the update government policy does provide a strict speed limit. Therefore, by resubmitting periodically each of the machine contract programmes stored in the versioned database to the MCVL, may enable the continuous assessment of the executional performance of the digital contract during the course of its validity period, and reduce the risk that the digital contract or parts of the digital contract become enforceable and/or invalid. The resubmission of a machine contract programme to the MCVL may be triggers by an update signal issued by the knowledge database system e.g. the knowledge graph, indicating an update in the content of the operative database. For example, the risk factor of some of the operative statements may be updated on a regular basis, which may impact the performance and/or validity of the digital contracts containing the updated operative statements e.g. because the risk factor of the operative statements would be below the performance threshold.
According to embodiments of the present invention, the performance monitoring module is configured, upon detecting an executional performance issue with a machine contract programme and/or receiving a dispute communication from at least one of the parties and/or at least one user, for issuing a dispute notification signal. According to embodiment of the present invention, the performance monitoring module comprises a dispute resolution engine configured, upon the issuance of a dispute notification signal, to activate a dispute resolution event sequence, and notify the parties involved and/or at least one user of the suspension of the disputed contract. According to embodiments of the present invention, the dispute resolution engine is configured to suggest dispute resolution proposals to the at least one user and/or parties for resolving the contract dispute, and wherein upon an acceptance by the parties and/or at least one user of a dispute resolution proposal, the dispute resolution engine being configured to regenerate a master digital data file and corresponding machine contract programme for the disputed contract. According to embodiments of the present invention the dispute resolution proposal comprise a set of operative statements retrieved from the knowledge database system.
The dispute resolution engine enables the quick and easy resolution of disputes arising between parties e.g. due to the incorrect execution of a digital contract term. The dispute resolution engine may assess the cause of the dispute resolution and accordingly suggest resolution proposals. For example, the dispute resolution engine may use the risk assessment engine to assess the risk in resolving a dispute. Furthermore, the dispute resolution engine may check the content of the operative database to determine if a similar dispute has been previously resolved. For example, the information relating to the dispute resolution arising by the execution of an operative statement may be part of the metadata information linked to each operative statement. Further, the dispute resolution may communicate the dispute to a dedicated dispute resolution centre that explicitly deals with disputes e.g. a dispute resolution panel. The dispute resolution engine based on the input of the dispute resolution centre or the dispute resolution information extracted from the operative database may proposed a set of resolution proposals to the parties e.g. amendments and/or actions to be taken.
According to embodiments of the present invention, the performance threshold is selected by the parties and/or the at least one user.
According to embodiments of the present invention, the operative statements indicate a set of instructions for controlling the operation of at least one contract input data source during execution of the digital contract. For example, the operative statements may comprise instructions that determine the operation of a remote device during the execution of the contract e.g. an autonomous vehicle, factory robots, digital devices, and the like. The system of the present invention may ensure that the device operation complies with the terms of the digital contract during its execution.
According to embodiments of the present invention, the at least one contract input data source is a device and/or a system configured for transmitting data collected from a predetermined environment. For example, the digital contract may be configured to monitor a range of sensors and/or devices in an Internet of Things network. The system of the present invention may be configured to monitor the operation of range of devices, and based on the information received, to assess the executional performance of the digital contract.
According to embodiments of the present invention, the at least one contract input data source is part an Internet of Things, IoT, infrastructure. According to embodiment of the present invention, the contract input data source comprises at least one IoT sensor.
According to embodiments of the present invention, the UI comprising a set of input and output data fields. For example, the User Interface (UI) may comprise a range of input fields to be used by the user to provide information to the system for the generation of a source digital data file. Furthermore, the UI may comprise a range of output fields, which may be used by the system to display information to the user e.g. the list of operative statements for selection, and/or a viewing window for the viewing the master digital data file. The UI may comprise a number of windows and graphical objects that may be used for the exchange of information between the user and the system of the present invention, and/or the user and other user sharing the same session.
According to embodiments of the present invention, the system may be configured to open for each user a unique user session, which may be shared with other users e.g. the parties to the digital contract. The sharing of the session may be performed through a unique identification number or token, which may be shared with other users to access details of the session, and/or perform operations e.g. providing information required for the generation of the digital contract, and/or sign and confirm the digital contract, and/or make or propose amendments.
According to embodiments of the present invention, the digital contract generation logic comprises a cryptographical module comprising a set of cryptological protocols for hashing, digitally signing and encrypting data stored in the versioned database. For example, the cryptological module may be in the form of a software library that includes software functions like hash, encrypt, sign, verify, etc, and may be appended/linked to the machine contract programme.
According to a second aspect of the present invention, a method is provided for generating digital contracts, each digital contract comprising a master digital data file and a corresponding machine contract programme, each contract being configured to govern a transactional relationship between at least two parties, the method comprising:
generating, validating, and managing, by means of a digital contract generation logic, at least one digital contract from input data received from at least one user and by:
exchanging data, through a User Interface, UI, with at least one user the UI being accessible through at least one computer device;
receiving input data, by means of a source data file generation logic, SDFGL from the at least one user through the User Interface, the SDFGL being configured to propose, based on the user input data, a set of operative statements to the user for selection, the SDFGL being configured to generate, based on the user-selected operative statements, a source digital data file, wherein each operative statement comprising operative data comprising a set of instructions controlling the operation of the digital contract and a set of contract data inputs, each contract data input being associated with at least one data source;
analysing, by means of a parser logic, the source digital data file and least extracting the operative data from each operative statement, the parser logic comprising a machine contract generation logic, MCGL, configured to convert the extracted operative data, a set of software programme statements, and generate, based on the set of software programme statements and contract data inputs defined in the operative data, a machine contract programme written in a source language corresponding to the source digital data file, the MCGL is configured, based on the type of the logical operations executed in the software programme statements and associated contract data inputs and data sources, to append to the machine contract programme a set of calls to software libraries and/or classes for the execution of the machine contract programme;
wherein, when the assigned risk factor of each output value is equal or above a performance threshold, the MCVL is configured to issue a validation signal indicating a successful validation of the executional performance of the generated machine contract programme, and
wherein, when the assigned risk factor of at least one output value is below the performance threshold, the MCVL is configured to issue an alert signal to the user indicating a potential issue with the executional performance of the machine contract program, which needs to be resolved;
generating, by means of a master data file generation logic, MDFGL, upon receiving a validation signal, a master digital data file from the source data file, the master digital data file and/or the machine contract programme being transmitted, through the User Interface and/or a preferred communication medium, to the at least one user and/or directly to the parties identified in the source data file for an agreement confirmation and signature, the MDFGL being configured, upon receiving the agreement confirmation and signature, to store the master digital data file and the corresponding machine contract programme to a versioned database.
The present invention will be illustrated using the exemplified embodiments shown in the
Once the source digital data file has been created, a parser logic 230 is used to analyse the source digital data file. The parser logic may be a computer software program that parses the source digital data file to extract operative data from each operative statement. The parser logic 230 may extract from the source digital data file a range of information e.g. the structure and format of the file, the logical operations involved in the operative statements, the contract data inputs, expected outcomes, and the like. As shown in
comprising a set of software programme statements. For example, the software logic may use the operative data as keywords to search to a linked database for applicable software statements, and accordingly generate a machine contract programme containing software statements that call the specific sector of the linked library. For example, the MGCL takes the operative data as inputs and with text analytics searches Machine Contracts libraries, then associate the operative data to the relevant sectors of the Machine contract libraries and generates a machine contract programme containing software programme statements that call the specific sectors of the linked libraries and associated commands. For example, the software statement generation logic 2321 may generate an if-else conditional statement to represent the conditional statement logical operations involved in an operative statement of the source data file. The MCGL 232 may comprise a software module selection logic 2322 which is configured to select a set of software modules e.g. software libraries, classes, Application Programming Interface (API) calls to 3d party interfaces, and the like, to be linked to the generated software statements. The software modules may be selected based on the type of operations involved in the software programme statements and associated contract data inputs and data sources. The MCGL 232 may comprise a MC programme generation logic 2323 configured to generate a machine contract programme comprising the generated software statements and links to the selected software modules, which are called during the execution of the digital contract. The machine contract programme is written in a desired programming language. Although not shown in
The digital contract platform 200 may be provided with a performance monitoring module 270 configured to monitor the execution of a digital contract by monitoring the operation of the corresponding contract input data sources. The performance monitoring module 270 may be communicatively coupled to the contract input data sources associated with a machine contract programme. The performance monitoring module 270 may be configured for evaluating, based on input data received from connected contract input data sources, the performance of the machine contract program. As a result, with use of a performance monitoring module 270 it may be possible for a user to manage the execution of a digital contract. For example, the performance monitoring module may be communicatively coupled e.g. via an Application Programming Interface (API), directly to the contract input data sources identified in the digital contract, and/or may be coupled to an information repository storing information collected from the contract input data sources during the execution of the digital contract. The performance monitoring module 270 may be configured to periodically submit the machine contract programmes stored in the versioning database for revalidation to the MCVL 240. In this way, it may be possible to revaluate the executional performance of a digital contract over the validity period of the contract and account for updates in the operative statements metadata information. For example, an update in a company or government policy may render an operative statement unenforceable and/or invalid under certain conditions. Furthermore, the performance monitoring module 270 may be configured to receive information directly from the digital contract parties regarding the executional performance of a digital contract. For example, a party may raise through the performance monitoring module 270 a dispute issue relating to the incorrect execution of a digital contract or a part of the digital contract by the other party or parties. the performance monitoring module 270 may be configured upon detecting an executional performance issue with a machine contract programme and/or receiving a dispute communication from at least one of the parties and/or at least one user, for issuing a dispute notification signal. A dispute resolution engine 280 may be provided for handling the dispute resolution. For example, the dispute resolution engine 280 may be configured, upon the issuance of a dispute notification signal, to activate a dispute resolution event sequence, and notify the parties involved and/or at least one user of the suspension of the disputed contract. The digital contract platform may be provided with a communication module 295, which may be used for the exchange of data between the digital contract platform and external modules e.g. the contract input data sources.
Alice contracts to sell to Bob goods that conform to the following characteristics: goods will be delivered by a certain date; goods will satisfy certain quality metrics; goods will satisfy certain quantity metrics; the price of the goods will depend on the goods satisfying the conditions above.
1) Alice and Bob write a Draft Contract, that is submitted as input data to the digital contract platform 200 via the User Interface 210 where it may be digitalised, digitally saved and stored on the master versioning database 260, e.g. a DLT.
2) The Draft Contract is digitally signed and stored on the DLT that can be accessed by both Alice and Bob.
3) The Draft Contract is submitted to the SDFGL 220, where it is used to generate a Source Data File (SDF) by means of a parser, which extracts from the draft contract operative data like sector (supply chain/logistic), principals (Alice and Bob), type of transaction (sale), inputs (price of the goods, goods quantities, good qualities). The parser 230 may further extract the contractual terms and conditions specified in the draft contract.
4) The SDF is submitted to the MCGL 232 that parses the SDF, extracts operative data (i.e. supply chain, Principals, type of assets, operative statements etc) and converts the operative data to software statements that write calls the appropriate libraries (supply chain trading programmes), the appropriate functions (sale), appropriate variables and objects for goods. Operative statements such as contractual terms and conditions existing in the SDF are converted to software IF CLAUSES. The output is the Machine contract, that is submitted to a version-controlled repository.
5) Alice and Bob agree on a risk threshold and on a set of Operative Statements, that are submitted to the Knowledge Database System 222.
6) The Machine Contract is either compiled or interpreted into Machine Code and is submitted to the MCVL 240, which validates the machine contract programme by running the code with all the possible inputs and calls to all the possible functions, classes and libraries. The outputs and related inputs are sent to the Risk Analysis Engine that runs a set of risk algorithms and labels the outputs with their related risk factor. Then the outputs and related inputs are sent to the SDFGL that, with a parser or text analytics algorithms, embeds the outputs to text sentences like “If beetles are found in the packing case then the goods will be rejected regardless of whether there is any damage to the goods”, that becomes and Operative Statement and with its related risk factor is submitted to the Knowledge Database System.
7) If any of the outputs has a critical risk factor like zero then a major software bug/vulnerability has been detected and a request of change is flagged. The machine contract is changed and resubmitted.
8) The Draft Contract is submitted to a text analytics engine, which outputs Knowledge Database Systems queries that generates Operative Statements with related risk factors. For example, the query would be, what are the Operative Statements and related Risk Factors that covers cases in supply chain, with certain goods, on these markets?
9) Now there are 3 sets of Operative Statements with risk factors. The ones as output of the MCVL, the ones agreed by Alice and Bob, the ones as output of the queries of the text analytics engine. All of those that have a risk factor higher than the decided threshold are appended to the SDF, the output is a Legal Contract, that is digitally signed by Alice and Bob, hashed and submitted to a DLT that can be accessed by both Alice and Bob.
If a dispute is generated between Alice and Bob, a Trade Dispute is flagged and written as an Operative Statement. That is an input to the text analytics engine and its outputs, together with any type of type of sensors reading (like IOT) and the output become Knowledge Database System queries, that generates Operative Statements with related risk factor. Alice and Bob are asked to review and if they agree to append the new Operative Statements to the Legal Contract. If they disagree a panel of experts is asked to review. Depending on the decision a Legal Contract is digitally signed, hashed and submitted to a DLT that can be accessed by all the Principals or a subset of them. The New Operative Statements are also submitted to the SDFGL, the MCGL and the MCVL and a new Machine Contract is generated.
Alice contracts to sell to Bob goods that utilise third party logistics services from Charlie. Charlie would contract with Alice to deliver the goods to Bob. To do so, he would collect the goods from Alice when instructed, compliantly transport (for example, maintaining temperature) and deliver those goods to Bob. Once the goods are ready for collection from Alice, a networked device, such as computer device running a software programme, would prompt Charlie to dispatch a truck to collect the goods, indicating the temperature at which the goods must be transported, and how the goods should be handled and any special notices about the goods such as whether or not they contain any hazardous materials. Upon delivery of the goods to Bob's premises as directed by the digital contract, a computer device would log the delivery e.g. a computer device running a software programme, and generate a signal confirming the delivery on a networked device, which would be communicated to the application executing the digital contract to indicate that some or all of the terms and conditions relating to the delivery of goods from Alice to Bob have been performed and that all of the conditions for payment of Charlie by Alice have been performed, enabling the digital contract between Alice and Bob and the digital contract between Alice and Charlie to operate accordingly. In general, the system of the present invention may be used by the contractual parties to generate the digital contract governing their contractual relationship, as followed:
1) Alice and Charlie write a Draft Contract, that is digitalized, digitally saved and stored on a DLT.
2) The Draft Contract is digitally signed and stored on a DLT that can be accessed by both Alice and Charlie.
3) The Draft Contract is submitted to the SDFGL, a parser extracts operative data like sector (supply chain/logistic), principals (Alice and Charlie), type of transaction (service), inputs (weight of goods, dimensions of goods, distances between where the goods are collected and where they are deposited), the relevant operative elements of the contract between Alice and Bob and outputs a SDF, such as the relevant contractual clauses.
4) The SDF is submitted to the MCGL that converts the operative data to software statements that write calls the appropriate libraries (supply chain logistics programmes), the appropriate functions (service), appropriate variables and objects for logistics. Operative statements existing in the SDF are converted to software statements e.g. IF CLAUSES. The output is a Machine contract programme, that is submitted to a version-controlled repository.
5) Alice and Charlie agree on a risk threshold and on a set of Operative Statements, that are submitted to the Knowledge Database System.
6) The Machine Contract is compiled or interpreted into Machine contract Code and is submitted to the MCVL, that runs the code with all the possible inputs and calls to all the possible functions, classes and libraries. The outputs are sent to the Risk Analysis Engine that runs a set of risk algorithms and labels the outputs with their related risk factor. Then the outputs are sent to the SDFGL that converts the outputs in Operative Statements that are submitted to the Knowledge Database System that updates its graph database.
7) If any of the outputs have a critical risk factor like zero then a major software bug/vulnerability has been detected and a request of change is flagged. The machine contract is changed and resubmitted.
8) The Draft Contract is submitted to a text analytics engine and it outputs Knowledge Database Systems queries that generates Operative Statements with related risk factors.
9) Now there are 3 sets of Operative Statements with risk factors. The ones as output of the MCVL, the ones agreed by Alice and Charlie along with those that have operative effect in the digital contract between Alice and Bob and the ones as output of the queries of the text analytics engine. All of those that have a risk factor higher than the decided threshold are appended to the Draft Contract, the output is a Legal Contract, that is digitally signed by Alice and Charlie, hashed and submitted to a DLT that can be accessed by both Alice and Charlie.
If a dispute is generated between Alice and Charlie, a Trade Dispute is flagged and written as an Operative Statement. That is input to the text analytics engine and its outputs, together with any type of type of sensors reading (like IOT) and the output become Knowledge Database System queries, that generates Operative Statements with related risk factor. Alice and Charlie are asked to review and if they agree to append the new Operative Statements to the Legal Contract. If they disagree a panel of experts is asked to review. Depending on the decision a Legal Contract is digitally signed, hashed and submitted to a DLT that can be accessed by all the Principals or a subset of them. The New Operative Statements are also submitted to the SDFGL, the MCGL and the MCVL and a new machine contract is generated.
The legislator creates a set of laws governing the use of self-driving vehicles in private and commercial contexts. A regulator is created whose role is to ensure compliance with these rules by private and commercial operators of self-driving vehicles. That regulator wishes to ensure that compliance is built into the operation of these vehicles, so the operating code of the self-driving vehicle is made subject to the governance of the regulator and a digital contract is created between the regulator and the regulated operating software of the self-driving vehicle).
There would only be one party to the digital contract that can change the terms and they may do so unilaterally with decisions informed to the regulated counterparties. The Regulator would therefore
1) Have the legislation (draft contract) digitalised, digitally saved and stored on a DLT.
2) The Draft Contract is digitally signed and stored on a DLT that can be accessed by any relevant party (such as Charlie) but only edited and amended by the Regulator.
3) The Draft Contract is submitted to the SDFGL, the parser extracts operative data like sector (rules of the road, vehicular transportation), principals (regulator and regulated), type of transaction (governing regulation), inputs (speed limits, usage limits, compliance with signage, load limits, etc.), the relevant operative elements of the legislation and outputs an SDF.
4) The SDF is submitted to the MCGL that converts the operative data to software statements that write calls the appropriate libraries (rules of the road, logistics, transport, vehicular use), the appropriate functions (regulation), appropriate variables and objects for the use of self-driving vehicles. Operative statements existing in the SDF are converted to software IF CLAUSES. The output is the Machine contract, that is submitted to a version-controlled repository.
5) The Regulator sets a risk threshold and on a set of Operative Statements, that are submitted to the Knowledge Database System.
6) The Machine Contract is compiled or interpreted into Machine Code and is submitted to the MCVL, that runs the code with all the possible inputs and calls to all the possible functions, classes and libraries. The outputs are sent to the Risk Analysis Engine that runs a set of risk algorithms and labels the outputs with their related risk factor. Then the outputs are sent to the SDFGL that converts the outputs in Operative Statements that are submitted to the Knowledge Database System that updates its graph database.
7) If any of the outputs have a critical risk factor like zero then a major software bug/vulnerability has been detected and a request of change is flagged. The machine contract is changed and resubmitted.
8) The Draft Contract is submitted to a text analytics engine and it outputs Knowledge Database Systems queries that generates Operative Statements with related risk factors.
9) Now there are 3 sets of Operative Statements with risk factors. The ones as output of the MCVL, the ones set by the Regulator and the ones as output of the queries of the text analytics engine. All of those that have a risk factor higher than the decided threshold are appended to the Legislation (Draft Contract), the output is a Legal Contract of Regulation, that is digitally signed by the Regulator and all of the Regulated, hashed and submitted to a DLT that can be accessed by both Regulated and Regulator.
If a dispute or query is generated by a Regulated entity seeking clarification of rules, a Dispute is flagged and written as an Operative Statement. That is input to the text analytics engine and its outputs, together with any type of type of statistical data supporting the proposition and the output become Knowledge Database System queries, that generates Operative Statements with related risk factor. The Regulator is asked to review and if they agree to append the new Operative Statements to the Legal Contract. If they disagree a panel of experts is asked to review. Depending on the decision a Legal Contract is digitally signed, hashed and submitted to a DLT that can be accessed by all the Regulator and the Regulated. The New Operative Statements are also submitted to the SDFGL, the MCGL and the MCVL and a new machine contract is generated.
This in turn creates operative code that would be required to be inserted into any digital contract by commercial operators such as Charlie in example 2.
Charlie therefore has to insert certain operative clauses into any contract he has, such as that self-driving vehicles cannot be used in certain weather conditions and therefore Charlie cannot collect, transport or deliver in such conditions.
Further, Charlie cannot undertake a contract with Alice that would require that Charlie's self-driving vehicle exceeds the speed limit on the routes that would be used in the performance of the contract between them as the operative code of the Regulator cannot be disregarded.
The Regulations thus have an overriding effect on the contracts that it impacts and compliance with the regulations can be said to be both automated and complete.
Autonomous vehicles would need to be continuously controlled and monitored to ensure that they operate according to a set of criteria and guidelines on how to operate in specific situations. It is expected, depending on the use of the autonomous vehicles, that different categories of autonomous vehicle would exist. Each category would be required to abide by a set of specific criteria. For example, certain vehicle may be used for transportation e.g. buses, trucks, taxis, and the like, while others may be used for personal use. It is expected that autonomous vehicles would include Artificial Intelligence algorithms e.g. machine learning algorithms, that would help them continuously learn and adapt to their surroundings. Therefore, the behaviour and operation of the autonomous vehicles would change over time. As such it is essential that the operation of the autonomous vehicle is controlled and continuously monitored.
In order to control and monitor the operation of each autonomous vehicle, and/or autonomous vehicles in a specific category, each autonomous vehicle may be provided with access to a machine executable digital contract. The machine executable contract may comprise a set of operative statements that have been defined to control and monitor the operation of the autonomous vehicle.
To create the machine executable digital contract, a user may access the digital contract platform of the present disclosure. Through the user interface (UI), the user may provide input data, such as search keywords, to identify operative statements that are applicable to the specific use of the autonomous vehicle.
The keywords provided by the user may be used by the source data file generation logic, SDFGL, which is provided with a semantic search query generation logic, SSQGL, configured to generate, based on information extracted from the user input data, at least one search query comprising a plurality of search criteria.
The search query is submitted to a knowledge database system comprising an operative statement database containing a plurality of operative statements each tagged with a set of metadata information, and a semantic search engine configured to execute the at least one search query generated by the SSQGL so as to identify and retrieve from the operative statement database a set of operative statements associated with metadata information matching the search criteria of the at least one search query. The retrieved operative statements are configured to control and/or monitor the operation of the autonomous vehicles/vehicles, which are specified as contract input data sources during the execution of the digital contract. For example, the operative statements retrieved may relate to applicable laws for operating the autonomous vehicles on the road e.g. highway code or relates, the measures that the autonomous vehicles should follows when encountering pedestrians, what to do in certain situations e.g. when an accident happens, how to respond a call from the user of the autonomous vehicle e.g. emergency call, and the like.
A document generation logic is provided to present to the user for selection, through the User Interface, the operative statements retrieved from the operative statement database. Based on the user selection, the document generation logic is configured to generate a source digital data file. For example, the source digital data file may be a human-readable medium or in a human-readable format comprising encoded data or information that can be naturally read by humans. In computing, human-readable data is often encoded as ASCII or Unicode text. Similarly, the source digital data file may be in computer machine readable format.
The source data file may represent a first version of a physical legal contract comprising a set of operative statements, each comprising operative data comprising a set of conditions and criteria that are to be followed by the autonomous vehicle during the term of the digital contract.
The source data file is then parsed using the parser logic to extract operative data from the operative statements in the source digital data file. The parser logic is configured to generate, based on the extracted operative data, a machine contract programme, which when executed performs the operations specified in the operative statements contained in the source digital data file.
As previously stated, machine contract programmes are vulnerable to errors, which may only be detectable during operation of the machine contract programme, or only when a condition becomes true. These errors are extremely hard to point out and usually are only discovered when the machine contract programme is operational. The usual approach, when an error is discovered is to develop a patch, which is then uploaded in the machine contract programme to fix the errors. These errors may be exploited by a hackers to take control over the machine contract programme, which in the case of autonomous vehicles would be catastrophic and would endanger the lives of people.
Therefore, in order to validate the machine contract programme developed by the digital contract platform a machine contract validation logic, MCVL, may be provided. The MCVL comprises an execution engine which is configured to execute the machine contract programme for different contract data input combination values to determine the executional performance of the digital contract under different operating scenarios and/or conditions. the MCVL is configured to assign a risk factor to each operative statement, which is compared to a predetermined performance threshold e.g. a threshold assigned by the user. I the risk factor is within a first threshold range from the performance threshold e.g. at or above the predetermined threshold, then a validation signal is generated. Otherwise the MCVL generates an alert signal, indicating a vulnerability in the machine contract programme, which is reported to the user. Upon receiving a validation signal the machine contract programme is transmitted to the at least one user to be signed, and upon signature the machine contract programme is hashed and placed on a versioning database ready to be used for execution by the autonomous vehicle.
Once the autonomous vehicle starts to execute the machine contract programme, it transmits to a performance monitoring module a set of operational data. The performance monitoring module is configured to monitor the execution of the digital contract by monitoring the operation data received by the autonomous vehicle and accordingly evaluate whether the autonomous vehicle operates according to the operative statements of the digital contract.
In this way, the continuous monitoring and control of the operation of the autonomous vehicle is ensured. Furthermore, in the case that certain operative statements in the digital contract need to be changed, e.g. because of a legislative change it the traffic code, or a user requirement, then a new digital contract may be generated and put into operation.
The digital contract may be submitted for revalidation at specified intervals to ensure that its executable performance is within a certain level, and free from vulnerabilities.
Engraving images with laser cutting is a notorious hard problem when performed on metal surfaces characterised by irregularities and different surface curvatures. The movement and intensity of the laser are governed by software, the machine code, that receives as inputs the scan and characteristics of the image to be engraved, via image processing. The quality of the final product is highly dependent on the combination of the image resolution, the metal surface characteristics and the laser precision.
A customer contracts with an engraver that owns an autonomous manufacturing machine (an autonomous laser engraving machine) to obtain the engraving of a set of images with different resolution and characteristics on metal surfaces with different irregular curvatures and characteristics with the acceptance of the final product subject to fuzzy quality objectives. The contract regulates the decision and method of the machine to engrave the images on metal surfaces or not and therefore impacts the consequent acceptance of the engraver production of an engraved image. The contract translates in a Machine Contract that, when run on the machine, instructs the machine how to operate on different combinations of images and metal sheets.
1) the customer and the engraver write a Draft Contract, that is submitted as input data to the digital contract platform 200 via the User Interface 210 where it may be digitalised, digitally saved and stored on the master versioning database 260, e.g. a DLT.
2) the Draft Contract is digitally signed and stored on the DLT that can be accessed by any authorised user.
3) the Draft Contract is submitted to the SDFGL 220, where it is used to generate a Source Data File (SDF) by means of a parser, which extracts from the draft contract operative data like sector (image processing/metal surfaces, curvatures/image resolution), users (metal engravers), type of transaction (engrave or not), inputs (image files and image characteristics). The parser 230 may further extract the contractual terms and conditions specified in the draft contract.
4) The SDF is submitted to the MCGL 232 that parses the SDF, extracts operative data (material, surfaces curvatures, images, image definition, quality attributes, engraving activity) and converts the operative data to software statements that write calls the appropriate libraries (engraving software programmes), the appropriate functions (engrave), appropriate variables and objects for images and metal sheet surfaces. Operative statements such as contractual terms and conditions existing in the SDF are converted to software IF CLAUSES. The output is the Machine contract, that is submitted to a version-controlled repository.
5) the customer and the engraver agree on a risk threshold and on a set of Operative Statements, that are submitted to the Knowledge Database System 222.
6) The Machine Contract is either compiled or interpreted into Machine Code and is submitted to the MCVL 240, which validates the machine contract programme by running the code with all the possible inputs and calls to all the possible functions, classes and libraries. The outputs and related inputs are sent to the Risk Analysis Engine that runs a set of risk algorithms and labels the outputs with their related risk factor. Then the outputs and related inputs are sent to the SDFGL that, with a parser or text analytics algorithms, embeds the outputs to text sentences like “If the image is blurred, black and white and the metal sheet has an irregularity index of at least 20% then the image will be rejected”, that becomes and Operative Statement and with its related risk factor is submitted to the Knowledge Database System.
7) If any of the outputs has a critical risk factor like zero then a major software bug/vulnerability has been detected and a request of change is flagged. The machine contract is changed and resubmitted.
8) The Draft Contract is submitted to a text analytics engine, which outputs Knowledge Database Systems queries that generates Operative Statements with related risk factors. For example, the query would be, what are the Operative Statements and related Risk Factors that covers cases in image resolution, image characteristics, material characteristics and material curvatures in the fields of laser metal engraving?
9) Now there are 3 sets of Operative Statements with risk factors. The ones as output of the MCVL, the ones agreed by the engraver and the machine owner, the ones as output of the queries of the text analytics engine. All of those that have a risk factor higher than the decided threshold are appended to the SDF, the output is a Legal Contract, that is digitally signed by the engraver and the machine owner, hashed and submitted to a DLT that can be accessed by both.
If a disagreement is generated between the customer and the engraver, a Trade Dispute is flagged and written as an Operative Statement. That is an input to the text analytics engine and its outputs, together with any type of type of sensors reading (like IOT) and the output become Knowledge Database System queries, that generates Operative Statements with related risk factor. The customer and the engraver are asked to review and if they agree to append the new Operative Statements to the Legal Contract. If they disagree a panel of experts is asked to review. Depending on the decision a Legal Contract is digitally signed, hashed and submitted to a DLT that can be accessed by all the Principals or a subset of them. The New Operative Statements are also submitted to the SDFGL, the MCGL and the MCVL and a new Machine Contract is generated.
Supporting the delivery phase of goods with fleets of autonomous drones is a hard problem in which the delivery is subject to uncertain factors like weather conditions and, moreover, the price of the delivery itself is dependent on the inputs of weather forecast models. The delivery phase is governed by a legal contract that manages and controls to the operations of the drones' fleet with machine code.
A customer contracts with the operator of a fleet of autonomous drones for the delivery of goods. The contract regulates the decision and method of the fleet to deliver the goods subject to uncertain conditions like weather and it can price the delivery subject to the inputs of weather model forecasting. The contract translates in a Machine Contract that, when run on the drones' fleet system, instructs the drones on the trajectories, time of flight and computes a related price.
1) the customer and the drones owner write a Draft Contract, that is submitted as input data to the digital contract platform 200 via the User Interface 210 where it may be digitalised, digitally saved and stored on the master versioning database 260, e.g. a DLT.
2) the Draft Contract is digitally signed and stored on the DLT that can be accessed by any authorised user.
3) the Draft Contract is submitted to the SDFGL 220, where it is used to generate a Source Data File (SDF) by means of a parser, which extracts from the draft contract operative data like sector (delivery/drones/weather dependent), users (type of goods), type of transaction (delivery when and at which price), inputs (weather forecast/goods weight). The parser 230 may further extract the contractual terms and conditions specified in the draft contract.
4) The SDF is submitted to the MCGL 232 that parses the SDF, extracts operative data (delivery/drones/weather dependent/type of goods/goods weight) and converts the operative data to software statements that write calls the appropriate libraries (drones flight management and delivery pricing), the appropriate functions (fly, where and how and price), appropriate variables and objects for. Operative statements such as contractual terms and conditions existing in the SDF are converted to software IF CLAUSES. The output is the Machine contract, that is submitted to a version-controlled repository.
5) the customer and the drones owner agree on a risk threshold and on a set of Operative Statements, that are submitted to the Knowledge Database System 222.
6) The Machine Contract is either compiled or interpreted into Machine Code and is submitted to the MCVL 240, which validates the machine contract programme by running the code with all the possible inputs and calls to all the possible functions, classes and libraries. The outputs and related inputs are sent to the Risk Analysis Engine that runs a set of risk algorithms and labels the outputs with their related risk factor. Then the outputs and related inputs are sent to the SDFGL that, with a parser or text analytics algorithms, embeds the outputs to text sentences like “If a storm is forecasted and the goods are fragile then the price will be at least $$$$ with a risk of 30%”, that becomes and Operative Statement and with its related risk factor is submitted to the Knowledge Database System.
7) If any of the outputs has a critical risk factor like zero then a major software bug/vulnerability has been detected and a request of change is flagged. The machine contract is changed and resubmitted.
8) The Draft Contract is submitted to a text analytics engine, which outputs Knowledge Database Systems queries that generates Operative Statements with related risk factors. For example, the query would be, what are the Operative Statements and related Risk Factors that covers cases in drones' fleets, goods types, weather forecast dependencies in the fields of goods delivery?
9) Now there are 3 sets of Operative Statements with risk factors. The ones as output of the MCVL, the ones agreed by the customer and the drones owner, the ones as output of the queries of the text analytics engine. All of those that have a risk factor higher than the decided threshold are appended to the SDF, the output is a Legal Contract, that is digitally signed by the engraver and the machine owner, hashed and submitted to a DLT that can be accessed by both.
If a disagreement is generated between the customer and the drones owner, a Trade Dispute is flagged and written as an Operative Statement. That is an input to the text analytics engine and its outputs, together with any type of type of sensors reading (like IOT) and the output become Knowledge Database System queries, that generates Operative Statements with related risk factor. The customer and the engraver are asked to review and if they agree to append the new Operative Statements to the Legal Contract. If they disagree a panel of experts is asked to review. Depending on the decision a Legal Contract is digitally signed, hashed and submitted to a DLT that can be accessed by all the Principals or a subset of them. The New Operative Statements are also submitted to the SDFGL, the MCGL and the MCVL and a new Machine Contract is generated.
| Number | Date | Country | Kind |
|---|---|---|---|
| 19209780.6 | Nov 2019 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2020/082437 | 11/17/2020 | WO |
