Computer-implemented architecture for supporting a user in the implementation of procedures

Abstract

Computer-implemented architecture (1) configured to support at least one user in the implementation of a procedure, the architecture comprising: a representation module (2), in which such procedure is stored, in coded form, together with its initial state (s0); an event receiving and storing module (3), configured for: receiving in input, in coded form, each event that occurs with reference to said procedure; classifying said event according to a set of classes and a set of rules stored therein; storing said event according to a chronological order of arrival; and outputting said event; an event interpretation and validation module (4), operatively connected to the event receiving and storing module (3) and configured for: receiving in input each event sent by the event receiving and storing module (3); sorting each event, according to sorting rules stored therein; interpreting each event, according to interpretation rules stored therein; validating each interpreted event, alone or in combination with others already interpreted events, based on validation rules stored therein; obtaining at least one corresponding message (M), starting from said valid and interpreted event or events; and outputting such at least one message (M); procedure state update module (5), operatively connected to the representation module (2) and to the event interpretation and validation module (4), configured for: receiving in input such at least one message (M), outputted by the event interpretation and validation module (4), and automatically determining at least one updated state (SA) of the procedure, based on the at least one message (M) received in input, the coded representation of the procedure, and the state in which the procedure is, upon arrival of such at least one message (M) received; and send in output such at least one updated state (SA) of the procedure; a message receiving and storing module (6), operatively connected to the event interpretation and validation module (4) and configured for: receiving in input such at least one message (M) outputted by the event interpretation and validation module (4), and storing it according to a chronological order of arrival; an interface (7), operatively connected to the procedure state update module (5) and configured for receiving in input such at least one updated state (SA) of the procedure, and reporting the same to the at least one user.

Description

[0001] COMPUTER-IMPLEMENTED ARCHITECTURE FOR SUPPORTING A USER IN THE IMPLEMENTATION OF PROCEDURES

[0002] ***

[0003] The present invention concerns a computer-implemented architecture configured to support at least one user in the implementation of procedures. The present invention also concerns a method of functioning thereof.

[0004] Nowadays, to ensure the proper functioning of companies, organizations and more generally to achieve effective collaboration between multiple parties, it is fundamental to establish a climate of mutual trust. For this reason, the rules that govern the behaviours to be put in place in the relationships between the parties are often defined in agreements, contracts or implementation protocols, from which corresponding procedures are developed.

[0005] These procedures are essential for the correct implementation of the aforesaid agreements, contracts and implementation protocols and their digitisation makes them more accessible, easier to implement and easier to monitor, thus favouring better cooperation.

[0006] The digitization of the aforesaid agreements, contracts and implementation protocols, that is, their expression in the form of a code executable by a computer, allows automation and efficiency and, thanks to the use of technologies that exploit distributed ledger technology (DLT), provides greater security, immutability and transparency. While thus offering numerous advantages, it nevertheless suffers from some limitations in terms of standardization, interoperability, scalability, accurate understanding of nuances and complexity.

[0007] It is felt, therefore, the need to improve the state of the art in the sector of the management of agreements, contracts and implementation protocols according to the corresponding procedures and, more particularly, the main object of the present invention is to provide a computer-implemented architecture configured to support at least one user in the implementation of procedures deriving from agreements, contracts or implementation protocols, etc. that allows to accurately represent such procedures, taking into account all the respective nuances and complexities.

[0008] Another object of the present invention is to make available a computer-implemented architecture configured to support at least one user in the implementation of procedures deriving from agreements, contracts or implementation protocols etc., that is scalable.

[0009] A further object of the present invention is to make available a computer-implemented architecture configured to support at least one user in the implementation of procedures deriving from agreements, contracts or implementation protocols etc., which enables interoperability between systems and standardization.

[0010] Yet another object of the present invention is to make available a computer- implemented architecture configured to support at least one user in the implementation of procedures deriving from agreements, contracts or implementation protocols etc. that, based on the events that occurred between the parties, can automatically determine the next step of the procedure to be followed, supporting the user in their decision-making processes where necessary.

[0011] Not least object of the present invention is to provide a method of function of such architecture.

[0012] A specific object of the present invention is a computer-implemented architecture configured to support at least one user in the implementation of a procedure, said architecture comprising: a representation module, in which such procedure is stored, in coded form, together with its initial state; an event receiving and storing module, configured for: receiving in input, in coded form, each event that occurs with reference to such procedure; y classifying such event according to a set of classes and a set of classification rules stored therein; storing such event according to a chronological order of arrival; and y outputting such event; an event interpretation and validation module, operatively connected to the event receiving and storing module and configured for: y receiving in input each event sent by the event receiving and storing module; y sorting each event, according to the sorting rules stored therein; y interpreting each event, according to interpretation rules stored therein; y validating each interpreted event, alone or in combination with other already interpreted events, based on validation rules stored therein; y obtaining at least one corresponding message, starting from said valid and interpreted event or events; and y outputting such at least one message; procedure state update module, operatively connected to the representation module and to the event interpretation and validation module, configured for: y receiving in input such at least one message, outputted by the event interpretation and validation module, and y automatically determining at least one updated state of the procedure, based on the at least one message received in input, the coded representation of the procedure, and the state in which the procedure is, upon arrival of such at least one received message; and y outputting such at least one updated state of the procedure; a message receiving and storing module, operatively connected to the event interpretation and validation module and configured for: receiving in input such at least one message, outputted by the event interpretation and validation module, and

[0013] ■ / storing it according to a chronological order of arrival; an interface, operatively connected to the procedure state update module and configured to receive in input such at least one updated state of the procedure, and reporting the same to the at least one user.

[0014] According to another aspect of the invention, the procedure in its coded form may be represented through a finite-state machine, optionally wherein a state transition of the finite- state machine depends on the at least one message received by the update module and on the state of the finite-state machine, at the time such at least one message is received by the update module.

[0015] According to a further aspect of the invention, the event interpretation and validation module and / or the event receiving and storing module may be operatively connected by an external data source.

[0016] According to a further aspect of the invention, the interpretation rules may comprise artificial intelligence models.

[0017] According to another aspect of the invention, the event interpretation and validation module may be configured for:

