Method and system for controlling the delivery of goods

Abstract

Method and system for controlling the delivery of goods This method is implemented by a control system (KX) and includes: - the registration (E10) of a user (EXP-MGR) with an access management module (MODSGA) and the provision (8) of authentication means (TOKEM) to a workstation (PCEXPM) of said at least one user (EXP-MGR); - the downloading (E30) of a configuration file (FCONF) of the delivery containing information on at least one operation to take place during said delivery; - the recording (E40) of a result of an operation in a delivery visibility database (BDVIS) on request (18, 21) of a user; - the recording (E90) of at least one transaction representative of said at least one operation and of a signature of said transaction in an immutable and verifiable audit database (AUDDB), said signature being made using a private key of said system (KX).Fig 1.

Description

Title of the invention: Method and system for controlling the delivery of goods Scope of the invention

[0001] The present invention is in the field of controlling a logistics flow, and more particularly the delivery of goods.

[0002] It applies in particular, but not exclusively, to the control or monitoring of a drug delivery process. Prior art

[0003] Logistics flows, and in particular the delivery of medicines, are complex processes. They generally involve several entities, typically at least one shipper of the goods, at least one logistics provider, for example a carrier, and a customer receiving the goods.

[0004] The logistics flow can logically be broken down into a number of operations, for example, goods packaging operations, goods transport operations, administrative operations, for example customs operations, for example, the provision of certificates of conformity.

[0005] The logistics flow must also sometimes be carried out in compliance with delivery conditions, for example, the location of the goods, temperature or humidity for the proper preservation of the goods,...

[0006] There is a general need to allow, as the delivery progresses, or even later, authorized persons but in a confidential manner, to obtain good visibility on the various operations, conditions and events that occur during the delivery.

[0007] There is no satisfactory system to date. Object and summary of the invention

[0008] Thus, the invention proposes a method for controlling the delivery of goods, said method being implemented by a control system and comprising: - a step of registering at least one user with an access management module of said control system and providing means of authentication to a workstation of said at least one user; - a step involving the downloading, from the workstation of said user, of a delivery configuration file, this file containing information on at least one operation to be carried out during said delivery, said download being conditional upon authentication of said user using said authentication method provided to said user and upon verification of their rights user to perform said download in view of a user role and their rights in accordance with a security policy; - a step of recording the result of at least one said operation in a delivery visibility database upon request from a user, said recording being conditional upon authentication of said user and verification of that user's right to formulate said request in view of a user role and their rights in accordance with said security policy; and - a step of recording at least one transaction representative of said at least one operation and a signature of said transaction in an immutable and verifiable audit database, said signature being made using a private key of said system.

[0009] Correspondingly, the invention relates to a system for controlling the delivery of goods, this system comprising: - an access management module configured to register at least one user and to provide authentication means to a workstation of said at least one user; - a download module, from the workstation of said user, for a delivery configuration file, this file containing information on at least one operation to be carried out during said delivery, said download being conditional upon: (i) authentication of said user by said access management module using said authentication means provided to that user and by (ii) verification, by a security policy application module, of that user's right to perform said download in view of a user role and their rights in accordance with said security policy; - a delivery visibility management module configured to record the result of at least one said operation in a delivery visibility database upon request from a user, said recording being conditional upon: (i) the authentication of said user by said access management module and by (ii) the verification, by a security policy application module, of that user's right to formulate said request in view of a user role and their rights in accordance with said security policy; - said visibility management module being configured to record at least one representative transaction of said at least one operation and a signature of said transaction in an immutable and verifiable audit database, said signature being made using a private key of said system.

[0010] Thus, and in general, the invention proposes a method and a system for controlling the delivery of goods, this method and this system offering the pos ability for authorized persons to access and monitor data and statuses relating to critical operations in the delivery process.

[0011] Indeed, in one embodiment, the process according to the invention includes, upon request from a user, a step of querying the visibility database, this query being conditioned by an authentication of this user and by the verification of a right of this user to formulate this request in view of a role of the user and his rights in accordance with said security policy.

[0012] The invention proposes to define the operations and conditions of delivery in a configuration file and to control that this configuration file is actually downloaded by an authenticated and authorized person.

[0013] Thus, downloading and any subsequent access to the system according to the invention by a user, in reading and writing, can only be done by authenticated users and in compliance with a security policy.

[0014] In one embodiment of the invention, the security policy conforms to the ABAC model.

[0015] It is recalled that an ABAC policy (in English "Attributes-Based Access Control") is an access control model that uses user, resource and condition attributes to determine whether a user is allowed to access a given resource.

[0016] Furthermore, and very advantageously, the invention proposes, for each operation recorded in the visibility database, to record a corresponding transaction and the signature of this transaction in another database, the latter being immutable and unforgeable.

[0017] Very advantageously, the signatures are all generated using a secret private key from the delivery control system.

[0018] - said visibility management module being configured to record at least a representative transaction of said transaction and at least one operation and a signature of said transaction in an immutable and verifiable audit database, said signature being made using a private key of said system.

[0019] This immutable and verifiable database can be a blockchain.

[0020] This database can be described as an audit database because it allows subsequent review of all relevant operations and events that occurred during delivery.

[0021] In one embodiment of the control method, the configuration file includes at least some of the following information: - information on data to be entered and on the persons authorized to carry out such entry; - information on at least one stage of transport of the goods; - information on at least one document to be downloaded and on the people authorized to perform this download; -the conditions of said delivery.

[0022] According to a particular embodiment of the invention, in addition to authorized users, connected objects can access the delivery control system in write and / or read mode, provided that these objects have been specifically referenced in the system by an authenticated user with rights to do so.

[0023] Thus, in one embodiment, data entered by an authorized person includes an identifier of a connected object configured to measure data representing delivery conditions of said goods, the method comprising: - a step of obtaining, by the connected object, data measurements representing delivery conditions, and recording these measurements in a delivery conditions database; - a step of recording at least one transaction representative of said measures and a signature of said transaction in the immutable and verifiable audit database, said signature being carried out using the private key of said system; and - if these measures do not comply with the conditions of said delivery, a step of recording these measures in an exception database.

[0024] This feature advantageously allows for real-time measurement of delivery conditions (location, temperature, humidity, shocks, light, or other factors), for example by attaching a connected device registered in the system to the goods. Each measurement is recorded as a transaction, with its signature, in the audit database.

[0025] In one embodiment, the invention proposes to implement an automatic anomaly detection mechanism, an anomaly being detected if the operations specified in the configuration file are not recorded as such in the visibility database. Any detected anomaly is recorded as a transaction with its signature in the audit database.

[0026] Thus, in one embodiment, the process comprises: - a step to verify the conformity of the information recorded in the visibility database with the information in the configuration file, and if not, a step to record an anomaly in an exception database; and - a step of recording at least one transaction representative of said anomaly and a signature of said transaction in the immutable and verifiable audit database, said signature being made using the private key of said system.

[0027] As mentioned above, when a measure does not conform to the conditions of delivery, it is subject, in addition to the recording of the corresponding transaction in the audit database, to a recording in an exception database.

[0028] In a particular embodiment, the invention proposes an automatic mechanism for processing these exceptions.

[0029] Thus, in one embodiment, the process comprises: - a step involving querying the exception database to identify measures that do not comply with the delivery conditions; and, where applicable: - a decision-making stage regarding the treatment to be applied to this said measure.

[0030] A treatment may, for example, consist of alerting a user.

[0031] In one embodiment, the conformity verification and non-conforming measurement processing steps are performed by an anomaly processing module trained to detect anomalies and to decide how to handle them from a set of rules and historical data.

[0032] In summary, the invention provides authorized users with visibility, possibly in real time, on relevant delivery information. This may include, in particular, information on the progress of operations, sensor values, status information, and documents.

[0033] All this information is the subject of a signed transaction recorded in the audit database. List of figures

[0034] Fig. 1 illustrates the main steps of a delivery control process according to a particular embodiment of the invention.

[0035] Figure 2 schematically represents a delivery control system according to a particular embodiment of the invention;

[0036] Fig. 3 is an example of a configuration file. Detailed description

[0037] Fig. 1 represents in flowchart form the main steps of a Pcl delivery control process according to a particular embodiment of the invention.

[0038] In the embodiment, this process is implemented by a KX delivery control system which will be described with reference to Figures 2 and 3 in an example scenario implementing the invention.

[0039] In the embodiment described here, the KX control method includes a step E10 for registering users authorized to interact with the KX system. This registration step includes, for example, a phase for initializing a password. pass and provision of user-specific authentication means (tokens, certificates, ...).

[0040] Such recording methods are known to those skilled in the art. They allow the KX system to verify, for each user access to the system, whether that user is an authorized user.

[0041] Then, as soon as a user wishes to access the KX system to perform an operation, the process checks during a step E20, on the one hand that the user is authenticated but also that the user has rights to perform this operation.

[0042] This is the case, for example, if a user requests to download a configuration FConf file for a delivery: the download of this file by a user (step F30) can only be carried out after authentication of the user and verification of the right of the user to carry out this download.

[0043] In a preferred embodiment, a user's rights to perform an operation are defined according to the user's role(s) and an AB AC type security policy.

[0044] Similarly, if a user wishes to save (step E40) the result of an operation or any other information in the KX system, this saving is conditional upon step E20, which involves user authentication and verification of the user's right to make such a saving request, based on their role and the rights defined by the security policy. Likewise, uploading a document to the KX system by a user is subject to the same requirements.

[0045] In the embodiment described herein, the KX system includes a visibility database in which all relevant delivery events are recorded, including those recorded by authorized users. These may include, for example, events related to the transport of the goods or the completion of formalities. Any information entered by an authorized user (relating, for example, to the batch number or serial number of the goods) is also recorded in this visibility database.

[0046] Similarly, if a user wishes to query this visibility database to obtain delivery information, the provision of such information is conditional upon the E20 step of user authentication and verification of the user's right to request this information in view of his role and rights defined by the security policy.