[0018] - / calculating an index indicating the reliability of such at least one message received, based on computational rules the reliability index which are stored in said module, and ■ / outputting also such index, together with such at least one message.

[0019] According to a further aspect of the invention, the procedure state update module may be configured to receive, when available, also the reliability index associated with said at least one received message, and to take it into account to automatically determine the at least one updated state SA of the procedure. According to a further aspect of the invention, the procedure state update module may be configured for outputting the at least one updated state SA of the procedure, together with the respective reliability index.

[0020] According to another aspect of the invention, the procedure state update module may be configured to calculate according to predetermined calculation rules, the probability p that the procedure evolves towards a given state rather than another, said calculation rules optionally also taking into account the reliability index associated with each previous message that has determined the evolution of the procedure in the state in which it is, and wherein, optionally, the procedure state update module may be configured to transmit the at least one updated state SA of the procedure, together with the respective probability.

[0021] According to a further aspect of the invention, the interface may be operatively connected to the event receiving and storing module and / or to the message receiving and storing module, and configured to receive in input each event and / or each message saved therein, optionally with the respective reliability index, for reporting the same to the user.

[0022] According to an additional aspect of the invention, the interface may be operatively connected to the representation module and to the event interpretation and validation module and configured to send:

[0023] - / to the representation module, the coded representation of the procedure and its initial state;

[0024] - / to the event receiving and storing module, the set of classes and the classification rules; and

[0025] - / to the event interpretation and validation module, the sorting rules, the interpretation rules, the validation rules and the reliability index calculation rules.

[0026] According to another aspect of the invention, the architecture may comprise an action module, operatively connected to the event interpretation and validation module and to the procedure state update module and to the event receiving and storing module and configured for: y receiving each updated state of the procedure, with the reliability index of the respective message, or each updated state of the procedure, with the probability index p if the architecture is implemented according to the claim, and automatically determining one or more actions, based on action rules stored therein, and y outputting the action or actions thus determined, at least to said interface.

[0027] According to a further aspect of the invention, the interface may be operatively connected to the action module and configured for: receiving in input each action outputted by it, reporting the same to the user, and sending the action rules to the action module.

[0028] A group of architectures is also a specific object of the invention, comprising: a first architecture comprising an action module, a second architecture as described above, operatively connected to the first architecture and wherein its event receiving and storing module is configured to receive an event, generated by the execution of the action or actions determined by the action module of the first architecture, optionally executed automatically by said action module or by a user of the first architecture.

[0029] It is also a specific object of the invention a computer-implemented method to support at least one user in the implementation of a procedure, through at least one architecture as described above, said method comprising: in said event receiving and storing module: y receiving in input, in coded form, each event that occurs with reference to such procedure; y classifying such event according to a set of classes and a set of classification rules stored therein; storing such event according to a chronological order of arrival; and y outputting such event; in said event interpretation and validation module, operatively connected to the event receiving and storing module: y receiving in input each event sent by the event receiving and storing module; y sorting each event according to the sorting rules stored therein; y interpreting each event according to interpretation rules stored therein; y validating each interpreted event, alone or in combination with other already interpreted events, based on validation rules stored therein; y obtaining at least one corresponding message, starting from said valid and interpreted event or events; y outputting such at least one message; in said procedure state update module, operatively connected to the representation module and to the event interpretation and validation module: y receiving in input such at least one message, outputted by the event interpretation and validation module, and y automatically determining at least one updated state of the procedure, based on the at least one message received in input, the coded representation of the procedure, and the state in which the procedure is, upon arrival of such at least one received message; and y outputting the at least one updated state of the procedure; in said message receiving and storing module, operatively connected to the event interpretation and validation module: y receiving in input such at least one message, outputted by the event interpretation and validation module, and y storing it according to a chronological order of arrival; in said interface, operatively connected to the procedure state update module, receiving said at least one updated state of the procedure, and reporting the same to the at least user.

[0030] According to another aspect of the invention, the method may comprise, if the action module is present in the architecture: receiving in input each updated state of the procedure; y automatically determining one or more actions based on action rules stored therein; and y outputting the action or actions thus determined at least to the interface, for their subsequent report to the user.

[0031] Also forming a specific object of the invention is a system configured to implement the architecture or a group of architectures described above and to execute the method referred to above.

[0032] Finally, object of the invention is one or more computer programs, comprising instructions in the form of code which, when executed by an architecture or a group of architectures as described above, cause the implementation of the method referred to above.

[0033] The invention will be now described, by way of non-limiting illustration, according to its preferred embodiments, with particular reference to the Figures in the accompanying drawings, in which:

[0034] Figure 1 shows a block diagram of a computer-implemented architecture configured to support at least one user in the implementation of a procedure, according to the present invention;

[0035] Figure 2 illustrates a block diagram of the architecture of the present invention, according to a variant thereof;

[0036] Figure 3 is an alternative schematic representation of a specific example of the architecture of the present invention and its operation;

[0037] Figure 4 shows an alternative schematic representation of the architecture of the present invention, applied to the specific case of a fact-checking procedure;

[0038] Figure 5 illustrates a schematic representation of the architecture of the present invention, applied to the specific case of a procedure for implementing a lease agreement between a tenant and a landlord; and

[0039] Figure 6 is a schematic representation of two architectures of the present invention, operatively connected to each other for the implementation of a decision-making procedure, which protects the privacy of the users and discloses information selectively.

[0040] Before entering into the merits of the present invention, it is highlighted that the present invention can be employed to assist one or more users in the implementation of a procedure deriving from contracts, implementation protocols, etc. as well as from all cases in which two or more parties have implicitly or explicitly established to regulate their relationships through a set of agreed procedures, regardless of whether these are written or not, complex or not.

[0041] It is specified that, with the term “event” in the present description and in the claims that follow, it is meant any event that occurs with reference to a procedure. For example, by way of non-limiting example, an event can be sending an email or a phone call, between two or more parties involved in the procedure, or an issue of a payment notice, the receiving of the corresponding receipt, the signing of an agreement, the publication of a post on a social network, the forwarding of a data collected by a sensor, the result of an analysis carried out by an equipment, transmitted together with a log file summarizing its operation during the execution of such analysis, etc.