[0047] In one embodiment of the invention, the configuration file may include at least some of the following information: - information on data to be entered and on the persons authorized to perform this entry; - information on at least one stage of transport of the goods; - information on at least one document to be downloaded and on the people authorized to perform this download; -the conditions of said delivery.

[0048] In one embodiment of the invention, a user may also request that one or more connected objects perform data measurements representative of the delivery conditions of the goods. For example, the user may enter the serial number of such a connected object, this entry being authorized only after user authentication and verification of their rights in light of the security policy.

[0049] These connected objects are for example a temperature sensor, a GPS module, a humidity sensor, a shock detector (for example an accelerometer), a light detector attached to the goods to detect respectively the temperature or humidity at the level of the goods, whether the goods have been opened, or a possible shock.

[0050] When such a connected object has been validly declared and configured to perform the expected measurements, these measurements are carried out, for example regularly or at times defined in the configuration file, during a step referenced E60. These measurements are for example recorded in a delivery conditions database.

[0051] In the embodiment described here, if the KX system detects (step E70) that the measured data do not conform to those defined in the configuration file, they are recorded in an exception database (step E80).

[0052] In the embodiment described here, the PCL control process implements a mechanism for detecting anomalies and, for some of them, a mechanism for processing these anomalies.

[0053] In the embodiment described here, anomalies are dealt with by an expert system or by a module trained for this purpose which relies on a set of rules and on historical data.

[0054] Thus, during an E100 step, the anomaly management module checks the conformity of the information recorded in the visibility database with the information in the configuration file and in case of non-conformity, it records an anomaly in an exception database.

[0055] In the embodiment described here, the anomaly management module is further configured to handle the case of delivery condition measurements that do not conform to the configuration file.

[0056] Thus, during a step El 10, the anomaly management module queries the exception database to identify measures that do not conform to the conditions of delivery; and, where appropriate, decides on the treatment to be given to this measure.

[0057] In the embodiment described here, the delivery control process includes a step E90, implemented each time: -that information is recorded in the visibility database (step E40); - that a measurement of data representative of an environmental delivery condition is taken (step E60); - each time an anomaly is detected (step E100), this step consists of recording in an immutable and verifiable audit database, a transaction representative of this event and a signature of this transaction carried out using the system's private key.

[0058] This audit database offers complete traceability of delivery by aggregating information from the BDVis visibility database and the BDloT measurement database.

[0059] Fig. 2 represents a system and method for controlling the transport of goods according to an embodiment of the invention.

[0060] In the example of [Fig.2], three entities are considered, namely an EXP sender, A logistics provider (LOG) and a customer (CLT). For each of the three entities (EXP, LOG, CLT), three users are represented, namely: - a user with an ADM role of administrator EXP-ADM, LOG-ADM, CLT-ADM; - a user with an MNG role of manager (EXP-MNG, LOG-MNG, CLT-MNG); and - a user with an OP role as an EXP-OP, LOG-OP, CLT-OP operator.

[0061] Figure 2 also shows the workstation, for example a personal computer, a server, a tablet, or a smartphone, of each of these users. The workstation of the administrator (respectively, the manager, the operator) of the ENT entity (where ENT represents the shipper EXP, the logistics provider LOG, or the customer CLT) is denoted PCENTA (respectively PC|AVI, PCENT0).

[0062] The circled numbers represent steps that can be implemented in at least one particular mode of a goods transport control method according to a particular embodiment of the invention.

[0063] Registration of the MXP sender's EXP-MGR manager with the KX server

[0064] During step 1, the EXP-MGR manager of the EXP sender uses their PCEXpm workstation to register with the KX server. This registration can, for example, be carried out using a web page.

[0065] In the embodiment described here, during step 2, the EXP-MGR manager enters his first name, last name, email address, and name user EXP-MGR and the name of its EXP entity to an administration module MODAdmSer so that this information (or attributes) is stored (step 3) in a BDPERM permissions database.

[0066] During a general step 4, a M0DABAG module for applying an ABAC security policy periodically checks for new permissions recorded in the BDPERM permission database.

[0067] In step 5, the administration module M0DAdm registers the EXP-MNG manager of the EXP sender with an access management module M0DSGA (Identity Access Management System). This access management module M0DSGA is, for example, a cloud computing platform administered by a service provider, for example, the AWS platform (registered trademark, Amazon Web Services) of Amazon (registered trademark).

[0068] During a step 6, the access management module M0DSGA sends a request (for example an email) to the PCEXPm workstation of the EXP-MNG manager of the sender EXP to ask him to reset his password.

[0069] During step 7, the EXP-MNG manager of the sender EXP uses their PCEXPm workstation to change their password. In the embodiment described here, this step, which is known to those skilled in the art, is performed under the control of the M0DSGA access management module.