[0042] The term “message” in this description and in the claims that follow, means any event or a sequence of events that have been interpreted and validated by a module of the architecture that will be described below, for example, by way of non-limiting example, sending an email incorporating a determined signature and / or having a determined content, or a phone call between the parties that took place within a certain time interval from a previous event, or still an issue of a payment notice of a specific bank and intended for a specific recipient, receiving the corresponding receipt within a predetermined period of time, the signing of an agreement comprising determined signatures, the publication of a post on a determined social network by a specific user, the registration of a data value above a specific threshold by a sensor or equipment, etc.

[0043] With reference now to the attached figures, it will be noted that the architecture of the present invention is represented in Figure 1 and indicated therein with reference numeral 1 and it comprises a representation module 2, in which a procedure P of interest and an initial state so thereof is stored in coded form (i.e., expressed in the form of a code executable by a computer).

[0044] According to a preferred embodiment of the invention, the procedure P in its coded form is represented through a finite-state machine and through state transition rules of the finite-state machine (see for example Figures 3 to 6). The coded representation of a procedure through a finite-state machine is in fact advantageous for many reasons, including the fact that it allows the procedure itself to be represented in a very easy-to-understand way, and helps to predict its temporal evolution. This representation also guarantees stability and reliability, avoiding representing also evolutions of the procedure that are inconsistent. Finite-state machines, moreover, are more easily scalable and extendable, thanks to their ability to comprise grafted machines and / or shared state. This last aspect of the finite-state machines is, among other things, particularly advantageous since it allows interoperability between different procedures to be implemented. In any case, the person skilled in the art will have no difficulty in understanding how such a procedure can also be encoded in another way, for example through a flowchart representation or in any other suitable way, without thereby departing from the scope of protection of the present invention. Not only that, the representation of a procedure can also be very complex and comprise grafted and / or feedback cycles, through which the procedure responds in an iterative and evolutionary way to the events that occur, giving the architecture 1 greater flexibility and responsiveness.

[0045] The architecture 1 of the present invention also comprises an event receiving and storing module 3, configured to receive in input from the outside, in coded form (for example in the form of a stream of data processable by a computer), each event and which occurs with reference to such procedure. By way of non-limiting example, see Figure 3, an event may be an email (graphically represented as a letter envelope) that is received by the event receiving and storing module 3.

[0046] Such events can reach the event receiving and storing module 3 in any suitable way. They can for example be actively transmitted by a user in charge of supervising the implementation of the procedure, through suitable interfacing means (for example a keyboard) connected to the event receiving and storing module 3, or they can be detected and transmitted automatically by a web application or by equipment external to the architecture 1 and specially programmed or still be sent directly by the parties involved in the implementation of the procedure, in any suitable way, for example through an application external to the architecture 1 of the present invention, installed on the communication devices of the parties and operatively connected, for example through a suitable communication network, to the architecture 1 of the invention.

[0047] The event receiving and storing module 3 is further configured to classify a received event, according to a predetermined set of classes and according to a set of classification rules stored therein, and it is further configured to store said event according to the respective chronological order of arrival.

[0048] Thus, for example, an email that reaches the event receiving and storing module 3 will be recognized as such by the module that receives it, thanks to the application of the aforesaid classification rules and therefore stored together with its instant of arrival in the module itself.

[0049] In Figure 3, specifically, four emails are represented with the references e i, e2, es and e4 in addition to three further events es-ee-e? automatically detected by a web application (referred to as API SYNC, in the Figures). Such automatically detected events may be, for example, notifications relating to a charge or a credit made to the bank account of one of the parties, detected through a standard API configured to interact with the banking institution of which that party is a current bank account holder. In addition to the aforesaid events, the event receiving and storing module 3 is also configured to receive, classify and store previously stored information on a public or private register, accessible to the users of the architecture, represented in Figure 3 through cylindrical shapes and indicated with references es-ei?.

[0050] The event receiving and storing module 3 is further configured to transmit each received event towards another module of the architecture 1 of the invention.

[0051] The architecture 1 of the present invention comprises in fact an event interpretation and validation module 4, operatively connected to the event receiving and storing module 3 and configured to receive in input each event sent by the event receiving and storing module 3, to order and interpret it, according to respective sorting rules and interpretation rules stored therein, optionally employing artificial intelligence models. More precisely, the sorting rules allow to establish the temporal relationships between the events received in input by the event receiving and storing module 3 and transmitted to the event interpretation and validation module 4, which events are stored in the event receiving and storing module 3 according to their order of arrival, but they may have occurred at a time instant prior to the time of arrival in this module. In the event interpretation and validation module 4, therefore, events are temporally ordered based on the actual time instant in which they occurred and, therefore, they are interpreted. The interpretation rules can be of deterministic type and comprise, for example, the execution of a specific code in which the input is the event to be interpreted. Alternatively, the interpretation rules of the events may comprise artificial intelligence models and, that is, non-deterministic and / or probabilistic models, belonging for example to the Large Language Model (LLM) family, such as for example ChatGPT, which processes the content of an email received in input and, for example, it establishes whether such content implies a willingness to terminate a contract or not. In any case, the person skilled in the art will have no difficulty in understanding how the sorting rules and the interpretation rules may vary depending on the specific application for which the architecture 1 of the present invention is implemented and used. For example, but not only, they could be implemented according to the teachings of patent EP 3493141 Al.

[0052] The event interpretation and validation module 4 is also configured to validate said interpreted event, alone or in combination with other interpreted events, based on validation rules stored therein, to establish, that is, whether this alone or in combination with other interpreted events may or may not cause a progress of the procedure and, in the specific case of the procedure represented by a finite-state machine, whether said event alone or in combination with other interpreted events may or may not determine a change of state of said state machine. If so, the event interpretation and validation module 4 is configured to translate the validated event or events into at least one corresponding message (Ml, M2, ..., in Figure 1). The event interpretation and validation module 4 is also configured to send in output this message thus produced.

[0053] Each message is in fact transmitted from the event interpretation and validation module 4 to a procedure state update module 5, which is also part of the architecture 1 of the invention, which procedure state update module 5 is operatively connected to the representation module 2 and to the event interpretation and validation module 4 and configured to receive in input a message, outputted by the event interpretation and validation module 4, and automatically determine the updated state SA of the procedure, based on the message received in input, the representation in coded form of the procedure P and the state in which it is (also known as the current state) when the message arrives.

[0054] The procedure P state update module 5 is also configured to send in output the updated state SA thereof.

[0055] In this regard, the architecture 1 of the present invention advantageously also comprises an interface 7, operatively connected to the procedure state update module 5 and configured to receive in input the updated state SA of the procedure, for subsequent notification to the user or users of the architecture 1.

[0056] According to an advantageous embodiment of the invention, the event interpretation and validation module 4 is also configured to receive in input useful data, coming from data sources external to the architecture 1 but connectable to it, such as, for example, blockchains or public databases, or private databases, etc. Such data, coming from external sources, can in fact be used to interpret and / or validate the received events, according to the interpretation and validation rules stored therein, and thus to establish whether a received and interpreted event can (alone or in combination with other received events) be validated, that is, whether or not it can cause an update of the procedure. By way of non-limiting example, for the validation of an event corresponding to the receipt of a digital signature, the event interpretation and validation module 4 to validate the digital signature received could resort to consulting an external database to verify which is the key used for that digital signature and whether it actually belongs to the actual owner of the digital signature.

[0057] The event receiving and storing module 3 is also advantageously configured to receive in input the aforesaid data from external data sources and to store them based on the chronological order of arrival.

[0058] With such a configuration, it is quite evident that the event receiving and storing module 3 maintains the history of what happens over time, in relation to the procedure P of interest and the data coming from external sources that are possibly used for the interpretation and validation of the events. According to a particularly advantageous aspect of the invention, the event interpretation and validation module 4 can also be configured to calculate the value of a reliability index RI of a corresponding message, based on corresponding reliability index calculation rules stored in the module itself, and send it in output together with it. It may happen, in fact, that an event received by the event interpretation and validation module 4 is not interpretable and / or validable with high reliability, based on the interpretation and validation rules stored in the module itself. Think, for example, of an event that consists of an email whose content may be unclear or contradictory. The reliability index RI can be calculated in any suitable way according to the aforesaid calculation rules, depending on the specific case of implementation and use of the architecture 1 of the present invention. To provide a purely exemplary and non-limiting case, in the medical field, for example, an event consisting of the arrival of the results of some medical examinations may be associated with a certain reliability to a specific clinical condition, based on what may already be known from the literature of the sector.

[0059] Well, the architecture 1 of the present invention is configured so that the procedure state update module 5 also uses, when available, the reliability index RI associated with each message received (see Figure 1 for the pairs (Ml, RI1), (M2, RI2), ... ) to automatically determine the updated state SA of the procedure.

[0060] For example, according to a first variant of the present invention, as a function of the value of the reliability index RIi of an i-th message Mi received (i=l, 2,...), the procedure state update module 5 will automatically determine which state to select as updated procedure state SA, among several possible procedure states. In the specific case in which the procedure is represented by a finite-state machine, based on the value of the reliability index RIi of the i-th message Mi received, the procedure state update module 5 may select the state of the finite- state machine, among several possible states, or it may remain in its current state. To provide a practical example, referring to Figure 3, if the procedure was in state s2 and a received message were with high reliability a message M3 a (being associated with a high value of the index RI3a, for example higher than a predetermined threshold percentage, for example greater than or equal to 80%) rather than a message M3b, the procedure update module 5 would select as updated state SA the state s3a, rather than the state s3b.

[0061] Alternatively, according to another variant of the invention, the procedure state update module 5 can provide in output a plurality of updated states, SAI, among several possible states of the procedure, based on the received message Mi (i=l, 2,...) and the value of the reliability index RIi of this message. To return to the example provided above, represented in Figure 3, if the procedure were in state s2 and a received message were with high reliability a message M3a and with reduced reliability a message M3b, the procedure update module 5 would select both the state s3a and the state s3b as updated states SAL

[0062] In this case, the procedure state update module 5 is configured for outputting the updated state SA or the updated states SAi of the procedure, together with the respective reliability indices RIi, and the interface 7 is configured to receive the in input the updated state SA or the updated states SAi of the procedure with the respective reliability indices RIi, for subsequent notification to the user or users of the architecture 1.

[0063] In this regard, it should be specified that the procedure update module 5, according to a variant of the invention, is configured to calculate according to predetermined calculation rules also the probability p that the procedure evolves towards a given state rather than another. The calculation rules can be more or less complex and also take into account, in reverse, the reliability index RI associated with the messages that have determined the evolution of the procedure in the previous states. If, for example, a state Sc can be reached starting from a state Sa, after the arrival of messages B and C each with a low reliability index RI, for example equal to 0.1, the state update module 5 can for example associate the state Sc with a probability pc equal to 0.1*0.1=> p(Sc) = 0.001 => 1%. Here, providing in output, by the procedure state update module 5, a plurality of updated states, SAi, among several possible states of the procedure, as described above and based not only on the last message Mi received (i=l, 2,...) and the value of the reliability index RIi of that message, but also of the previous ones, can offer a more accurate representation of the updated state SA or of the updated states, SAi, and in the applications where even less probable states can have significant impacts, it allows to support more informed and prudent decisions by the system users.

[0064] In summary, according to a variant of the present invention, as said above, the updated states SAi of the procedure can be represented by a two-dimensional array comprising the list of all possible states with the respective probability [(Sa, pa), (Sb, pb) ...], the probability of each state being updated over time, as the events with the respective messages follow one another. According to a further variant of the present invention, whenever the procedure P undergoes a change of state, a predetermined number N of most probable states or the states associated with a probability higher than a certain threshold value can be sent to a saving module, not represented in the drawings, both internal and external to the architecture 1, for storage thereof.

[0065] The architecture 1 of the present invention also comprises a message receiving and storing module 6, operatively connected to the event interpretation and validation module 4. Said message receiving and storing module 6 is configured to receive in input each message outputted by the event interpretation and validation module 4 as well as the corresponding reliability index RI, if available, and to store them, according to the chronological order of arrival. With such a configuration, the message receiving and storing module 6 also helps to maintain a part of the history of what happens, over time, in relation to the procedure P of interest.