[0070] During step 8a, the access management module M0DSGA checks the attributes of the new user. If the check is successful, the access management module M0DSGA stores the password of the EXP-MNG administrator of the EXP sender and generates an authentication token (TOKEM) which is stored in the user's browser on their PCEXPM workstation in step 8. In the embodiment described here, this token is valid as long as the EXP-MNG administrator is communicating with the KX server. For example, it is invalidated by the KX server if the EXP-MNG administrator is inactive for a specified period, for example, 30 minutes. This TOKEM token ensures the validity and authenticity of the exchanges between the EXP-MNG user's browser and the KX server. Configuring a delivery flow

[0071] During step 9, the EXP-ADM administrator of the EXP sender uses their PCexpa workstation to register with the KX server. This step is similar to step 1 of the EXP-MNG manager's registration.

[0072] During step 10, the EXP-ADM administrator of the EXP sender changes their password at the request of the M0DSGA access management module. This step is similar to steps 6 and 7 for changing the password of the EXP-MNG manager.

[0073] During step 11, the M0DSGA access management module stores the password The EXP-ADM administrator's password generates a T0KEA authentication token, which is stored in the administrator's browser on their PCEXpA workstation. This step is similar to step 8; the T0KEA token ensures the validity and authenticity of the exchanges between the EXP-ADM administrator's browser and the KX server.

[0074] During step 12, the EXP-ADM administrator downloads a delivery configuration FConf file, this file containing information about operations to be carried out during said delivery. Alternatively, the administrator can use a user interface and create such a configuration file.

[0075] The FConf configuration file may also include information on data to be entered, for example batch numbers and / or serial numbers of goods, and the persons authorized to perform this entry.

[0076] The FConf configuration file may include information on one or more stages of transport of the goods, for example a place of departure and a place of arrival as well as the estimated date of this transport stage.

[0077] The configuration file may include information on documents to be downloaded (certificate of conformity, customs documents, delivery notes, ...) for example the type of this document, the estimated date of download, the persons authorized to carry out these downloads.

[0078] An example of an FConf configuration file is shown in [Fig. 3]. This file describes the steps of a delivery. In this example, the FConf configuration file contains one line for each step, this line containing: - an ET# column containing a number for this step; - an ETN column which contains a name for this step; - a VO column which includes a city from the start of this stage; - a PO column which includes a country of origin for this step; - an LgO column which includes the longitude of the starting point of this step; - an LtO column which includes the latitude of the starting point of this stage; - an EDO column which includes an estimated start date for this step; - a VD column which includes a city at the end of this stage; - a PD column which includes a country at the end of this stage; - a column LgD which includes the longitude of the end point of this step; - a LtD column which includes the latitude of the end point of this stage; - an EDD column which includes an estimated completion date for this step; - at least one RA action to be performed; - an RA# number for this RA action; - a type TA of this action ;; - a RESP identifier of the person responsible for this action; - possibly, a type of TD document to be recorded during said action; - a SW list of identifiers of people who can access the result of this action.

[0079] For some steps, the starting and ending location of a step may be identical.

[0080] In the embodiment described herein, the types of action TA include: - the UPL type: for a document download step; - the DATA type: for a data entry step; - the ACK type for a verification step.

[0081] In the embodiment described here, the TD document types include: - the COO type: for certificates of origin; - the COC type: for certificates of conformity; - the EPOD type for digital proof of delivery.

[0082] In the embodiment described here, the FConf configuration file also includes a table for storing identifiers of connected objects to be used to track delivery conditions.

[0083] In the example described here, this table includes: - a loT# column containing a connected object number; - a column MN containing a brand or type of connected object to be used; - a "Serial#" column intended to receive a serial number of a connected object of the brand or type of the MN column; - a condition to be measured, for example a temperature, a degree of humidity, a brightness, .... ; - a lower terminal BB and a higher terminal BH.

[0084] In the example in [Fig.2], the FConf configuration file describes a flow in four steps.