[0066] Returning to the interface 7, this is advantageously also operatively connected to the event receiving and storing module 3 and to the message receiving and storing module 6 and configured to receive in input each event (including data coming from an external source) and each message with the respective reliability index RI (if available) stored therein, for subsequent notification to the user.

[0067] It is therefore quite evident that, with such a configuration of the architecture 1 of the present invention, a user can be made aware of the events that occur in relation to the procedure in which he or she is involved or that he or she must supervise, in the chronological order in which such events occurred, and can receive notifications on the state of progress of the procedure as this is updated, thus being in a condition of making informed decisions accordingly.

[0068] According to another advantageous aspect of the invention, the interface 7 is optionally operatively connected both to the representation module 2 of the procedure of interest and to the event interpretation and validation module 4 and configured to send: to the representation module 2, the representation in coded form of the procedure P of interest and its initial state so as well as the rules of transition between one state of the procedure and the other, if the procedure P is represented through a finite-state machine; and to the event interpretation and validation module 4, the sorting rules, the interpretation rules, the validation rules and the reliability index calculation rules.

[0069] The interface 7 is also configured to transmit to the event receiving and storing module 3 also the classes and the classification rules to be stored for the classification of the received events.

[0070] With such a configuration of the architecture 1, it is therefore quite evident how a user through the interface 7 can send and / or modify the representation of the procedure P, its initial state so, the transition rules or the classes and / or the classification rules of the events received in input and / or the validation rules and / or the interpretation rules of the events and / or the sorting rules and / or the calculation rules of the reliability index, whenever necessary. All this, modifying only the module involved in these modifications and leaving the rest of the architecture 1 unchanged. By way of example only, as regards the update of the computational rules the reliability index, these can be modified in response to the result of the implementation of supervised learning algorithms, or as the information available increases, regarding a determined event to be interpreted. For example, in the medical field, the computational rules the reliability index concerning a certain event can be modified with the progressing of the clinical trials and the review of data by the operators in the sector, in order to reflect, for example, new medical discoveries. The representation of the procedure P, to provide a further example, may vary in correspondence with updates of contracts that take place between the parties.

[0071] According to a variant of the present invention, the event interpretation and validation module 4 is also configured to send to the message receiving and storing module 6, for saving it, also the event at which the rule for calculating the reliability index has been modified, in order to be able to keep track of the history of what happens with reference to the procedure, during its implementation.

[0072] According to a further variant of the present invention, the interface 7 is configured to send to the representation module 2 also the rules defining: the users, enabled to use the architecture 1 of the invention; the roles of such users, for example if a user is an administrator of the architecture or if he or she is a simple user of the architecture; and the relative permissions, for example regarding the possibility or not of sending and / or modifying the representation of the procedure P, its initial state so, the transition rules or the classes and / or the classification rules of the events received in input and / or the validation rules and / or the interpretation rules of the events and / or the sorting rules and / or the calculation rules of the reliability index, whenever necessary. According to a particularly preferred variant of the present invention, represented in Figure 2, the architecture 1 of the present invention also comprises an action module 8, operatively connected to the event interpretation and validation module 4, to the procedure state update module 5 and to the interface 7. Such an action module 8 is configured to receive in input each updated state of the procedure SAi and, if available, the reliability index RIi of the corresponding message, and automatically determine one or more suggested actions, based on action rules stored therein for the continuation of the procedure P. The action module 8 is further configured to send in output the action or actions thus determined (in Figure 3 represented with references ai, a2 and as) at least to the interface 7, for their subsequent notification to the user.

[0073] In the event that the suggested action or actions notified to the user are also performed by the latter, they generate corresponding events that will be received in input by the event receiving and storing module 3 which, after being stored and classified by the event receiving and storing module 3 and transmitted to the interpretation and validation module 4, may in turn cause a further update / progress of the state of the procedure P.

[0074] According to a variant of the present invention, the suggested action or actions determined automatically by the action module 8 may also be performed automatically by the latter. Consider, by way of non-limiting example, an action that consists of activating a timer at the end of which, according to the procedure P, it is necessary to send a new notification to the user.

[0075] The interface 7 of the architecture 1 of the present invention is configured not only to receive in input each action sent by the action module 8, but also to send to the action module 8 the action rules and / or any changes / updates thereof, when necessary.

[0076] It should also be noted that an action determined by the action module 8, when executed, becomes an event that, in addition to being received in input by the event receiving and storing module 3 of the same architecture 1, can also constitute a relevant event for at least another architecture according to the invention, configured to support the user in the implementation of a procedure connected to the procedure represented in the representation module 2 of the starting architecture 1.

[0077] With such a configuration it is quite evident that any agreement, contract, implementation protocol or set of collaboration rules can be easily and advantageously represented through one or more procedures P in one or more architectures 1 of the present invention, connected to each other according to various configurations in series, parallel, star- like or combinations thereof, thus allowing to support the user in the implementation of the procedure itself and / or in its supervision. Through the interface 7, a user can in fact be informed of the events that occur regarding the procedure and receive a notification whenever these events cause the procedure itself to progress, with the possible indication through the action module 8, of the subsequent actions to be taken or automatically taken by the action module 8, for the correct performance of the procedure.

[0078] Well, as can be seen from the description of the architecture 1 provided above, this is configured to implement a method to support at least one user in the implementation of a procedure, which is also the subject-matter of the present invention and which comprises the following steps: in the event receiving and storing module 3: receiving in input, in coded form, each event that occurs with reference to such procedure;

[0079] - / classifying such event according to a set of classes and a set of classification rules stored therein; y storing such event according to a chronological order of arrival; and outputting such event; in the event interpretation and validation module 4, operatively connected to the event receiving and storing module 3: y receiving in input each event sent by the event receiving and storing module 3; y sorting each event according to the sorting rules stored therein; y interpreting each event according to interpretation rules stored therein; y validating each interpreted event, alone or in combination with other already interpreted events, based on validation rules stored therein; y obtaining at least one corresponding message M starting from said valid and interpreted event or events, optionally with a respective reliability index RI; y outputting such at least one message M, optionally with the respective reliability index Ri; in the message receiving and storing module 6, operatively connected to the event interpretation and validation module 4: y receiving in input such at least one message M outputted by the event interpretation and validation module 4, optionally with the respective reliability index RI, and y storing it according to a chronological order of arrival; in the procedure state update module 5, operationally connected to the representation module 2 and to the event interpretation and validation module 4: y receiving at least one message M in input, optionally with the respective reliability index RI, outputted by the event interpretation and validation module 4; y automatically determining the updated states SA of the procedure, based on the at least one message M received in input, optionally with the respective reliability index RI, of the coded representation of the procedure and the state in which the procedure is, upon arrival of such at least one received message M; and y outputting the updated state SA of the procedure, optionally with the reliability index RI of the respective message M; in the interface 7, operatively connected to the procedure state update module 5, receiving in input the updated state SA of the procedure, optionally with the reliability index RI of the respective message M, and notifying the at least one user; in the action module 8, if any: receiving in input each updated state SA of the procedure, optionally with the reliability index RI of the respective message M; y automatically determining one or more suggested actions, based on action rules stored therein; and

[0080] 7 outputting the action or actions thus determined at least to the interface 7, for their subsequent notification to the user.

[0081] Some practical examples of implementations of the architecture 1 of the present invention are provided below, it being understood that an unlimited number of procedures can be implemented with the architecture 1 of the present invention.

[0082] Example 1

[0083] Represented in Figure 4 is an architecture 1 configured to support the implementation of a procedure P for checking a fact, which is understood to have occurred only if it is in a specific state, indicated with s4 in the representation with finite-state machine stored in the representation module 2.

[0084] Each state of the procedure is represented by a circle and the connecting arrows between one state and the other indicate the transition rules of the procedure, that is, the validated events that, given a starting state (at the tail of an arrow), when they occur, cause the procedure to switch to another state (at the tip of the arrow).

[0085] For example, the procedure for checking a fact that is in the initial state so, according to what is represented in Figure 4, switches to the state si if both events ei and e2 occur or to the state S2, if the event e3 occur. The procedure in the state si switches to the state S2, if the event e 5 occurs, or it switches from the state si to the state S3, if the event 63 occurs, and so on.

[0086] Specifically, the events concerning the procedure for checking the fact, represented in Figure 4, are: two emails ei and e2, the one indicated with the reference el which comes from the sender Ul, contains the content Ml and is signed by SI and the one indicated with the reference e2, coming from the sender U2, which contains the content Ml and is signed by S2; and four arrivals (e3-ee) of data archived in two different registers or ledgers, txl and tx2, wherein, respectively, 63 concerns the arrival of data stored in the register txl, having content m4 and bearing the signature of SI, a concerns the arrival of data stored in the register tx2, having content m4 and bearing the signature of S2, es concerns the arrival of data stored in the register tx2, having content m3 and bearing the signature of S2, ee concerns the arrival of data stored in the register txl , having content m3 and bearing the signature of S 1.

[0087] These events, alone or in combination with others, can give rise to messages. For example, the occurrence of events ei and e2, according to the interpretation and validation rules stored in the module 4 of the architecture 1 and as represented in Figure 4, is translated into a single message Ml, the event 63 is translated into the message M2 and the same applies to the events es and ee which are translated into respective messages M3 and M4. The event e4, on the other hand, is not translated into any message because, based on the validation rules stored in the event interpretation and validation module 4, even if it occurs, it does not cause any change in the state of the procedure itself. With such an architecture, the person skilled in the art will have no difficulty in understanding how the fact-checking procedure represented in Figure 4 ensures coherence and consistency, taking into consideration only the events that meet the conditions necessary for such verification, and effectively prevents unauthorized or unexpected state transitions, improving the overall security and reliability of the procedure itself.

[0088] Starting from an initial state so, in fact, only the arrival in chronological order of the messages Ml, M2 and M4 determines the verification of the fact.

[0089] Example 2

[0090] Represented in Figure 5 is a procedure P stored in the representation module 2 of the architecture 1, configured to manage and monitor a lease contract of a property, between a tenant and a landlord.

[0091] The contract in question can be advantageously represented in an easy and intuitive way through the finite-state machine, in which various conditions or aspects of the contract to be monitored can be represented. The contract is in the initial state so “Unsigned contract proposal”, with a draft proposal awaiting review and approval by both parties. When both the landlord and the tenant sign the contract, the contract switches to the aforesaid series of parallel states: si “unpaid rent”, “unpaid bills”, “no cancellation by tenant” and “no cancellation by landlord” which represent the fundamental aspects of the contract in a simple and clear way and, as can be seen from Figure 5, may vary as a function of the events but also of time. For example, when the tenant sends a cancellation of the contract, this triggers a state transition (specifically, the termination of the lease contract) after a predetermined period of time, as clearly represented in Figure.

[0092] It should be noted, in this regard, that the same events that affect the procedure P represented in Figure 5, for example the payment or not of bills, may also affect similar procedures, represented with another architecture of the type described above that regulates, for example, the relationship of a utility manager and a user, or they may affect a change of state of the architecture, for example the change between one state and another, which may also be a state composed of several sub-states, each relating to a bill to be paid.

[0093] Example 3

[0094] Represented in Figure 6 are two architectures according to the present invention, operatively connected to each other for the implementation of a two-step decision-making procedure, which protects the privacy of the users and disseminates information selectively. At the top, in Figure 6, it is represented with the letter P, the first step of the procedure stored in an architecture 1, which concerns the verification by a certifying body, of the suitability of a user to the request for the provision of a service, for example to a state institution. At the bottom, instead, the letter P’ represents the second step of the procedure, which concerns the provision of the service by the state institution.

[0095] In the first step, the representation through the state machine provides for two possible states so and si and two allowed transitions: via messages Ml, M2 and M3 or via message M7. Given that the event receiving and storing module 3 receives the events ei, a and es, which in turn are translated into the respective messages Ml, M2 and M3 by the event interpretation and validation module 4, the state of the first state machine switches from so to si and this change of state triggers in the action module 8, an action by the certifying body that by signing for approval, generates a new event, e4.