[0085] First step. - Step number (ET#): 1 - Step name (ETN): "Delivery preparation"; - City and country of origin of the starting location of the stage (VO, PO): "Pune, India"; - City and country of the end of the stage (VD, PD): "Pune, India"; - Longitude and latitude of the starting point of the stage (LgO, LtO): "73.94; 25.26" - Longitude and latitude of the stage end point (LgD, LtD): "73.94; 25.26" - Stage start date (EDO): "22 / 11 / 11" - End date of stage (EDD): "22 / 11 / 11".

[0086] Actions to be performed: - Action 1: Action to be performed RA: Download the certificate of origin. TA action type: UPL, download action; Responsible for the RESP action: the EXP-OP operator of the EXP sender; Document type to download TD: COO: certificate of origin. . Persons who may be made aware of the result of this action: LOG-OP (LOG-MNG operator of the logistics provider), LOG-MNG (manager of the logistics provider) and CLT-OP (operator of the client). - Action 2: Action to be taken RA: Download the certificate of conformity. TA action type: UPL, download action; Responsible for the RESP action: the EXP-OP operator of the EXP sender; Document type to download TD: COC: certificate of conformity. . Persons who may be made aware of the result of this action: LOG-OP (LOG-MNG operator of the logistics provider), LOG-MNG (manager of the logistics provider) and CLT-OP (operator of the client). - Action 3: Action to be performed RA: Enter the Lot# numbers of the goods, the Serial # numbers of the goods, and the loT# numbers of connected objects authorized to perform temperature measurements of the goods during delivery; Action type TA: DATA, data entry; Responsible for the RESP action: the EXP-OP operator of the EXP sender; . Persons who may be made aware of the result of this action: LOG-OP (LOG-MNG operator of the logistics provider), LOG-MNG (manager of the logistics provider) and CLT-OP (operator of the client).

[0087] Second step. - Name of stage (ESN): "Transport to Mumbai"; - City and country of origin of the starting location of the stage (VO, PO): "Pune, India"; - Longitude and latitude of this place (LgO, LtO): “73.94; 25.26" - City and country of the stage end location (VD, PD): “Mumbai, India”; - Longitude and latitude of this location (LgD, LtD): "72.87; 19.07" - Stage start date (EDO): "22 / 11 / 11" - End date of stage (EDD): "22 / 11 / 11"

[0088] Actions to be performed: - Action 1: Action to perform RA: Enter the flight number from Mumbai to Doha. Action type TA: DATA, data entry; Responsible for the RESP action: LOG-OP of the logistics provider LOG. Persons who may be informed of the result of this action: EXP-OP (sender's operator), EXP-MNG (sender's representative) and CLT-OP (customer's operator).

[0089] - Action 2: Action to be taken: Confirm that the export customs formalities in Mumbai have been completed. Action type TA: ACK, verification; Responsible for the RESP action: LOG-OP of the logistics provider LOG. Persons who may be aware of the result of this action: EXP-OP (sender's operator), EXP-MNG (sender's manager) and CLT-OP (customer's operator).

[0090] Third step. - Name of the stage (ESN): "Transport to Doha"; - City and country of the starting location of the stage (VO, PO): "Mumbai, India"; - Longitude and latitude of this place (LgO, LtO): “72.87; 19.07 » - City and country of the stage finish location (VD, PD): “Doha, Qatar”; - Longitude and latitude of this location (LgD, LtD): "51.43; 25.28" - Stage start date (EDO): "22 / 11 / 11" - End date of stage (EDD): "22 / 11 / 12".

[0091] Actions to be performed: - Action 1: Action to be taken RA: Confirm that the export customs formalities in Doha have been completed. Action type TA: ACK, verification; Responsible for the RESP action: LOG-OP of the logistics provider LOG. Persons who may be aware of the result of this action: EXP-OP (sender's operator), EXP-MNG (sender's manager) and CLT-OP (customer's operator).

[0092] Fourth step. - Name of the stage (ESN): "Transport to the customer"; - City and country of the starting location of the stage (VO, PO): "Doha, Qatar"; - Longitude and latitude of this place (LgO, LtO): “51.43; 25.28" - City and country of the stage finish location (VD, PD): “Rumaylah, Qatar”; - Longitude and latitude of this location (LgD, LtD): "72.87; 19.07" - Stage start date (EDO): "22 / 11 / 12" - End date of stage (EDD): "22 / 11 / 12"

[0093] Actions to be performed: - Action 1: Action to be performed RA: Download the proof of delivery note. TA action type: UPL, download action; Responsible for the RESP action: the CLT-OP operator of the CLT client; Document type to download EPOD: COO: electronic proof of delivery. Persons who may be aware of the result of this action: EXP-OP (shipper's operator), EXP-MNG (shipper's manager) and LOG-OP (logistics provider's operator).

[0094] In the example described here, this table includes: - a Nb column containing a connected object number; - a column MN containing a brand or type of connected object to be used; - a "Serial#" column intended to receive a serial number of a connected object of the brand or type of the MN column; - a condition to be measured, for example a temperature, a degree of humidity, a brightness, .... ; - a lower terminal BB and a higher terminal BH.

[0095] In the example in [Fig.2], the connected objects table of the Fconf configuration file contains: - a single connected object (Nb=l); - of the XYZ brand (MN column); - to measure a temperature condition (COND column): - the temperature must be between 24° (lower limit BB) and 26° (upper limit BH).

[0096] During a step 13, the ABAC security policy application M0DABAC module checks whether the EXP-ADM administrator of the EXP sender was authorized (step 12) to download the dTivraison flow configuration FConf file.

[0097] For this purpose, it uses lines 1 to 7 of the security policy in Annex 1.

[0098] If the M0DABAC module verifies, in view of the ABAC security policy, that The EXP-ADM administrator of the EXP sender was authorized to download the FCoxh configuration file. The M0DABAC module applies the ABAC security policy and forwards a request to manage delivery visibility to a MODVis delivery visibility management module.

[0099] During a step 14, the MODVis visibility management module saves the information from the FConf configuration file into a BDVis delivery visibility database. Execution of the delivery flow steps

[0100] We now describe the execution of the delivery flow steps.

[0101] During step 15, the EXP-OP operator of the EXP sender uses their PCEXpo workstation to register with the KX server. This step is similar to step 1 of the EXP-MNG manager's registration.

[0102] During step 16, the EXP-OP operator of the EXP sender changes their password at the request of the M0DSGA access management module. This step is similar to steps 6 and 7 for changing the password of the EXP-MNG manager.

[0103] During a step 17, the access management module M0DSGA stores the password of the EXP-OP operator and generates a TOKeo authentication token which is stored in the browser of this operator, in his PCexpo workstation. This step is similar to step 8, the TOKeo token ensuring the validity and authenticity of the exchanges between the EXP-OP operator's browser and the KX server.

[0104] During step 18, the EXP-OP operator downloads the COO certificate of origin (as required by the FConf- configuration file for the delivery flow (step 1 "Delivery Service", RAI action "Download certificate of origin")). The MODAbac module for applying the AB AC security policy checks whether the EXP operator of the EXP sender is authorized to download TD-type documents containing the COO certificate of origin.

[0105] For this purpose, it uses lines 17 to 24 of the security policy in Annex 1.

[0106] Only if it is determined that the operator is authorized to download this certificate, during a step 19, the MODVis visibility management module records in the visibility database BDNis information that the original certificate COO has been downloaded and the MODVis visibility management module records the original certificate COO in the document database BDD0C during a step 20.

[0107] During step 21, the EXP-OP operator downloads the COC certificate of conformity (as required by the FConf- configuration file for the delivery flow (step 1 "Delivery Service", action RA2 "Download Certificate of Conformity")). The ABAC security policy application module M0DABAG checks whether the EXP operator of the EXP shipper is authorized to download documents of type TD COC certificate of conformity.

[0108] For this purpose, it uses lines 25 to 33 of the security policy in Annex 1.

[0109] During step 22, the MODVis visibility management module updates the BDNis visibility database to indicate that the download of the COO certificate of conformity was carried out on 22 / 11 / 11 in Pune by the operator EXP-OP.

[0110] During a step 23, the MODVis visibility management module registers the COC compliance certificate in the BDd0C document database.

[0111] During step 24, the EXP-OP operator enters the Lot# numbers of the goods and the Serial# numbers of the goods. In the example described here: Lot# = ABCXR123 Serial # = 123456789

[0112] It also captures the serial number "Serial #" of a connected object from the brand MN to monitor the temperature of the merchandise. In the example described here; IoT#=K12345.

[0113] During a step 25, the ABAC security policy application M0DABAC module checks whether the EXP-OP operator of the EXP sender is authorized to enter this information.

[0114] For this purpose, it uses lines 35 to 42 of the security policy in Annex 1.

[0115] Only if this is the case, during step 26 the MODVis management module Visibility updates the BDVis visibility database by recording the following information: "Delivery of Batch # =ABCXR123, Serial # =123456789, Temperature to be monitored between 24°C and 26°C via IoT #=K12345."

[0116] During this same step, the EXP-OP operator defines the temperature to be monitored by the connected object loT with serial number IoT#=K12345, namely the allowed range [24°C, 26°C].

[0117] During step 27, the MODVis visibility management module records representative transactions in an immutable and verifiable audit database BDaud1t, and the KX server signs these transactions with its private key. The information recorded in this database is tamper-proof and unforgeable. New transactions can be recorded, but recorded transactions cannot be destroyed or modified. Recording of conditions by the IoT

[0118] In the embodiment described here, when a connected object has been declared and configured to monitor the conditions of a delivery (step 26), a MODloT connected object management module obtains, for example regularly, during a step 28, measurements taken by these connected objects and records these measurements in a BDloT delivery conditions database (step 29).

[0119] If the measurements are not within the range defined in the FConf configuration file, the corresponding transactions are logged in a BDEXC exception database. For example, the following transaction is logged: "Temperature detected of 28°C on 22 / 11 / 11 by the connected object loT# = K12345."

[0120] During a step 30, the MODloT connected object management module of the flow records all transactions in the audit database BDaud1t and the KX server signs these transactions with its private key.

[0121] Interactions with the logistics provider's operator

[0122] During a step 31, the LOG-OP operator of the logistics provider LOG uses his PCLOgo workstation to register with the KX server.

[0123] During step 32, the LOG-OP operator changes his password on request of the MODSga access management module-

[0124] During step 33, the access management module M0DSGa stores the password of the LOG-OP operator and generates a TOKlo authentication token which is stored in the browser of this operator, in his PCLOgo workstation-

[0125] During a step 34, the LOG-OP operator checks whether customs formalities have been completed in Mumbai by querying the BDNis visibility database.

[0126] During a step 35, the M0DABAC module for applying the ABAC security policy checks whether the LOG-OP operator of the logistics provider LOG is authorized to perform this check according to the security policy.

[0127] For this purpose, it uses lines 43 to 52 of the policy presented in Annex 1.

[0128] Only if this is the case, during step 36 the MODVis management module The visibility updates the delivery flow management information visibility database to indicate that customs formalities were completed in Mumbai on 22 / 11 / 11 by the operator LOG-OP. Anomaly detection

[0129] The KX server includes a MODA1 anomaly detection module trained to detect events that do not conform to the procedure defined in the Fconf configuration file.

[0130] For this purpose, the anomaly detection module M0DA1 accesses, for example regularly: - to the BVis visibility database to identify the events predicted by the Fconf configuration file; and - to the BDEXc exception database to check if temperature measurements not conforming to the requirements of the Fconf configuration file have been recorded there.

[0131] In the example described here, the action of the third step* Transport to Doha" provides that confirmation of the completion of export customs formalities in Doha must be carried out on 22 / 11 / 12.

[0132] If the anomaly detection module M0DA1 detects (during a step 37) that these formalities have not been carried out, it records an exception in the exception database BDEXC.

[0133] During a step 38, the anomaly detection module M0DA1 records a transaction representative of said exception in the audit database BDaud1t and the KX server signs these transactions with its private key.

[0134] Similarly, the FConf configuration file includes an indication that the temperature of the goods must be between 24° (lower limit BB) and 26° (upper limit BH).

[0135] If the M0DA1 anomaly detection module detects (step 39) by querying the BDEXC exception database a temperature measurement outside of this beach, it decides how to handle this exception during a step 40. It uses for example a set of decision rules and a history of temperature measurements.

[0136] For example, one action may consist of alerting users who have access to the workflow.

[0137] If the anomaly detection module M0DA1 detects (during a step 42) that goods are not in an expected location at a given time, for example in this example in Mumbai on the morning of 22-11-12, it decides, based on a set of rules, whether a

[0138] During step 44, the anomaly detection module M0DA1 records the exception in the audit database BDaud1t and the KX server signs these transactions with its private key. Interactions with the customer's operator

[0139] During a step 45, the customer's CLT-OP operator uses his PCclto workstation to register with the KX server.

[0140] During a step 46, the CLT-OP operator changes his password at the request of the access management module M0DSGa.

[0141] During a step 47, the access management module M0DSGa stores the password of the operator CLT-OP and generates an authentication token TOKCo which is stored in the browser of the workstation PCclto of this operator.

[0142] During a step 48, the CLT-OP operator queries the KX server to find out where the goods are located.

[0143] During step 49, the M0DABAG module for applying the ABAC security policy checks whether the CLT-OP operator of the logistics provider LOG is authorized to obtain this information and only if so provides him with the location information recorded in the visibility database BDVis-ANNEXE 1

[0144] 1:{

[0145] 2: "application": "KATALX_APP"

[0146] 3: "comment":

[0147] 4: "version": "20220831",

[0148] 5: "policy": {

[0149] 6: "rules": [

[0150] 7: {

[0151] 8: "resource": "F-config",

[0152] 9: "action": "DOWNLOAD",

[0153] 10: "conditions": [

[0154] 11 "principakrole = 'ADM'",

[0155] 12 "&principal:organization = 'EXP'"

[0156] 13 "&principal:status = 'active'"

[0157] 14 ]

[0158] 15},

[0159] 16 {

[0160] 17 "resource": "COO-doc",

[0161] 18 "action": "DOWNLOAD",

[0162] 19 "conditions": [

[0163] 20 "principakrole = 'OP'",

[0164] 21 "&principakorganization = 'EXP'"

[0165] 22 "&principak status = 'active'"

[0166] 23 ]

[0167] 24},

[0168] 25 {

[0169] 26 "resource": "COC-doc",

[0170] 27 "action": "DOWNLOAD",

[0171] 28 "conditions": [

[0172] 29 "principakrole = 'OP'",

[0173] 30 "&principakorganization = 'EXP'"

[0174] 31 "&principak status = 'active'"

[0175] 32 ]

[0176] 33},

[0177] 34 {

[0178] 35 "resource": "SHIPMENT-details",

[0179] 36 "action": "EDIT",

[0180] 37 "conditions": [

[0181] 38 "principakrole = 'OP'",

[0182] 39 "&principakorganization = 'EXP'"

[0183] 40 "&principak status = 'active'"

[0184] 41 ]

[0185] 42},

[0186] 43 {

[0187] 44 "resource": "CUSTOMS",

[0188] 45 "action": "EDIT",

[0189] 46 "conditions": [

[0190] 47 "principakrole = 'OP'",

[0191] 48 "&principakorganization = 'LOG'",

[0192]

[0193]

[0194]

[0195]

[0196]

[0197]

[0198]

[0199]

[0200]

[0201]

[0202]

[0203]

[0204]

[0205]

[0206]

[0207]

[0208]

[0209]

[0210]

[0211]

[0212]

[0213] 49: "&principal:region = 'IN'", 50: "&main:status = 'active'" 51:] 52:}, 53: 54: "resource": "key" 55: "action": "share" 56: “conditions”: (28) 57: "main: status = 'active'" 58: 59: "resource": "key" 60: "action": "to obtain" 61: “conditions”: (32) 62: "main: location and ['na']", 63: "& principal: department and context: masterKeylnfo: encryption: department" 64: " & context: masterKeylnfo :cryptage :expiration>NOW()" 65: 66: "resource": "recordingDescription" 67: "action": "decipher" 68: “conditions”: 69: "main: decryptionKeys and context DecryptionKeys", 70: " & context:decryptionKey:expiration>NOW()"

Claims

Claims

1. Method for controlling the delivery of goods, said method being implemented by a control system (KX) and comprising: - a step (E10, 1, 5) of registering at least one user (EXP-MGR) with an access management module (MODSga) of said control system (KX) and of providing (8) authentication means (TOKem) to a workstation (PCEXpm) of said at least one user (EXP-MGR); - a step (E30, 12) of downloading, from the workstation of a said user (EXP-MGR) a configuration file (FConf) of the delivery, this file (FConf) comprising information on at least one operation to take place during said delivery, said downloading being conditioned by (E20) an authentication (11) of said user from said authentication means (TOKem) provided to this user and by the verification (13) of a right of this user to carry out said downloading in view of a role (OP) of the user and his rights in accordance with a security policy; - a step (E40, 19, 22, 26, 36) of recording a result of at least one said operation in a delivery visibility database (BDVis) upon request (18, 21) from a user, said recording being conditioned (E20) by an authentication of said user and by the verification (4) of a right of this user to formulate said request in view of a role (OP) of the user and his rights in accordance with said security policy; and - a step (E90, 27) of recording at least one transaction representative of said at least one operation and a signature of said transaction in an immutable and verifiable audit database (BDaud), said signature being carried out using a private key of said system (KX).

2. Method for controlling the delivery of goods according to claim 1 in which said configuration file (FCONF) comprises at least certain information among: - information on data to be entered and on the persons authorized to carry out this entry; - information on at least one stage of transport of the goods; - information on at least one document to download and on the persons authorized to carry out this download; - the delivery conditions of said delivery.

3. Control method according to claim 2, wherein said data entered (24) by an authorized person (EXP-OP) comprise an identifier of a connected object configured to measure data representative of delivery conditions of said goods, the method comprising: - a step (E60, 28) of obtaining, by the connected object, measurements representative of conditions of said delivery, and (29) of recording these measurements in a conditions database (BDloT); - a step (E90, 30) of recording at least one transaction representative of said measurements and a signature of said transaction in said immutable and verifiable audit database (BDAud), said signature being carried out using the private key of said system (KX); and - if said measurements do not comply with the conditions of said delivery (E70), a step (E80) of recording said measurements in an exception database (BDEXc).

4. Control method according to one of claims 1 to 3, comprising, upon request (31, 48) from a user, a step (E50, 49) of querying the visibility database (BDVis), said query being conditioned (E20) by authentication of said user and by verification (33, 47) of a right of this user to formulate said request in view of a role (OP) of the user and his rights in accordance with said security policy.

5. Control method according to one of claims 1 to 4, comprising: - a step (E100, 37) of verifying the conformity of the information recorded (19, 22, 26, 36, 42) in the visibility base (BDVis) with respect to the information in the configuration file (FConf) and in the event of non-conformity a step of recording an anomaly in an exception database (BDEXC); and - a step (E90, 38) of recording at least one transaction representative of said anomaly and a signature of said transaction in said immutable and verifiable audit database (BDAud), said signature being carried out using the private key of said system (KX).

6. Control method according to claim 3, comprising: - a step (El 10, 39) of querying the exception database (BDexc) to identify measurements that do not comply with the delivery conditions; and, where applicable: - a step (El20, 40) of deciding on the processing to be carried out on this said measurement.

7. Control method according to claim 5 and 6 characterized in that said steps (E1 10, 37) of verification of conformity and (E120, 40) of processing of non-conforming measurement are implemented by an anomaly processing module (M0DA1) trained to detect anomalies and to decide on their processing from a set of rules and historical data.

8. A control method according to any one of claims 1 to 7 wherein 1 the security policy is in accordance with the AB AC model.

9. System (KX) for controlling the delivery of goods, said system (KX) comprising: - an access management module (MODS ga) configured to register at least one user (EXP-MGR) and to provide authentication means (TOKem) to a workstation (PCEXpm) of said at least one user (EXP-MGR);- a download module, from the workstation of a said user (EXP-MGR) of a configuration file (FConf) of the delivery, this file (FConf) comprising information on at least one operation to be carried out during said delivery, said download being conditioned by: (i) authentication of said user by said access management module (M0DSGa) from said authentication means (TOKEM) provided to this user and by (ii) verification (4), by a module (M0DABAC) for applying a security policy, of a right of this user to carry out said download in view of a role (OP) of the user and his rights in accordance with said security policy;- a delivery visibility management module (MODVis) configured to record a result of at least one said operation in a delivery visibility database (BDVis) upon request (18, 21) from a user, said recording being conditioned by: (i) the authentication of said user by said access management module (M0DSga) and by (ii) the verification (4), by an application module (M0DABAC) of a; security policy, of a right of this user to formulate said request in view of a role (OP) of the user and his rights in accordance with said security policy; - said visibility management module (MODVIS) being configured to record at least one transaction representative of said at least one operation and a signature of said transaction in an immutable and verifiable audit database (BDaud), said signature being carried out using a private key of said system (KX).

Images