[0096] The event e4, in addition to being shared with the user, is also received by the architecture 1' configured to support the implementation of the second step of the procedure, which is represented by a state machine that provides two possible states s'o and s'i and a single possibility of transition from one state to another, that is, the reception of the event e4 transmitted by the certifying body.

[0097] As it can be noted, the certifying body is not aware of the exact conditions that allowed the user to obtain the required eligibility and not even the state institution responsible for providing the service knows these details.

[0098] At the same time, the events received by the event receiving and storing modules 3 and the corresponding messages translated by the event interpretation and validation modules 5 and 5’ can be consulted, if necessary, for example in the event that it is necessary to demonstrate how each transition has taken place, while maintaining the user's privacy. In the event of a dispute, a third party authority can, for example, reconcile all events and understand the details that led to the provision of the service to the user.

[0099] Example 4

[0100] The architecture 1 of the present invention can be advantageously applied in a monitoring system, for example in the financial or IT field, exploiting the potential of the event interpretation and validation module 4 which, based on the interpretation and validation rules stored therein, can be used to detect suspicious activities. For example, in the financial field the architecture 1 of the present invention could be employed to examine financial transactions and identify unusual or suspicious patterns. Similarly, it could function as an IDS system in a computer network, monitoring traffic and analysing the data for anomalous behaviour or intrusion attempts.

[0101] The architecture 1 of the present invention, as can be seen from the examples described above, is advantageously usable in many applications and lends itself, also thanks to the interface 7, to be included in management control systems, since all the data notified to the user can be processed by a remote processor with high computing power, for example, in order to elaborate new directives to be used to further improve the implementation of the procedures.

[0102] For example, it can be used strategically by consulting firms (domain experts) or law firms, in contexts where the in-depth analysis of the company data allows for more informed decisions to be made, or in regulated sectors, such as healthcare, where the sharing of information with regulatory bodies serves to ensure the compliance of the decisions, ensuring that the actions taken are always aligned with the latest sector guidelines and regulations. For example, considering that the architecture 1 allows events, messages and states to be communicated in output, these can be used to generate zero-knowledge evidence (otherwise known as ZK) through external services. Such tests ZK make it possible to demonstrate that a procedure is in a given state, without revealing further details, which is particularly useful for auditing purposes or to ensure regulatory compliance.

[0103] In addition, the possibility offered by the architecture 1 to share states and messages with other architectures of a similar type allows to improve the procedures associated with a system and to produce aggregated data which, for example, can be used in the clinical sector to refine medical decisions or, in other contexts, they can be used by the legislators to develop or refine implementing laws and policies.

[0104] A further possibility offered by the architecture 1 could be to publish, thanks to the outputting of an action by the action module 8, the cryptographic hash of an event or a state reached on an immutable public ledger, such as a blockchain. This would advantageously allow verifiably “marking” the achievement of given states of a procedure in a certain time. By publishing the hash on a shared register, multiple users or instances of the architecture 1 can in fact coordinate and synchronize, reaching consensus on the evolution of a procedure modelled through state machines. The publication of the hash, without revealing the details of the event, serves as irrefutable proof and allows interoperability and composition of processes across different organizations.

[0105] The architecture 1 of the present invention may be implemented in the form of software, optionally saved in the cloud, or firmware and / or hardware, for example in part saved on portable electronic devices or other consumer equipment that are used to store and / or emit suitable signals, such as smartphones, tablets, PCs, smartwatches, handhelds, etc. The software modules may also be stored in a random access memory (RAM), a read-only memory (ROM), a register, a hard disk, a removable disk, a CD-ROM, a blockchain, or any other type of storage medium well known in the art.

[0106] The modules of the architecture are configured to communicate with each other by sending and receiving information (events, messages, states, rules, etc.) typically in the form of data streams (signals) of any suitable type and the storage of the events, messages and data connected to them can take place on random access memory media or optical storage media, or blockchain. The events and messages, as already mentioned above, can be transferred in the form of data streams (signals) via telecommunications networks, such as radio networks, satellite networks, wireless networks or wired networks, for example via the Internet.

[0107] In light of the above, it is evident that the architecture 1 implementable on the support computer in the implementation of procedures and the method described above solve the problems set out in the introduction.

[0108] In fact, as explained above, they allow each type of procedure to be accurately represented, taking into account all the respective nuances and complexities that can be easily and directly expressed through finite-state machines. The architecture of the present invention, thanks to the configuration of the modules described, is scalable and allows interoperability between different systems as well as standardization. Not only does it support a user who can not only be constantly informed of the state of the procedure but can also receive support for their decision-making processes by receiving indications on the possible steps to be taken to make the procedure itself progress.

[0109] The preferred embodiments and possible versions of the invention have been outlined above, but it is to be understood that the persons skilled in the art may make modifications and changes without infringing the scope of protection, as defined in the attached claims.

Claims

CLAIMS1. Computer implemented architecture (1) configured to support at least one user in the implementation of a procedure, said architecture comprising:- a representation module (2), in which such procedure is stored, in coded form, together with an initial state (so);- an event receiving and storing module (3), configured for: receiving in input, in coded form, each event occurring with reference to that procedure; classifying such event according to a set of classes and a set of rules stored therein; y storing such event according to a chronological order of arrival; and y outputting such event;- an event interpretation and validation module (4), operatively connected to the event receiving and storing module (3) and configured for: y receiving in input each event sent by the event receiving and storing module (3); y sorting each event, according to sorting rules stored therein; y interpreting each event, according to interpretation rules stored therein; y validating each interpreted event, alone or in combination with other already interpreted events, based on validation rules stored therein; y obtaining at least one corresponding message (M), starting from said valid and interpreted event or events; and y outputting such at least one message (M);- procedure state update module (5), operatively connected to the representation module (2) and to the event interpretation and validation module (4), configured for: y receiving in input said at least one message (M), outputted by the event interpretation and validation module (4), and y automatically calculating at least one updated state (SA) of the procedure, based on the atleast one message (M) received in input, the coded representation of the procedure, and the state in which the procedure is, when said at least one message (M) is received; and outputting this at least one updated state (SA) of the procedure;- a message receiving and storing module (6), operatively connected to the event interpretation and validation module (4) and configured for: receiving in input such at least one message (M) outputted by the event interpretation and validation module (4), and storing said message according to a chronological order of arrival;- an interface (7), operatively connected to the procedure state update module (5) and configured to receive in input such at least one updated state (SA) of the procedure, and reporting the same to the at least one user.

2. Architecture (1) according to claim 1, wherein the procedure in its coded form is represented through a finite-state machine, optionally wherein a state transition of the finite- state machine depends on the at least one message (M) received by the procedure state update module (5) and the state of the finite-state machine, when said at least one message (M) is received by the update module (5).

3. Architecture (1) according to claim 1 or 2, wherein the event interpretation and validation module (4) and / or the event receiving and storing module (3) is operatively connected by an external data source.

4. Architecture (1) according to any previous claim, wherein the interpretation rules comprise artificial intelligence models.

5. Architecture (1) according to any previous claim, wherein the event interpretation and validation module (4) is configured for: " calculating an index (RI) indicating the reliability of such at least one message (M) received, based on computational rules of the reliability index which are stored in thismodule, and> / outputting also this index (RI), together with such at least one message (M).

6. Architecture (1) according to claim 5, wherein the procedure state update module (5) is configured to receive, when available, also the reliability index (RI) associated with said at least one received message (M), and to take it into account to automatically determine the at least one updated state (SA) of the procedure.

7. Architecture (1) according to claim 6, wherein the procedure state update module (5) is configured for outputting the at least one updated state (SA) of the procedure, together with the respective reliability index (RIi).

8. Architecture (1) according to claim 6 or 7, wherein the procedure state update module (5) is configured to calculate according to predetermined calculation rules, the probability p that the procedure may evolve towards a given state rather than another, said calculation rules optionally also taking into account the reliability index (RI) associated with each previous message (M) that has determined the evolution of the procedure in the state wherein the procedure is, and wherein, optionally, the procedure state update module (5) is configured to transmit the at least one updated state (SA) of the procedure, together with the respective probability value.

9. Architecture (1) according to any previous claim, wherein the interface (7) is operatively connected to the event receiving and storing module (3) and / or the message receiving and storing module (6), and configured to receive in input each event and / or each message saved therein, optionally with the respective reliability index (RI), for reporting the same to the user.

10. Architecture (1) according to any previous claim, wherein the interface (7) is operatively connected to the representation module (2) and to the event interpretation and validation module (4) and configured to send:to the representation module (2), the coded representation of the procedure and the initial state (so) thereof; to the event receiving and storing module (3), the set of classes and the rules; and to the event interpretation and validation module (4), the sorting rules, the interpretation rules, the validation rules and the rules for computing the reliability index.

11. Architecture (1) according to any previous claim, comprising an action module (8), operatively connected to the event interpretation and validation module (4) and to the procedure state update module (5) and to the event receiving and storing module (3) and configured for: receiving each updated state (SA) of the procedure, with the reliability index (RI) of the respective message (M) if the architecture (1) is implemented according to claim 5, or each updated state (SA) of the procedure, with the probability value p if the architecture (1) is implemented according to claim 8, and automatically determining one or more actions, based on action rules stored therein, and y outputting the action or actions thus determined, at least to said interface (7).

12. Architecture (1) according to claim 11, wherein the interface (7) is operatively connected to the action module (8) and configured for:- receiving in input each action outputted by the action module,- reporting the same to the user, and- sending the action rules to the action module (8).

13. Architecture group, comprising:- a first architecture (1) according to claim 11 or 12,- a second architecture (1') according to any previous claim, wherein said second architecture (1') is operatively connected to the first architecture (1) and the event receiving and storing module (3) of the second architecture is configured to receive one event, generated by theexecution of the action or actions determined by the action module (8) of the first architecture (1), optionally automatically implemented by said action module (8) or by a user of the first architecture (1).

14. Computer-implemented method to support at least one user in the implementation of a procedure, through at least one architecture (1) according to any claim 1 to 12, said method comprising:- in said event receiving and storing module (3): receiving in input, in coded form, each event that occurs with reference to such procedure; classifying such event according to a set of classes and a set of rules stored therein; storing such event according to a chronological order of arrival; and y outputting such event;- in said event interpretation and validation module (4), operatively connected to the event receiving and storing module (3): y receiving in input each event sent by the event receiving and storing module (3); y sorting each event according to sorting rules stored therein; y interpreting each event according to interpretation rules stored therein; y validating each interpreted event, alone or in combination with other already interpreted events, based on validation rules stored therein; y obtaining at least one corresponding message (M) from this or these events interpreted and considered as valid; y outputting such at least one message (M);- in said procedure state update module (5), operationally connected to the representation module (2) and to the event interpretation and validation module (4): y receiving in input such at least one message (M) outputted by the event interpretation and validation module (4), andautomatically determining at least one updated state (SA) of the procedure, based on the at least one message (M) received in input, the coded representation of the procedure, and the state in which the procedure is, upon arrival of such at least one received message (M); and outputting the at least one updated state (SA) of the procedure;- in said message receiving and storing module (6), operatively connected to the event interpretation and validation module (4): receiving in input such at least one message (M) outputted by the event interpretation and validation module (4), and storing it according to a chronological order of arrival;- in said interface (7), operatively connected to the procedure state update module (5), receiving in input said at least one updated state (SA) of the procedure, and reporting the same to the at least one user.

15. Method according to claim 14, comprising in the action module (8), if present: receiving in input each updated state (SA) of the procedure; y automatically determining one or more actions based on action rules stored therein; and y outputting the action or actions thus determined at least to the interface (7), for their subsequent notification to the user.

16. System (10) configured to implement the architecture (1) according to any claim 1 to 12 or a group of architectures according to claim 13 and for implementing the method according to claim 14 or 15.

17. Set of one or more computer programs, comprising instructions in coded form that, when executed by an architecture according to any claim 1 to 12 or a group of architectures according to claim 13, cause the implementation of the method according to claim 14 or 15

Images