WO2016083161A1 - Procede et systeme de gestion de consignes de livraison, et installation de livraison mettant en oeuvre un tel procede et/ou un tel systeme - Google Patents

Procede et systeme de gestion de consignes de livraison, et installation de livraison mettant en oeuvre un tel procede et/ou un tel systeme Download PDF

Info

Publication number
WO2016083161A1
WO2016083161A1 PCT/EP2015/076557 EP2015076557W WO2016083161A1 WO 2016083161 A1 WO2016083161 A1 WO 2016083161A1 EP 2015076557 W EP2015076557 W EP 2015076557W WO 2016083161 A1 WO2016083161 A1 WO 2016083161A1
Authority
WO
WIPO (PCT)
Prior art keywords
setpoint
user
phase
operator
delivery
Prior art date
Application number
PCT/EP2015/076557
Other languages
English (en)
Inventor
Sandrine RESSAYRE
Original Assignee
Ier
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ier filed Critical Ier
Publication of WO2016083161A1 publication Critical patent/WO2016083161A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G06Q10/0836—Recipient pick-ups
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G06Q10/0833—Tracking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G06Q10/0834—Choice of carriers

Definitions

  • the present invention relates to a method of managing delivery instructions. It also relates to a system implementing such a method and an installation implementing such a method and / or such a system.
  • the field of the invention is the field of the management of automated orders of delivery of objects, and in particular parcels.
  • this system does not guarantee the delivery of the object, for example when no delivery order is available during the passage of the deliveryman.
  • the delivery success rate to be high, it is necessary to provide a large number of instructions, which increases the cost of the system and its size.
  • the delivery of objects with this system is not fast and ergonomic for the user. Indeed, the user must move before the instruction to see the presence or not of an object that has been delivered.
  • An object of the present invention is to overcome the aforementioned drawbacks.
  • Another object of the invention is to provide a delivery management method and system for delivering a more ergonomic and more flexible delivery for the user.
  • Another object of the invention is to provide a method and a management system of delivery instructions to reduce costs and congestion related to delivery instructions.
  • Yet another object of the invention is to provide a method and a management system of delivery instructions allowing a greater success rate of delivery. Presentation of the invention
  • the invention proposes to achieve at least one of the aforementioned objects by a method of managing instructions for the delivery of objects, in particular parcels, said method comprising the following steps:
  • identification of at least one available setpoint that can accommodate said object by consulting a database, called a set of instructions,
  • the method according to the invention makes it possible to carry out a delivery of packages in instructions, by first determining the availability of a deposit that can accommodate the object before making the delivery.
  • the setpoint management method according to the invention avoids a deliveryman to move with the object if there is no set available to accommodate the object upon delivery.
  • the method according to the invention thus allows a 100% delivery rate.
  • the method according to the invention makes delivery more flexible and more ergonomic for the user because it avoids informing a user of the delivery of its object when no deposit is available to accommodate the object.
  • it is possible to inform the user for example through a wireless communication network, once an available setpoint that can accommodate the object is identified.
  • the method according to the invention when the user is notified for the delivery of his object, it is guaranteed that a deposit will be available to accommodate his object and therefore that the delivery will actually be made. This avoids the user to move to the deposit by believing that his object is delivered, while the delivery man could not deliver it for lack of available instructions.
  • the method of managing instructions according to the invention makes it possible to reduce the costs associated with delivery by avoiding a new passage for delivery.
  • the method according to the invention makes it possible to provide on each site a set of instructions comprising a lower number of instructions by adapting the delivery times to the availability of the instructions, which allows less bulky and less expensive instructions.
  • a deposit is a locker or a set of lockers, each locker being provided with a door controlling the access to said locker and can be locked in the closed position.
  • the locker or set of lockers further comprises: means for reading a biometric identification data item, and / or means for reading an identification data item from an identification means, and / or means for entering an identification data item , such as an alphanumeric keyboard;
  • means for controlling such a locking / unlocking means optionally, means for controlling such a locking / unlocking means
  • the step of identifying an available setpoint can be carried out further according to at least one item relating to the nature, to a size and / or to a weight of the object to be delivered.
  • the instruction to accommodate this object must allow to meet this condition.
  • the set of instructions database can include for at least one, in particular for each, setpoint data relating to the nature, to a size and / or weight of one or objects that said deposit can accommodate .
  • the method according to the invention can comprise between the deposition phase and the withdrawal phase, a so-called end of control management phase, comprising the following steps performed for each instruction:
  • Such an end of setpoint management phase makes it possible to accelerate the release of the setpoints, and to reduce the occupation time of a setpoint or to increase the number of setpoints available. Indeed, when the user delays in removing his object, he is alerted to come and remove it as soon as possible and thus release the deposit for a next delivery for example.
  • This end-of-order management phase makes it possible to further reduce the number of instructions on each site, and thus to reduce the cost and the congestion presented by the instructions.
  • the management end of instructions also reduces the average time of delivery of objects.
  • the method according to the invention may further comprise following transmission of the alert message, a transmission of the user to the central site of a request message of:
  • the user performs the removal of the object as described above in a predetermined period of time.
  • the method according to the invention may comprise the removal phase of the object as described above.
  • said withdrawal phase may furthermore understand a step of payment by the user of an amount after the authentication step.
  • the amount can be a predetermined fixed amount, or determined according to the additional duration or movement of the object.
  • the method according to the invention may further comprise a so-called return phase following the withdrawal phase, said return phase comprising the following steps:
  • Such a return phase makes it possible to use the instructions, not only for the delivery of the object to the user, but also the object deliveries from the user to a third party as part of a return delivery.
  • the method of management of instructions according to the invention thus makes it possible to propose new functionalities to the users.
  • the setpoint management method may comprise a phase, referred to as removal of the object, by an operator, said removal phase comprising the following steps:
  • the method according to the invention may comprise, for each setpoint, a modification of a state data item of said stored setpoint with an identifier of said setpoint in the setpoint database:
  • the state data can be modified in real time, according to data communicated by the operator or the user.
  • the state data can be updated according to data communicated by at least one presence sensor located at each instruction and can signal the presence and / or absence of an object in setpoint.
  • at least one presence sensor located at each instruction and can signal the presence and / or absence of an object in setpoint.
  • an instruction "to be released”, comprising an object to be returned and can be released by an operator at the time of delivery of an object, or
  • the setpoint management method may further comprise a signaling step:
  • At least one of these signaling steps can be performed by the user and / or the operator and / or the instruction concerned.
  • At least one of these signaling steps can be performed through a wireless communication network, such as 3G, 4G, 5G, Wifi, Bluetooth, etc. Alternatively or in addition, at least one of these signaling steps can be performed through a wired communication network, such as the ADSL, SDSL, etc. network. At least one data item received during at least one of these signaling steps may be used to update or modify a state data item related to the concerned instruction.
  • a wireless communication network such as 3G, 4G, 5G, Wifi, Bluetooth, etc.
  • a wired communication network such as the ADSL, SDSL, etc. network.
  • At least one data item received during at least one of these signaling steps may be used to update or modify a state data item related to the concerned instruction.
  • At least one authentication step of the operator may comprise an entry by said operator at said setpoint of an access code or identification data of said operator.
  • the access code or the identification data can be communicated (e) to the operator before the operator authentication step, through a wireless communication network, for example on a smartphone of the operator.
  • At least one access code can be a code entered through a keyboard provided at the setpoint, or for a group of instructions.
  • the identification data can be read from an identification means, such as an identification card comprising a bar code or a QR code or an RFID identification card, or an NFC card, or a card. chip.
  • the access code or the identification data used for the authentication step of the operator is the access code or the identification data used for the authentication step of the operator.
  • During the removal phase can be communicated to the operator, and / or the setpoint, after the return phase.
  • At least one authentication step of the user may include an entry, at said setpoint, an access code or identification data by said user.
  • the access code or the identification data can be communicated to the user before the user authentication step, through a wireless communication network, for example on a smartphone of the user.
  • At least one access code can be a code entered through a keyboard provided at the setpoint, or for a group of instructions.
  • the identification data can be read from an identification means, such as an identification card comprising a bar code or a QR code or an RFID identification card, or an NFC card, or a card. chip.
  • an identification means such as an identification card comprising a bar code or a QR code or an RFID identification card, or an NFC card, or a card. chip.
  • the access code or the identification data used for the authentication step of the user is a prefix or the identification data used for the authentication step of the user.
  • the method according to the invention comprises, prior to the authentication step, a step of transmission towards the access code setpoint, or the identification data, or else a verification algorithm access code or identification data, prior to the authentication step.
  • This transmission step can be performed through a wired or wireless communication network.
  • the verification of an access code or identification data, during an authentication step, of the user or the operator can be performed on a central site distant from the deposit.
  • the method according to the invention comprises, during the authentication step, a step of transmission from the setpoint to the central site of the access code, or of the identification data entered by the user. , respectively the operator.
  • This transmission step can be performed through a wired or wireless communication network.
  • a step of depositing the object, and / or a step of removing the object, and / or a step of removing the object can comprise an entry of an identification data item. object at the setpoint.
  • the identification data of the object can be entered on a keyboard provided for this purpose, or read by an optical or magnetic type reader.
  • the validation of at least one, preferably each, of these steps may be conditioned on a reading of said object identification data, and possibly on a comparison of said identification data with a given data item.
  • identification code previously stored in the setpoint database, or in a history database of the delivered objects, possibly in association with an identifier of said setpoint.
  • This identification data of the object can be included in the delivery data received during the removal phase and kept throughout the process.
  • the method according to the invention can be implemented for the management of several setpoints or remote setpoint groups one of the others, preferably from the single central site.
  • the method according to the invention may further comprise, before the step of identifying an available setpoint, a step for determining whether at least one other object can be delivered for the same user or for the same delivery address, for example. consultation of a database, called objects, storing the data relating to the objects to be delivered, according to the relative data.
  • the objects can be delivered by the same operator, and preferably in the same setpoint.
  • the method according to the invention makes it possible to group the deliveries of objects for the same user, in the same instruction, which makes it possible to reduce the costs, the pollution, the labor and the infrastructure necessary for the delivery. of these objects.
  • the method according to the invention may further comprise, before the step of identifying an available setpoint, a step of identifying at least one other object whose delivery is provided for the same user or for the same address delivery, but not yet available for delivery.
  • the method according to the invention may comprise a step, informing the user of this situation and proposing a group delivery.
  • the process is stopped until the availability of said other object and the process resumes when said other object is available for delivery.
  • the method according to the invention makes it possible to group the deliveries of several objects for the same user or for the same delivery address, which makes it possible to reduce the costs, the pollution, the manpower and the infrastructure necessary to the delivery of these objects.
  • the method according to the invention may further comprise, before the step of identifying an instruction available for the delivery of the object, a step of identifying at least one other object to be delivered to the same user or for the same delivery address by another operator.
  • the identification step determines whether said setpoint already reserved can accommodate the object to be delivered in addition to said other object according to the data relating to the size and nature of the objects, the compatibility between the objects, etc. . :
  • the instruction already reserved is selected for the delivery of this object, possibly after confirmation with the user;
  • this instruction is reserved for all objects, possibly after confirmation with the user. Then, the identifier of the instruction is communicated to the operators responsible for delivering this object and the other object;
  • a management system of instructions for the delivery of objects, in particular parcels comprising:
  • a central server remote from said setpoints, connected to each of said setpoints through a communication network
  • a setpoint database storing, for each setpoint, a state datum of said setpoint in association with an identifier of said setpoint, and
  • an installation comprising:
  • FIGURES 1-5 are a diagrammatic representation in the form of a diagram of a nonlimiting exemplary embodiment of the method according to the invention.
  • FIG. 6 is a schematic representation of a nonlimiting exemplary embodiment of a system according to the invention.
  • - FIGURE 7 is a schematic representation of a non-limiting embodiment of an installation according to the invention.
  • FIGURE 8 is a schematic representation of a non-limiting example of a setpoint that can be used in the context of the present invention.
  • FIGURES 1-5 give a diagrammatic representation in the form of a diagram of an exemplary embodiment of a method 100 for managing instructions according to the invention.
  • FIGURE 1 is a representation of an example of a deposition phase 102 of the process 100 shown in FIGURES 1-5.
  • the removal phase comprises a step
  • Delivery data may include data relating to: - an identity of the user to whom the object is to be delivered,
  • This delivery data can be received by a central site, in particular by a central server that performs the management of the instructions.
  • a subscription request may be required to the user and a subscription step may be performed, the user providing the necessary information for identification.
  • an available setpoint is identified by consulting a setpoint database storing for each instruction its location. and his state of availability.
  • This database can be stored at the central site or in the central server.
  • step 106 is repeated at a later time, for example 1 hour later.
  • the setpoint is reserved during a step 108.
  • the setpoint status data is changed to "reserved setpoint" in the database, for example by the server. central.
  • the data relating to the object are stored in association with the identifier of the instruction.
  • an access code to the setpoint is generated and transmitted to the operator who must deliver the object, possibly with an identifier of the setpoint and an address of the setpoint.
  • the access code can be transmitted to the operator via a wireless communication network, such as the mobile telephone network, on the smartphone or a portable device of the operator connected to this wireless communication network. .
  • An acknowledgment of receipt of the access code may be issued by the operator.
  • the access code to the setpoint can also be sent to the setpoint and stored at the setpoint.
  • the transmission of the code access to the setpoint can be transmitted through a wireless communication network, such as that used for the operator, or a wired communication network of ADSL type.
  • the transmission of the access code to the operator, and possibly to the setpoint, can be performed by the central site or the central server.
  • the access code generated can be stored in association with an identifier of the setpoint.
  • the object is transported to the setpoint, for example using an electric vehicle.
  • a step 114 the operator authenticates at the setpoint by entering the access code, possibly after selecting the reserved setpoint, for example using an alphanumeric keyboard.
  • the access code entered by the operator is compared with the access code generated and sent to the operator during step 110. This comparison can be carried out either at the setpoint level or by the central server.
  • an identifier of the object can also be entered by the operator and compared to the identifier of the object stored in step 108.
  • step 114 If in step 114 authentication is not successful, step 114 can be repeated.
  • step 114 If in step 114 the authentication is successful, the setpoint is unlocked during step 116, either by a local command or by a remote command issued for example by the central site.
  • step 118 the object is positioned in the setpoint and the setpoint is locked.
  • a step 120 carries out a signaling of the deposit of the object in the setpoint by sending a notification to the central site.
  • an access code to the setpoint containing the object is generated and transmitted to the user, possibly with an identifier of the setpoint.
  • the access code can be transmitted to the user via a wireless communication network, such as the mobile telephone network, on the smartphone or a portable device of the user connected to it. wireless communication network.
  • An acknowledgment of receipt of the access code may be issued by the user.
  • the access code to the setpoint can also be sent to the setpoint and stored at the setpoint. Transmission of the access code to the setpoint can be transmitted through a wireless communication network, such as that used for the user, or a wired communication network of ADSL type.
  • the transmission of the access code to the user, and possibly to the setpoint, can be carried out by the central site or the central server.
  • step 122 the access code transmitted to the user can be stored in association with an identifier of the setpoint.
  • FIG. 2 is a representation of an example of a setpoint management phase 200 forming part of the method 100 shown in FIGURES 1-5.
  • the end of demand management phase 200 comprises a step 202 during which a time data item corresponding to the end of the depositing phase is stored. During this step 202, a timer is also triggered, for a predetermined duration, for example 24 hours.
  • an alert message is sent to the user, for example through a network wireless communication network such as the mobile phone network, for example to a smartphone of the user.
  • This alert message invites the user to remove the object within a predetermined period of time, for example 1 hour.
  • step 204 several options are possible.
  • the user can for example proceed to a withdrawal of the object during a withdrawal phase described with reference to FIG. 3. In this case, the end of the management phase 200 is terminated.
  • the user issues a request message: - an additional duration, for example 12 hours, this additional period then being paid;
  • a new timer for the additional duration is triggered during a step 208.
  • step 208 the user can proceed to a withdrawal of the object during a withdrawal phase described with reference to FIG. 3. In this case, the phase is terminated. end of order management system 200.
  • the process resumes at step 204, when the additional timer ends.
  • step 206 the user requests a transport of the object to another predetermined and imposed location
  • the object is removed from the setpoint by an operator to be transported to said location, during a step 210, using an access code or identification data.
  • the state data of the setpoint is changed to "free setpoint" during a step 212.
  • step 208 the removal of the object took place before the end of the timer in this case, it is terminated the end of management management phase.
  • FIGURE 3 is a representation of an example of a withdrawal phase 300 forming part of the process 100 shown in FIGURES 1-5.
  • the withdrawal phase 300 shown in FIG. 3 comprises a step 302 during which the user authenticates at the setpoint by entering the access code generated during step 122, possibly after having selected the setpoint, for example by entering an identification number of the deposit using an alphanumeric keypad.
  • the access code entered by the user is compared with the access code generated and sent to the user during step 122 of the phase of 102. This comparison can be made either at the setpoint or by the central server, as described above.
  • step 302 may be repeated, for example a limited number of times.
  • step 302 If in step 302 the authentication is successful, the setpoint is unlocked during a step 304, either by a local command or by a remote command issued for example by the central site.
  • the user removes the object from the setpoint during a step 306 and the setpoint is then locked, either automatically or manually by the user.
  • a signaling of the withdrawal of the object of said setpoint is carried out by sending a notification to the central site, either by the user or by the instruction, or both.
  • the state data of the setpoint is changed to "free setpoint" during a step 310.
  • the withdrawal phase 300 of the object can furthermore, before step 304 of unlocking, a step 312 of payment for the additional duration, by any means of payment, for example on a payment terminal at the deposit or any means of digital payment, for example NFC, Paypal, Apple Pay, etc.
  • FIGURE 4 is a representation of an example of a return phase 400 that may be part of the process 100 shown in FIGURES 1-5.
  • the return phase 400 shown in FIG. 4 comprises a step 402 which transmits, for example to the central site, return data of the object.
  • This data may include recipient identification data, and possibly recipient address data and / or object identification data and / or user identification data, etc.
  • the step of transmitting the return data can be performed at the setpoint or remote from the setpoint through a wired or wireless communication network.
  • an available setpoint is identified by consulting the setpoint database storing for each setpoint its location and its availability status.
  • step 404 is repeated at a later time, for example 1 hour later.
  • the setpoint is reserved during a step 406.
  • the setpoint status data is modified to "reserved setpoint", in the database, for example by the server central.
  • the return data is stored in association with the identifier of the setpoint.
  • an access code to the setpoint is generated and transmitted to the user, possibly with an identifier of the setpoint and an address of the setpoint.
  • the access code can be transmitted to the user via a wireless communication network, such as the mobile telephone network, on the smartphone or a portable device of the user connected to this wireless communication network.
  • An acknowledgment of receipt of the access code may be issued by the user.
  • the access code to the setpoint can also be sent to the reserved setpoint and stored at the reserved setpoint. Transmission of the access code to the setpoint can be transmitted through a wireless communication network, such as that used for the user, or a wired communication network of ADSL type.
  • the transmission of the access code to the user, and possibly to the setpoint, can be carried out by the central site or the central server.
  • the access code generated can be stored in association with an identifier of the setpoint.
  • the object is transported to the setpoint by the user.
  • the user authenticates at the setpoint by entering the access code, possibly after having selected the reserved instruction, for example using an alphanumeric keyboard.
  • the access code entered by the user is compared with the access code generated and sent to the user during step 408. This comparison can be performed either at the setpoint or by the central server.
  • an identifier of the object can also be entered by the user and compared to the identifier of the object stored in step 406.
  • step 412 may be repeated, for example a predetermined number of times.
  • step 412 If in step 412, the authentication is successful, the setpoint is unlocked during step 414, either by a local command or by a remote command issued for example by the central site.
  • step 416 the object is positioned in the setpoint and the reserved setpoint is locked.
  • a step 418 carries out a signaling of the deposit of the object in the deposit by sending a notification to the central site.
  • an access code to the setpoint containing the object is generated and transmitted to an operator for the removal of the object during a removal phase described later with reference to FIG. 5, possibly with an identifier of the setpoint.
  • the access code can be transmitted to the operator via a wireless communication network, such as the mobile telephone network, on the smartphone or a portable device of the operator connected to this wireless communication network. .
  • An acknowledgment of receipt of the access code may be issued by the operator.
  • the access code to the setpoint can also be sent to the setpoint and stored at the setpoint.
  • the transmission of the access code to the setpoint can be transmitted through a wireless communication network, such as that used for the operator, or a wired communication network of the ADSL type.
  • the transmission of the access code to the operator, and possibly to the setpoint, can be performed by the central site or the central server.
  • step 420 the access code transmitted to the operator can be stored in association with an identifier of the setpoint. Finally, the state data of the setpoint is modified to "setpoint to be released" during a step 422.
  • FIGURE 5 is a representation of an example of a removal phase 500 forming part of the process 100 shown in FIGURES 1-5.
  • the removal phase 500 shown in FIG. 5 comprises a step 502 during which the operator authenticates at the setpoint by entering the access code generated during step 420, possibly after having selected the setpoint for example by entering an identification number of the deposit using an alphanumeric keypad.
  • the access code entered by the operator is compared with the access code generated and sent to the operator during step 420 of the return phase 400. This comparison can be carried out either at level of the setpoint either by the central server, as described above.
  • step 502 may be repeated, for example a predetermined number of times.
  • step 502 If in step 502 the authentication is successful, the setpoint is unlocked during a step 504, either by a local command or by a remote command issued for example by the central site.
  • the operator removes the object from the setpoint during a step 506 and the setpoint is then locked, either automatically or manually by the operator, possibly after checking the state or the identifier of the object.
  • a signaling of the withdrawal of the object of said setpoint is carried out by sending a notification to the central site, either by the operator or by the instruction, or both.
  • the state data of the setpoint is changed to "free setpoint" during a step 510.
  • the unlocking of the setpoint by the operator, respectively by the user is performed by entering an access code during the phases 100, 200, 300, 400 and 500, and in particular during the steps 114, 210, 302, 412 and 502.
  • the unlocking of the setpoint by the operator, or by the user or by both is carried out by entering an identification data, for example by reading an identification data from an identification means at the setpoint such as an RFID card, NFC card, a card chip, a magnetic card, a biometric identification data, etc.
  • the steps relating to the generation, transmission and storage of an access code to the operator and / or to the user are not performed. These steps are replaced by an entry step, in particular of reading, of an identification data of the operator, and / or of the user, at the level of the instruction during the authentication step, and a comparison of this entered identification data with an identification data of the operator, respectively of the user, previously stored at the central site or at the setpoint.
  • FIGURE 6 is a representation of an example of a setpoint management system according to the invention.
  • the system 600 shown in FIG. 6 comprises, at a central management site 602, a central server 604, at least one setpoint database 606 in which are stored, for each instruction in association with a given data. identification of the setpoint, a state of the setpoint data and possibly:
  • the system 600 further comprises one or more modules 608 for calculating or implementing at least one of the steps described above, such as, for example, one or more timer counting modules for at least one setpoint, etc.
  • the system 600 further comprises at the central site 602 a communication module 610 through a wireless or wired 612 communication network.
  • the system 600 further includes one or more portable communication modules 614i-614 m, so-called operators carried by 616i-616 m operators, and can communicate with the central site through the communication network 612 to transmit and receive data or messages.
  • the system 600 also comprises one or more portable communication modules 618i-618 n , said to be users, carried by users 620i-620 n , and able to communicate with the central site through the communication network 612 to transmit and receive data. data or messages.
  • system 600 also comprises one or more management terminals 622i-622k, said setpoints disposed at each setpoint or a group of instructions.
  • Each management terminal 622 performs local management of one or more instructions and comprises means (not shown) for:
  • an identification means such as an optical reader, a magnetic reader, a biometric reader; - enter an access code or identification number of a deposit, such as a keypad;
  • FIGURE 7 is a representation of an example of an automated delivery facility according to the invention.
  • the plant 700 shown in FIGURE 7 includes all system elements 600 of FIGURE 6.
  • the installation also comprises several setpoints or groups of setpoints 702i-702k, each setpoint or group of setpoints being managed by a management terminal 622i-622k, so that each setpoint of each setpoint group can be locked / unlocked independently of other instructions.
  • the setpoints or groups of setpoints 702i-702k are dispersed in space and at a distance, one of the others, and at a distance from the central site 602.
  • at least two sets of setpoints comprise a set of same number or different number of instructions.
  • the instructions of a set group can be of identical or different dimensions.
  • the automated delivery installation according to the invention can be combined / integrated, at least in part, with an existing installation and in particular with a shared use installation, in the form of a rental , of electric vehicles.
  • at least one setpoint or group of instructions can be integrated into a parking station or removal of vehicles, thereby sharing an existing infrastructure.
  • At least one management terminal may be a terminal for managing a station, for taking or removing vehicles
  • At least one operator may be an operator or a user of the shared-use vehicle facility
  • At least one server or a database or a server or a means of communication of the installation according to the invention can be integrated, at least in part, in a central management site of said shared-use installation of vehicles.
  • FIGURE 8 is a schematic representation of a non-limiting example of a setpoint that may be used in the context of the present invention.
  • the setpoint 800 shown in FIG. 8, is integrated into an existing structure 802 on the road.
  • a structure 802 can be for example a bus shelter, an automated rental station for electric vehicles.
  • an instruction 800 can be backed by an existing terminal on the road, such as an automated rental terminal of electric vehicles, a terminal of purchase of travel documents, a billboard, etc.
  • the setpoint 800 can benefit from existing electrical connections at the existing structure 802, whether it is a connection to an electrical source and / or a connection to a communication network.
  • Setpoint 800 comprises a module 804, called master module, and three modules 8O61-8O63, called slave modules.
  • Each slave module 806 is in the form of an assembly, for example one-piece, independent of the master module 804 and the other slave modules 806.
  • the master module 804 is fixed on the ground inside the structure 802.
  • the first slave module 8O61 is fixed to the master module 804 by one of its side walls and the second slave module 8 ⁇ 62 is fixed to the first slave module 8O61 by a of its side walls also. Fixing a module to the other is removable and is made by screws for example.
  • the third slave module 8 ⁇ 63 is deported with respect to the assembly formed by the master module 804 and the first two slave modules 806i and 8 ⁇ 62.
  • the master module 804 comprises at least one locker, said master locker, and each slave module 806 each has several lockers, called slave lockers, provided to receive one or more objects to deliver. These bins are of identical or variable sizes.
  • Each slave locker has a door locked or unlocked by an electric lock equipping the slave locker.
  • Each slave rack further comprises a technical duct, leaned against a side wall of the slave rack, and allowing the passage of said rack to an adjacent rack of a wired electrical connection comprising:
  • an electrical cable for supplying the adjacent rack, in particular the electrical lock of the adjacent rack and / or means for displaying a code in the adjacent rack;
  • each slave locker is mounted on two hinges at 90 ° allowing maximum opening of said door.
  • the master module furthermore comprises slave lockers, a technical locker, said master locker, as indicated above, which is not intended to receive an object to deliver.
  • This master register provides a gateway between the slave bins (of the master module 804 and each slave module 806) and a power supply source and / or a communication network for communicating with a remote server.
  • the master locker comprises means for independently controlling the locking or unlocking of the electric lock of each slave locker.
  • the master locker has a door that can be locked or unlocked thanks to an electric lock fitted to the master locker.
  • the master box may comprise a support mounted sliding in the master box, using two slides, and provided to accommodate the technical management means of the deposit (not shown), namely: means for controlling the locking / unlocking of each slave locker of the setpoint 800,
  • the sliding mounted support makes it possible to extract the technical management means in case of intervention on these means.
  • the door of the master locker is mounted on two hinges at 90 ° allowing maximum opening of said door.
  • the master register may include, integrated into / on its door, a contactless reader, RFID or NFC type, and an infrared reader, provided for reading an identification data from a person identification card. , such as an operator or a user, authorized to access a locker and / or a piece of data of an object that will be deposited in a (or removed from) a slave locker.
  • the master cabinet can also include, integrated in / on its door, a touch screen forming a user interface and to perform various functions, namely:
  • a verification code for example a verification code generated on the fly
  • Each locker of an instruction implemented in the present invention for example the setpoint 800, designed to receive one or more objects can be used for a single user and a single object to be delivered to this user.
  • each bin can be used to receive multiple objects from the same source or different sources for a user. This alternative makes it possible to optimize the use of the deposit lockers.
  • each locker of the setpoint can be used to receive multiple objects from the same source or different sources and intended for multiple users, in the context of a bin share between different users.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Quality & Reliability (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un procédé (100) de gestion de consignes pour la livraison d'objets comprenant les étapes suivantes : • lors d'une phase (102) de dépose : - réception (104) de données de livraison d'un objet, - identification (106) d'au moins une consigne disponible par consultation d'une base de données (606), - authentification (114) d'un opérateur livrant ledit objet auprès de ladite consigne, et - dépôt (118) dudit objet dans ladite consigne par ledit opérateur; • lors d'une phase de retrait : - authentification d'un utilisateur destinataire dudit objet auprès de ladite consigne pour un déverrouillage de ladite consigne, - retrait dudit objet de ladite consigne par ledit utilisateur. Elle concerne également un système mettant en œuvre un tel procédé et une installation comprenant un tel système.

Description

« Procédé et système de gestion de consignes de livraison, et installation de livraison mettant en œuvre un tel procédé et/ou un tel système »
La présente invention concerne un procédé de gestion de consignes de livraison. Elle concerne également un système mettant en œuvre un tel procédé et une installation mettant en œuvre un tel procédé et/ou un tel système.
Le domaine de l'invention est le domaine de la gestion de consignes automatisées de livraison d'objets, et en particulier de colis.
Etat de la technique
Depuis une dizaine d'années, le commerce électronique est en forte progression et séduit de plus en plus d'acheteurs. De manière connue, l'acheteur commande un objet acheté sur Internet et l'objet acheté est livré à l'acheteur.
L'augmentation du nombre d'objet à livrer a poussé les acteurs de ce domaine à mettre au point de nouveaux systèmes de livraison mettant en œuvre des consignes de livraison automatisées. L'objet est déposé dans une consigne par un livreur. Puis, l'utilisateur/acheteur vient récupérer son objet dans la consigne. Un tel système de livraison mettant en œuvre des consignes automatisées est décrit dans le brevet français publié sous le numéro FR 2 975 273. Ces systèmes présentent l'avantage d'un taux de réussite de livraison supérieur comparés aux procédés de livraisons traditionnels tout en diminuant la main d'œuvre et les coûts associés à la livraison d'un objet. En effet, avec ces systèmes il n'est pas nécessaire de prévoir la présence d'une personne, à savoir l'utilisateur acheteur ou un intermédiaire, lors du passage du livreur pour réaliser la livraison.
Cependant, le système décrit dans le document FR 2 975 273 présente des inconvénients majeurs.
En effet, ce système ne garantit pas la livraison de l'objet, par exemple lorsqu'aucune consigne de livraison n'est disponible lors du passage du livreur. En outre, pour que le taux de réussite de livraison soit élevé, il est nécessaire de prévoir un grand nombre de consignes, ce qui augmente le coût du système et son encombrement.
De plus, la livraison d'objets avec ce système est peu rapide et peu ergonomique pour l'utilisateur. En effet, l'utilisateur doit se déplacer devant la consigne pour constater la présence ou non d'un objet qui lui a été livré.
Un but de la présente invention est de remédier aux inconvénients précités.
Un autre but de l'invention est de proposer un procédé et un système de gestion de consignes de livraison permettant de réaliser une livraison plus ergonomique et plus flexible pour l'utilisateur.
Un autre but de l'invention est de proposer un procédé et un système gestion de consignes de livraison permettant de diminuer les coûts et l'encombrement liés aux consignes de livraison.
Encore un autre but de l'invention est de proposer un procédé et un système de gestion de consignes de livraison permettant un taux de réussite de livraison plus grand. Exposé de l'invention
L'invention propose d'atteindre au moins l'un des buts précités par un procédé de gestion de consignes pour la livraison d'objets, en particulier de colis, ledit procédé comprenant les étapes suivantes :
• lors d'une phase, dite de dépose :
- réception, au niveau d'un site central, de données de livraison d'un objet, lesdites données comprenant des données relatives à une adresse de livraison,
- en fonction desdites données, identification d'au moins une consigne disponible pouvant accueillir ledit objet par consultation d'une base de données, dite de consignes,
- authentification d'un opérateur livrant ledit objet auprès de ladite consigne pour un déverrouillage de ladite consigne, et
- dépôt dudit objet dans ladite consigne par un opérateur ;
• lors d'une phase, dite de retrait : - authentification d'un utilisateur destinataire dudit objet auprès de ladite consigne pour un déverrouillage de ladite consigne,
- retrait dudit objet de ladite consigne par ledit utilisateur.
Le procédé selon l'invention permet de réaliser une livraison de colis dans des consignes, en déterminant préalablement la disponibilité d'une consigne pouvant accueillir l'objet avant de réaliser la livraison. Ainsi, le procédé de gestion de consignes selon l'invention permet d'éviter à un livreur de se déplacer avec l'objet s'il n'y a pas de consigne disponible pour accueillir l'objet lors de sa livraison. Le procédé selon l'invention permet ainsi un taux de livraison à 100%.
De plus, le procédé selon l'invention permet de réaliser une livraison plus flexible et plus ergonomique pour l'utilisateur car il permet d'éviter d'informer un utilisateur de la livraison de son objet lorsqu'aucune consigne n'est disponible pour accueillir l'objet. Ainsi, il est possible d'informer l'utilisateur, par exemple au travers d'un réseau de communication sans fil, une fois qu'une consigne disponible pouvant accueillir l'objet est identifiée. Avec le procédé selon l'invention, lorsque l'utilisateur est prévenu pour la livraison de son objet, il est garanti qu'une consigne sera disponible pour accueillir son objet et donc que la livraison sera réellement réalisée. Cela évite à l'utilisateur de se déplacer jusqu'à la consigne en croyant que son objet est livré, alors que le livreur n'a pas pu le livrer faute de consigne disponible.
En outre, le procédé de gestion de consignes selon l'invention permet de diminuer les coûts associés à une livraison en évitant un nouveau passage pour la livraison.
Par ailleurs, le procédé selon l'invention permet de prévoir sur chaque site un ensemble de consignes comprenant un nombre de consignes plus faible en adaptant les moments de livraison à la disponibilité des consignes, ce qui permet des consignes moins encombrantes et moins coûteuses.
Dans la présente invention, une consigne est un casier ou un ensemble de casiers, chaque casier étant muni d'une porte contrôlant l'accès audit casier et pouvant être verrouillée en position fermée. Le casier ou l'ensemble de casiers comporte en outre : - un moyen de lecture d'une donnée d'identification biométrique, et/ou un moyen de lecture d'une donnée d'identification depuis un moyen d'identification, et/ou un moyen d'entrée d'une donnée d'identification, tel qu'un clavier alphanumérique ;
- un moyen de verrouillage/déverrouillage de la porte d'accès à un casier de manière individuelle et indépendante des autres casiers ;
- éventuellement, un moyen de contrôle d'un tel moyen de verrouillage/déverrouillage ; et
- éventuellement un moyen de communication avec un site distant pour échanger des données avec ledit site distant au travers d'un réseau de communication filaire ou sans fil .
Avantageusement, l'étape d'identification d'une consigne disponible peut être réalisée en outre en fonction d'au moins une donnée relative à la nature, à une dimension et/ou à un poids de l'objet à livrer.
Par exemple, lorsque le transport et la livraison de l'objet nécessitent de respecter au moins une condition de température ou d'humidité spécifique, la consigne pour accueillir cet objet doit permettre de respecter cette dite condition.
Pour ce faire, la base de données de consignes peut comprendre pour au moins une, en particulier pour chaque, consigne des données relatives à la nature, à une dimension et/ou à un poids d'un ou des objets que ladite consigne peut accueillir.
Avantageusement, le procédé selon l'invention peut comprendre entre la phase de dépôt et la phase de retrait, une phase, dite de gestion de fin de consignes, comprenant les étapes suivantes réalisées pour chaque consigne :
- mémorisation d'une donnée horaire à la fin de la phase de dépôt en association avec une donnée d'identification de ladite consigne,
- déclenchement d'une minuterie à partir de ladite donnée horaire, - lorsque la minuterie atteint une durée prédéterminée et que la phase de retrait n'est pas réalisée, transmission vers l'utilisateur d'un message d'alerte depuis le site central.
Une telle phase de gestion de fin de consignes permet d'accélérer la libération des consignes, et de diminuer le temps d'occupation d'une consigne ou augmenter le nombre de consignes disponibles. En effet, lorsque l'utilisateur tarde à venir retirer son objet, il est alerté pour venir le retirer au plus vite et ainsi libérer la consigne pour une prochaine livraison par exemple.
Cette phase de gestion de fin de consigne permet de diminuer encore plus le nombre de consignes sur chaque site, et donc de diminuer le coût et l'encombrement présenté par les consignes. De plus, la phase de gestion de fin de consignes permet également de diminuer le temps moyen de livraison des objets.
Avantageusement, le procédé selon l'invention peut en outre comprendre suite à la transmission du message d'alerte, une transmission de l'utilisateur vers le site central d'un message de demande de :
■ prolongation de la minuterie pendant une durée additionnelle prédéterminée, ou
■ déplacement dudit objet depuis ladite consigne vers une autre localisation ;
lorsque ladite transmission dudit message de demande est réalisée pendant une durée additionnelle suite à ladite transmission dudit message d'alerte.
Ainsi, suite à l'alerte, l'utilisateur réalise le retrait de l'objet tel que décrit plus haut dans un laps de temps prédéterminé.
Toutes ces possibilités permettent une plus grande flexibilité et ergonomie pour l'utilisateur lors de la livraison d'un objet. Suite à la transmission, par l'utilisateur, du message de demande de prolongation de la durée de retrait ou de déplacement de l'objet, le procédé selon l'invention peut comprendre la phase de retrait de l'objet telle que décrite plus haut. Dans ce cas, ladite phase de retrait peut en outre comprendre une étape de paiement par l'utilisateur d'un montant après l'étape d'authentification.
Le montant peut être un montant fixe prédéterminé, ou déterminé en fonction de la durée additionnelle ou du déplacement de l'objet.
Avantageusement, le procédé selon l'invention peut en outre comprendre une phase, dite de retour, suite à la phase de retrait, ladite phase de retour comprenant les étapes suivantes :
- transmission vers le site central d'un message, dit de retour, comprenant une donnée d'identification du destinataire et éventuellement une donnée d'identification de l'objet et éventuellement une donnée d'identification de l'utilisateur,
- identification d'au moins une consigne disponible pouvant accueillir ledit objet par consultation d'une base de données, dite de consignes,
- authentification de l'utilisateur au niveau de ladite consigne,
- dépôt de l'objet dans ladite consigne par l'utilisateur.
Une telle phase de retour permet d'utiliser les consignes, non seulement pour la livraison d'objet vers l'utilisateur, mais également les livraisons d'objet depuis l'utilisateur vers un tiers dans le cadre d'un retour de livraison. Le procédé de gestion de consignes selon l'invention permet donc de proposer de nouvelles fonctionnalités aux utilisateurs.
Après la phase de retour, le procédé de gestion de consignes selon l'invention peut comprendre une phase, dite d'enlèvement de l'objet, par un opérateur, ladite phase d'enlèvement comprenant les étapes suivantes :
- authentification de l'opérateur au niveau de ladite consigne pour un déverrouillage de ladite consigne,
- enlèvement dudit objet de ladite consigne par ledit opérateur. Un tel enlèvement peut être réalisé par un opérateur qui se trouve sur le site où se trouve la consigne comprenant l'objet concerné par la phase de retour, pour réaliser une livraison d'autres objets ; ce qui permet de mutualiser le déplacement de l'opérateur et de diminuer le temps et le coût associé à la livraison ou au retour d'objets. Par exemple, l'opérateur peut se déplacer jusqu'à la consigne et retirer l'objet à enlever. La consigne est alors libre et peut être utilisée de suite pour la livraison d'un autre objet. Avantageusement, le procédé selon l'invention peut comprendre, pour chaque consigne, une modification d'une donnée d'état de ladite consigne mémorisée avec un identifiant de ladite consigne dans la base de données de consignes :
- après une étape d'identification d'une consigne, pour signaler que ladite consigne est « réservée » pour une livraison ; et/ou
- après une étape de dépôt pour signaler que ladite consigne est « occupée » ; et/ou
- après une étape de dépôt lors d'une phase de retour pour signaler que ladite consigne est « à libérer » ; et/ou
- après une étape de retrait, pour signaler que ladite consigne est « vide ».
La donnée d'état peut être modifiée en temps réel, en fonction de données communiquées par l'opérateur ou l'utilisateur.
Alternativement ou en plus, la donnée d'état peut être mise à jour en fonction de données communiquées par au moins un capteur de présence se trouvant au niveau de chaque consigne et pouvant signaler la présence et/ou l'absence d'un objet dans la consigne. Dans la présente demande, par consigne « disponible », on entend :
- une consigne vide, c'est-à-dire une consigne ne contenant aucun objet, ou
- une consigne « à libérer », comprenant un objet à retourner et pouvant être libérée par un opérateur au moment de la livraison d'un objet, ou encore
- une consigne comprenant déjà un objet mais pouvant contenir encore un autre objet dans le cadre d'un partage de consigne pour un même utilisateur ou pour plusieurs utilisateurs. Avantageusement, le procédé de gestion de consignes peut en outre comprendre une étape de signalisation :
- du dépôt de l'objet dans ladite consigne lors d'une phase de dépôt, et/ou
- du dépôt de l'objet dans ladite consigne lors d'une phase de retour, et/ou
- du retrait de l'objet de ladite consigne lors d'une phase de retrait, et/ou
- du prélèvement de l'objet de ladite consigne lors d'une phase d'enlèvement.
Au moins une de ces étapes de signalisation peut être réalisée par l'utilisateur et/ou par l'opérateur et/ou par la consigne concernée.
Au moins une de ces étapes de signalisation peut être réalisée au travers d'un réseau de communication sans fil, tel que le réseau de téléphonie mobile 3G, 4G, 5G, Wifi, Bluetooth, etc. Alternativement ou en plus, au moins une de ces étapes de signalisation peut être réalisée au travers d'un réseau de communication filaire, tel que le réseau ADSL, SDSL, etc. Au moins une donnée reçue lors d'au moins une de ces étapes de signalisation peut être utilisée pour mettre à jour ou modifier une donnée d'état liée à la consigne concernée.
Préférentiellement, au moins une étape d'authentification de l'opérateur peut comprendre une entrée par ledit opérateur, au niveau de ladite consigne d'un code d'accès ou d'une donnée d'identification dudit opérateur.
Le code d'accès ou la donnée d'identification peut être communiqué(e) à l'opérateur avant l'étape d'authentification de l'opérateur, au travers d'un réseau de communication sans fil, par exemple sur un Smartphone de l'opérateur.
Au moins un code d'accès peut être un code entré au travers d'un clavier prévu au niveau de la consigne, ou pour un groupe de consignes. La donnée d'identification peut être lue depuis un moyen d'identification, tel qu'une carte d'identification comportant un code barre ou un code QR ou alors une carte d'identification RFID, ou une carte NFC, ou encore une carte à puce.
Préférentiellement, le code d'accès ou la donnée d'identification utilisée pour l'étape d'authentification de l'opérateur :
- lors de la phase de dépose, peut être communiquée à l'opérateur, et/ou à la consigne, après l'étape d'identification de la consigne lors de la phase de dépose ; et/ou
- lors de la phase d'enlèvement, peut être communiquée à l'opérateur, et/ou à la consigne, après la phase de retour.
De plus, au moins une étape d'authentification de l'utilisateur peut comprendre une entrée, au niveau de ladite consigne, d'un code d'accès ou d'une donnée d'identification par ledit utilisateur.
Le code d'accès ou la donnée d'identification peut être communiqué(e) à l'utilisateur avant l'étape d'authentification de l'utilisateur, au travers d'un réseau de communication sans fil, par exemple sur un Smartphone de l'utilisateur.
Au moins un code d'accès peut être un code entré au travers d'un clavier prévu au niveau de la consigne, ou pour un groupe de consignes.
La donnée d'identification peut être lue depuis un moyen d'identification, tel qu'une carte d'identification comportant un code barre ou un code QR ou alors une carte d'identification RFID, ou une carte NFC, ou encore une carte à puce.
Préférentiellement, le code d'accès ou la donnée d'identification utilisée pour l'étape d'authentification de l'utilisateur :
- lors de la phase de retrait, peut être communiquée à l'utilisateur, et/ou à la consigne, après la phase de dépose ; et/ou - lors de la phase de retour, peut être communiquée à l'utilisateur, et/ou à la consigne, après l'étape d'identification de la consigne lors de la phase de retour. La vérification d'un code d'accès ou d'une donnée d'identification, lors d'une étape d'authentification, de l'utilisateur ou de l'opérateur, peut être réalisée de manière locale à la consigne. Dans ce cas, le procédé selon l'invention comprend, préalablement à l'étape d'authentification, une étape de transmission vers la consigne du code d'accès, ou de la donnée d'identification, ou encore d'un algorithme de vérification du code d'accès ou de la donnée d'identification, préalablement à l'étape d'authentification. Cette étape de transmission peut être réalisée au travers d'un réseau de communication filaire ou sans fil.
Alternativement, ou en plus, la vérification d'un code d'accès ou d'une donnée d'identification, lors d'une étape d'authentification, de l'utilisateur ou de l'opérateur, peut être réalisée sur un/le site central distant de la consigne. Dans ce cas, le procédé selon l'invention comprend, lors de l'étape d'authentification, une étape de transmission depuis la consigne vers le site central du code d'accès, ou de la donnée d'identification entrée par l'utilisateur, respectivement l'opérateur. Cette étape de transmission peut être réalisée au travers d'un réseau de communication filaire ou sans fil.
Selon l'invention une étape de dépôt de l'objet, et/ou une étape de retrait de l'objet, et/ou une étape d'enlèvement de l'objet peut comprendre une entrée d'une donnée d'identification de l'objet au niveau de la consigne.
La donnée d'identification de l'objet peut être entrée sur un clavier prévu à cet effet, ou lue par un lecteur de type optique ou magnétique.
En outre, la validation d'au moins une, préférentiellement de chacune, de ces étapes peut être conditionnée à une lecture de ladite donnée d'identification de l'objet, et éventuellement à une comparaison de la dite donnée d'identification à une donnée d'identification préalablement mémorisée dans la base de données de consignes, ou dans une base de données d'historiques des objets livrés, éventuellement en association avec un identifiant de ladite consigne.
Cette donnée d'identification de l'objet peut être comprise dans les données de livraison reçues lors de la phase de dépose et conservée tout au long du procédé. Avantageusement, le procédé selon l'invention peut être mis en œuvre pour la gestion de plusieurs consignes ou groupes de consignes distant les un(e)s des autres, préférentiellement depuis l'unique site central.
Le procédé selon l'invention peut en outre comprendre, avant l'étape d'identification d'une consigne disponible, une étape pour déterminer si au moins un autre objet peut être livré pour le même utilisateur ou pour la même adresse de livraison, par consultation d'une base de données, dite d'objets, mémorisant les données relatives aux objets à livrer, en fonction des données relatives.
Si au moins un autre objet est identifié, et éventuellement si l'opérateur accepte de livrer ledit au moins un autre objet, les objets peuvent être livrés par le même opérateur, et préférentiellement dans la même consigne.
Ainsi, le procédé selon l'invention permet de regrouper les livraisons d'objets pour un même utilisateur, dans une même consigne, ce qui permet de diminuer les coûts, la pollution, la main d'œuvre et l'infrastructure nécessaire à la livraison de ces objets.
Le procédé selon l'invention peut en outre comprendre, avant l'étape d'identification d'une consigne disponible, une étape d'identification d'au moins un autre objet dont la livraison est prévue pour le même utilisateur ou pour la même adresse de livraison, mais qui n'est pas encore disponible à la livraison.
Si oui, le procédé selon l'invention peut comprendre une étape, informant l'utilisateur de cette situation et proposant une livraison groupée.
Si l'utilisateur accepte, dans ce cas le procédé est arrêté jusqu'à la disponibilité à la livraison dudit autre objet et le procédé reprend lorsque ledit autre objet est disponible pour la livraison.
Ainsi, le procédé selon l'invention permet de regrouper les livraisons de plusieurs objets pour un même utilisateur ou pour une même adresse de livraison, ce qui permet de diminuer les coûts, la pollution, la main d'œuvre et l'infrastructure nécessaire à la livraison de ces objets. Le procédé selon l'invention peut en outre comprendre, avant l'étape d'identification d'une consigne disponible pour la livraison de l'objet, une étape d'identification d'au moins un autre objet à livrer au même utilisateur ou pour la même adresse de livraison par un autre opérateur.
Si au moins un autre objet est identifié plusieurs situations sont possibles.
Dans le cas où ledit autre objet est déjà livré ou en cours de livraison, cela veut dire qu'une consigne est déjà réservée pour cet autre objet. Dans ce cas, l'étape d'identification détermine si ladite consigne déjà réservée peut accueillir l'objet à livrer en plus dudit autre objet en fonction des données relatives à la taille et la nature des objets, à la compatibilité entre les objets, etc. :
- si oui, la consigne déjà réservée est sélectionnée pour la livraison de cet objet, éventuellement après confirmation auprès de l'utilisateur ;
- si non, une autre consigne est identifiée telle que décrit plus haut pour livrer cet objet.
Dans le cas où ledit autre objet n'est pas encore en cours de livraison, cela veut dire qu'aucune consigne n'est encore réservée pour cet autre objet. Dans ce cas, l'étape d'identification d'une consigne disponible est réalisée pour tous les objets :
- si une consigne, pouvant accueillir tous les objets est détectée, alors cette consigne est réservée pour tous les objets, éventuellement après confirmation auprès de l'utilisateur. Ensuite, l'identifiant de la consigne est communiqué aux opérateurs chargés de livrer cet objet et l'autre objet ;
- si non, une autre consigne est identifiée telle que décrit plus haut pour livrer cet objet.
Ainsi, le procédé selon l'invention permet de partager la même consigne, et en particulier le même casier, pour la livraison de plusieurs objets provenant de plusieurs sources différentes et livrés par plusieurs opérateurs différents. De cette manière, la disponibilité des consignes, i.e. des casiers de livraison, est optimisée. Selon un autre aspect de la même invention, il est proposé un système de gestion de consignes pour la livraison d'objets, en particulier de colis, comprenant :
- un serveur central, distant desdites consignes, connecté à chacune desdites consignes au travers d'un réseau de communication,
- une base de données de consignes mémorisant, pour chaque consigne, une donnée d'état de ladite consigne en association avec un identifiant de ladite consigne, et
- pour chacune desdites consignes, un moyen de communication de ladite consigne avec ledit serveur central ;
lesquels étant configurés pour mettre en œuvre toutes les étapes du procédé selon l'invention.
Selon encore un autre aspect de l'invention, il est proposé une installation comprenant :
- plusieurs consignes ou groupes de consignes, pour la livraison d'objets, chacune desdites consignes pouvant être verrouillée/déverrouillée indépendamment des autres consignes, et
- un système de gestion de consignes selon l'invention.
Description des figures et modes de réalisation
D'autres avantages et caractéristiques apparaîtront à l'examen de la description détaillée de modes de réalisation nullement limitatifs, et des dessins annexés sur lesquels :
- les FIGURES 1-5 sont une représentation schématique sous la forme d'un diagramme d'un exemple de réalisation non limitatif du procédé selon l'invention ;
- la FIGURE 6 est une représentation schématique d'un exemple de réalisation non limitatif d'un système selon l'invention ; - le FIGURE 7 est une représentation schématique d'un exemple de réalisation non limitatif d'une installation selon l'invention ; et
- la FIGURE 8 est une représentation schématique d'un exemple non limitatif d'une consigne pouvant être utilisée dans le cadre de la présente invention.
Il est bien entendu que les modes de réalisation qui seront décrits dans la suite ne sont nullement limitatifs. On pourra notamment imaginer des variantes de l'invention ne comprenant qu'une sélection de caractéristiques décrites par la suite, isolées des autres caractéristiques décrites, si cette sélection de caractéristiques est suffisante pour conférer un avantage technique ou pour différencier l'invention par rapport à de l'état de la technique antérieur. Cette sélection comprend au moins une caractéristique de préférence fonctionnelle sans détails structurels, ou avec seulement une partie des détails structurels si c'est cette partie qui est uniquement suffisante pour conférer un avantage technique ou pour différencier l'invention par rapport à l'état de la technique antérieur.
En particulier, toutes les variantes et modes de réalisation décrits sont combinables entre eux si rien ne s'oppose à cette combinaison sur le plan technique.
Sur les figures et dans la suite de la description, les éléments communs à plusieurs figures conservent la même référence.
Les FIGURES 1-5 donnent une représentation schématique sous la forme d'un diagramme d'un exemple de réalisation d'un procédé 100 de gestion de consignes selon l'invention.
La FIGURE 1 est une représentation d'un exemple d'une phase de dépose 102 du procédé 100 représenté sur les FIGURES 1-5.
En référence à la FIGURE 1, la phase de dépose comprend une étape
104 de réception de données de livraison d'un objet, par exemple au travers d'un réseau de communication sans fil ou filaire, par exemple le réseau Internet. Les données de livraison peuvent comprendre des données relatives à : - une identité de l'utilisateur à qui l'objet doit être livré,
- une adresse de l'utilisateur à qui l'objet doit être livré,
- un identifiant de l'objet à livrer,
- au moins une dimension, une nature, un format, un poids, une taille de l'objet à livrer, et/ou
- un délai de livraison de l'objet à livrer, etc.
Ces données de livraison peuvent être reçues par un site central, en particulier par un serveur central qui réalise la gestion des consignes.
Lors de cette étape, une demande d'abonnement peut être requise à l'utilisateur et une étape d'abonnement peut être réalisée, l'utilisateur fournissant les informations nécessaires pour son identification.
Lors d'une étape 106, en fonction des données de livraison, et en particulier en fonction des données relatives à l'adresse de l'utilisateur, une consigne disponible est identifiée en consultant une base de données de consignes mémorisant pour chaque consigne sa localisation et son état de disponibilité. Cette base de données peut être mémorisée au niveau du site central ou dans le serveur central.
Si aucune consigne disponible n'est identifiée, alors l'étape 106 est réitérée à un moment ultérieur, par exemple 1 heure plus tard.
Si une consigne disponible est identifiée, alors la consigne est réservée lors d'une étape 108. Pour ce faire, la donnée d'état de la consigne est modifiée en « consigne réservée », dans la base de données, par exemple par le serveur central. Lors de cette étape, les données relatives à l'objet sont mémorisées en association avec l'identifiant de la consigne.
Lors d'une étape 110, un code d'accès à la consigne est généré et émis vers l'opérateur qui doit livrer l'objet, éventuellement avec un identifiant de la consigne et une adresse de la consigne. Le code d'accès peut être transmis à l'opérateur au travers d'un réseau de communication sans fil, tel que le réseau de téléphonie mobile, sur le Smartphone ou un appareil portable de l'opérateur connecté à ce réseau de communication sans fil . Une confirmation de réception du code d'accès peut être émise par l'opérateur.
Le code d'accès à la consigne peut également être émis vers la consigne, et mémorisé au niveau de la consigne. La transmission du code d'accès vers la consigne peut être émis au travers d'un réseau de communication sans fil, tel que celui utilisé pour l'opérateur, ou un réseau de communication filaire de type ADSL.
L'émission du code d'accès vers l'opérateur, et éventuellement vers la consigne, peut être réalisée par le site central ou le serveur central .
Lors de l'étape 110, le code d'accès généré peut être mémorisé en association avec un identifiant de la consigne.
Lors d'une étape 112, l'objet est transporté jusqu'à la consigne, par exemple en utilisant un véhicule électrique.
Lors d'une étape 114, l'opérateur s'authentifie au niveau de la consigne en entrant le code d'accès, éventuellement après avoir sélectionné la consigne réservée, par exemple à l'aide d'un clavier alphanumérique. Lors de cette étape, le code d'accès entré par l'opérateur est comparé au code d'accès généré et émis vers l'opérateur lors de l'étape 110. Cette comparaison peut être réalisée soit au niveau de la consigne soit par le serveur central.
Lors de cette étape, un identifiant de l'objet peut également être entré par l'opérateur et comparé à l'identifiant de l'objet mémorisé lors de l'étape 108.
Si à l'étape 114 l'authentification n'est pas réussie, l'étape 114 peut être réitérée.
Si à l'étape 114 l'authentification est réussie, la consigne est déverrouillée lors de l'étape 116, soit par une commande locale soit par une commande distante émise par exemple par le site central .
Lors de l'étape 118, l'objet est positionné dans la consigne et la consigne est verrouillée.
Une étape 120 réalise une signalisation du dépôt de l'objet dans la consigne par émission d'une notification vers le site central .
Lors d'une étape 122, un code d'accès à la consigne contenant l'objet est généré et émis vers l'utilisateur, éventuellement avec un identifiant de la consigne. Le code d'accès peut être transmis à l'utilisateur au travers d'un réseau de communication sans fil, tel que le réseau de téléphonie mobile, sur le Smartphone ou un appareil portable de l'utilisateur connecté à ce réseau de communication sans fil . Une confirmation de réception du code d'accès peut être émise par l'utilisateur.
Le code d'accès à la consigne peut également être émis vers la consigne, et mémorisé au niveau de la consigne. La transmission du code d'accès vers la consigne peut être émise au travers d'un réseau de communication sans fil, tel que celui utilisé pour l'utilisateur, ou un réseau de communication filaire de type ADSL.
L'émission du code d'accès vers l'utilisateur, et éventuellement vers la consigne, peut être réalisée par le site central ou le serveur central .
Lors de l'étape 122, le code d'accès transmis à l'utilisateur peut être mémorisé en association avec un identifiant de la consigne.
Enfin, la donnée d'état de la consigne est modifiée en « consigne occupée » lors d'une étape 124. La FIGURE 2 est une représentation d'un exemple d'une phase 200 de gestion de fin de consigne faisant partie du procédé 100 représenté sur les FIGURES 1-5.
La phase 200 de gestion de fin de consigne comprend une étape 202 pendant laquelle une donnée horaire correspondant à la fin de la phase de dépose est mémorisée. Lors de cette étape 202, une minuterie est également déclenchée, pour une durée prédéterminée, par exemple 24 heures.
Lorsque l'objet n'est pas retiré de la consigne par l'utilisateur avant la fin de la minuterie, alors à l'étape 204, un message d'alerte est émis vers l'utilisateur, par exemple au travers d'un réseau de communication sans fil tel que le réseau de téléphonie mobile, par exemple à destination d'un Smartphone de l'utilisateur. Ce message d'alerte invite l'utilisateur à retirer l'objet dans un laps de temps prédéterminé, par exemple 1 heure.
Suite à l'étape 204, plusieurs options sont possibles. L'utilisateur peut par exemple procéder à un retrait de l'objet lors d'une phase de retrait décrite en référence à la FIGURE 3. Dans ce cas, il est mis fin à la phase de gestion de fin de consigne 200.
Selon une autre option, lors d'une étape 206, l'utilisateur émet un message de demande : - d'une durée additionnelle, par exemple de 12 heures, cette durée additionnelle étant alors payante ;
- d'un transport de l'objet vers une consigne se trouvant à une autre localisation pour qu'il puisse le retirer, ce transport étant également payant.
Si l'utilisateur demande une durée additionnelle, une nouvelle minuterie pour la durée additionnelle est déclenchée lors d'une étape 208.
Suite à l'étape 208, pendant la durée additionnelle, l'utilisateur peut procéder à un retrait de l'objet lors d'une phase de retrait décrite en référence à la FIGURE 3. Dans ce cas, il est mis fin à la phase de gestion de fin de consigne 200.
Si l'utilisateur ne retire pas l'objet de la consigne pendant la durée additionnelle, le procédé reprend à l'étape 204, lorsque la minuterie additionnelle prend fin.
Si à l'étape 206, l'utilisateur demande un transport de l'objet vers une autre localisation prédéterminée et imposée, l'objet est retiré de la consigne par un opérateur pour être transporté à ladite localisation, lors d'une étape 210, à l'aide d'un code d'accès ou d'une donnée d'identification.
La donnée d'état de la consigne est modifiée en « consigne libre », lors d'une étape 212.
Bien entendu, lorsqu'à l'étape 208, le retrait de l'objet a eu lieu avant la fin de la minuterie dans ce cas, il est mis fin à la phase de gestion de fin de consigne.
La FIGURE 3 est une représentation d'un exemple d'une phase de retrait 300 faisant partie du procédé 100 représenté sur les FIGURES 1-5.
La phase de retrait 300 représentée sur la FIGURE 3 comprend une étape 302 lors de laquelle l'utilisateur s'authentifie au niveau de la consigne en entrant le code d'accès généré lors de l'étape 122, éventuellement après avoir sélectionné la consigne, par exemple en entrant un numéro d'identification de la consigne à l'aide d'un clavier alphanumérique. Lors de cette étape 302, le code d'accès entré par l'utilisateur est comparé au code d'accès généré et émis vers l'utilisateur lors de l'étape 122 de la phase de dépose 102. Cette comparaison peut être réalisée, soit au niveau de la consigne, soit par le serveur central, tel que décrit plus haut.
Si à l'étape 302 l'authentification n'est pas réussie, l'étape 302 peut être réitérée, par exemple un nombre limité de fois.
Si à l'étape 302 l'authentification est réussie, la consigne est déverrouillée lors d'une étape 304, soit par une commande locale soit par une commande distante émise par exemple par le site central.
L'utilisateur retire l'objet de la consigne lors d'une étape 306 et la consigne est alors verrouillée, soit automatiquement soit manuellement par l'utilisateur.
Lors d'une étape 308, une signalisation du retrait de l'objet de ladite consigne est réalisée par émission d'une notification vers le site central, soit par l'utilisateur soit par la consigne, ou encore par les deux.
La donnée d'état de la consigne est modifiée en « consigne libre » lors d'une étape 310.
Lorsque la phase de retrait 300 de l'objet est réalisée suite à l'étape 208, c'est-à-dire lorsque l'utilisateur a bénéficié d'une durée additionnelle pour retirer l'objet, alors la phase de retrait 300 peut en outre comprendre, avant l'étape 304 de déverrouillage, une étape 312 de paiement pour la durée additionnelle, par un moyen de paiement quelconque, par exemple sur un terminal de paiement au niveau de la consigne ou tout moyen de paiement digital, par exemple du type NFC, Paypal, « Apple Pay », etc.
La FIGURE 4 est une représentation d'un exemple d'une phase de retour 400 pouvant faire partie du procédé 100 représenté sur les FIGURES 1-5.
La phase de retour 400 représentée sur la FIGURE 4 comprend une étape 402 qui transmet, par exemple vers le site central, des données de retour de l'objet. Ces données peuvent comprendre une donnée d'identification du destinataire, et éventuellement une donnée d'adresse du destinataire et/ou une donnée d'identification de l'objet et/ou une donnée d'identification de l'utilisateur, etc. De manière générale, l'étape de transmission des données de retour peut être réalisée au niveau de la consigne ou à distance de la consigne au travers d'un réseau de communication filaire ou sans fil .
Lors d'une étape 404, en fonction des données de retour, une consigne disponible est identifiée en consultant la base de données de consignes mémorisant pour chaque consigne sa localisation et son état de disponibilité.
Si aucune consigne disponible n'est identifiée, alors l'étape 404 est réitérée à un moment ultérieur, par exemple 1 heure plus tard.
Si une consigne disponible est identifiée, alors la consigne est réservée lors d'une étape 406. Pour ce faire, la donnée d'état de la consigne est modifiée en « consigne réservée », dans la base de données, par exemple par le serveur central. Lors de cette étape, les données de retour sont mémorisées en association avec l'identifiant de la consigne.
Lors d'une étape 408, un code d'accès à la consigne est généré et émise vers l'utilisateur, éventuellement avec un identifiant de la consigne et une adresse de la consigne. Le code d'accès peut être transmis à l'utilisateur au travers d'un réseau de communication sans fil, tel que le réseau de téléphonie mobile, sur le Smartphone ou un appareil portable de l'utilisateur connecté à ce réseau de communication sans fil . Une confirmation de réception du code d'accès peut être émise par l'utilisateur.
Le code d'accès à la consigne peut également être émis vers la consigne réservée, et mémorisée au niveau de la consigne réservée. La transmission du code d'accès vers la consigne peut être émise au travers d'un réseau de communication sans fil, tel que celui utilisé pour l'utilisateur, ou un réseau de communication filaire de type ADSL.
L'émission du code d'accès vers l'utilisateur, et éventuellement vers la consigne, peut être réalisée par le site central ou le serveur central .
Lors de l'étape 408, le code d'accès généré peut être mémorisé en association avec un identifiant de la consigne.
Lors d'une étape optionnelle 410, l'objet est transporté jusqu'à la consigne par l'utilisateur.
Lors d'une étape 412, l'utilisateur s'authentifie au niveau de la consigne en entrant le code d'accès, éventuellement après avoir sélectionné la consigne réservée, par exemple à l'aide d'un clavier alphanumérique. Lors de cette étape, le code d'accès entré par l'utilisateur est comparé au code d'accès généré et émis vers l'utilisateur lors de l'étape 408. Cette comparaison peut être réalisée soit au niveau de la consigne soit par le serveur central.
Lors de cette étape 412, un identifiant de l'objet peut également être entré par l'utilisateur et comparé à l'identifiant de l'objet mémorisé lors de l'étape 406.
Si à l'étape 412, l'authentification n'est pas réussie, l'étape 412 peut être réitérée, par exemple un nombre prédéterminé de fois.
Si à l'étape 412, l'authentification est réussie, la consigne est déverrouillée lors de l'étape 414, soit par une commande locale soit par une commande distante émise par exemple par le site central .
Lors de l'étape 416, l'objet est positionné dans la consigne et la consigne réservée est verrouillée.
Une étape 418 réalise une signalisation du dépôt de l'objet dans la consigne par émission d'une notification vers le site central .
Lors d'une étape 420, un code d'accès à la consigne contenant l'objet est généré et émis vers un opérateur pour l'enlèvement de l'objet lors d'une phase d'enlèvement décrite plus loin en référence à la FIGURE 5, éventuellement avec un identifiant de la consigne. Le code d'accès peut être transmis à l'opérateur au travers d'un réseau de communication sans fil, tel que le réseau de téléphonie mobile, sur le Smartphone ou un appareil portable de l'opérateur connecté à ce réseau de communication sans fil. Une confirmation de réception du code d'accès peut être émise par l'opérateur.
Le code d'accès à la consigne peut également être émis vers la consigne, et mémorisé au niveau de la consigne. La transmission du code d'accès vers la consigne peut être émis au travers d'un réseau de communication sans fil, tel que celui utilisé pour l'opérateur, ou un réseau de communication filaire de type ADSL.
L'émission du code d'accès vers l'opérateur, et éventuellement vers la consigne, peut être réalisée par le site central ou le serveur central .
Lors de l'étape 420, le code d'accès transmis à l'opérateur peut être mémorisé en association avec un identifiant de la consigne. Enfin, la donnée d'état de la consigne est modifiée en « consigne à libérer » lors d'une étape 422.
La FIGURE 5 est une représentation d'un exemple d'une phase d'enlèvement 500 faisant partie du procédé 100 représenté sur les FIGURES 1-5.
La phase d'enlèvement 500 représentée sur la FIGURE 5 comprend une étape 502 lors de laquelle l'opérateur s'authentifie au niveau de la consigne en entrant le code d'accès généré lors de l'étape 420, éventuellement après avoir sélectionné la consigne, par exemple en entrant un numéro d'identification de la consigne à l'aide d'un clavier alphanumérique. Lors de cette étape 502, le code d'accès entré par l'opérateur est comparé au code d'accès généré et émis vers l'opérateur lors de l'étape 420 de la phase de retour 400. Cette comparaison peut être réalisée soit au niveau de la consigne soit par le serveur central, tel que décrit plus haut.
Si à l'étape 502 l'authentification n'est pas réussie, l'étape 502 peut être réitérée, par exemple un nombre prédéterminé de fois.
Si à l'étape 502 l'authentification est réussie, la consigne est déverrouillée lors d'une étape 504, soit par une commande locale soit par une commande distante émise par exemple par le site central .
L'opérateur retire l'objet de la consigne lors d'une étape 506 et la consigne est alors verrouillée, soit automatiquement soit manuellement par l'opérateur, éventuellement après vérification de l'état ou de l'identifiant de l'objet.
Lors d'une étape 508, une signalisation du retrait de l'objet de ladite consigne est réalisée par émission d'une notification vers le site central, soit par l'opérateur soit par la consigne, ou encore par les deux.
La donnée d'état de la consigne est modifiée en « consigne libre » lors d'une étape 510.
L'objet enlevé est alors transporté par l'opérateur vers le destinataire renseigné par l'utilisateur lors de l'étape 402. Dans l'exemple donné en référence aux FIGURES 1-5, le déverrouillage de la consigne par l'opérateur, respectivement par l'utilisateur, est réalisé par entrée d'un code d'accès lors des phases 100, 200, 300, 400 et 500, et en particulier lors des étapes 114, 210, 302, 412 et 502. Alternativement, pour au moins une de ces phases, il est possible que le déverrouillage de la consigne par l'opérateur, ou par l'utilisateur ou encore par les deux, soit réalisé par entrée d'une donnée d'identification, par exemple par lecture d'une donnée d'identification depuis un moyen d'identification au niveau de la consigne tel qu'une carte RFID, carte NFC, une carte à puce, une carte magnétique, une donnée d'identification biométrique, etc. Dans ce cas, les étapes relatives à la génération, à la transmission et à la mémorisation d'un code d'accès vers l'opérateur, et/ou vers l'utilisateur, ne sont pas réalisées. Ces étapes sont remplacées par une étape d'entrée, en particulier de lecture, d'une donnée d'identification de l'opérateur, et/ou de l'utilisateur, au niveau de la consigne lors de l'étape d'authentification, et une comparaison de cette donnée d'identification entrée avec une donnée d'identification de l'opérateur, respectivement de l'utilisateur, préalablement mémorisée au niveau du site central ou au niveau de la consigne.
La FIGURE 6 est une représentation d'un exemple d'un système de gestion de consignes selon l'invention.
Le système 600 représenté sur la FIGURE 6 comprend, au niveau d'un site central 602 de gestion des consignes, un serveur central 604, au moins une base de données de consignes 606 dans laquelle sont mémorisées, pour chaque consigne en association avec une donnée d'identification de la consigne, une donnée d'état de la consigne et éventuellement :
- une donnée d'adresse de la consigne,
- une donnée d'identification d'un objet associé à la consigne,
- une donnée d'identification d'un utilisateur concerné par un objet à livrer dans cette consigne,
- des données relatives à une adresse de livraison ou de retour de l'objet, - un code d'accès à la consigne,
- une donnée d'identification d'un utilisateur ou d'un opérateur autorisé à accéder à la consigne,
- etc.
Le système 600 comprend en outre un ou plusieurs modules 608 de calcul ou de réalisation d'au moins une des étapes décrites plus haut, tel que par exemple un ou des modules de décompte d'une minuterie pour au moins une consigne, etc.
Le système 600 comprend en outre au niveau du site central 602 un module de communication 610 au travers d'un réseau de communication 612 sans fil ou filaire.
Le système 600 comprend en outre un ou plusieurs modules de communication portables 614i-614m, dits d'opérateurs, portés par des opérateurs 616i-616m, et pouvant communiquer avec le site central au travers du réseau de communication 612 pour émettre et recevoir des données ou des messages.
Le système 600 comprend également un ou plusieurs modules de communication portables 618i-618n, dits d'utilisateurs, portés par des utilisateurs 620i-620n, et pouvant communiquer avec le site central au travers du réseau de communication 612 pour émettre et recevoir des données ou des messages.
Par ailleurs, le système 600 comprend également une ou plusieurs bornes de gestion 622i-622k, dits de consignes, disposées au niveau de chaque consigne ou d'un groupe de consignes. Chaque borne de gestion 622 réalise la gestion locale d'une ou de plusieurs consignes et comprend des moyens (non représentés) pour :
- communiquer avec le site central 602 au travers du réseau de communication 612 pour émettre et recevoir des données ou des messages ;
- réaliser un verrouillage/déverrouillage de chaque consigne de manière indépendante ;
- lire une donnée d'identification depuis un moyen d'identification tel qu'un lecteur optique, un lecteur magnétique, un lecteur biométrique ; - entrer un code d'accès ou un numéro d'identification d'une consigne, tel qu'un clavier ;
- mémoriser au moins une donnée ;
- effectuer un paiement automatisé ;
- effectuer un affichage tel qu'un écran ;
- effectuer une signalisation sonore ;
- etc.
La FIGURE 7 est une représentation d'un exemple d'une installation de livraison automatisée selon l'invention.
L'installation 700 représentée sur la FIGURE 7 comprend tous les éléments du système 600 de la FIGURE 6.
L'installation comprend, en plus, plusieurs consignes ou groupes de consignes 702i-702k, chaque consigne ou groupe de consignes étant géré(e) par une borne de gestion 622i-622k, de sorte que chaque consigne de chaque groupe de consigne peut être verrouillée/déverrouillée de manière indépendante des autres consignes.
Les consignes ou groupes de consignes 702i-702k sont dispersé(e)s dans l'espace et à distance, les un(es) des autres, et à distance du site central 602. De plus, au moins deux groupes de consignes comportent un nombre identique ou un nombre différent de consignes. Les consignes d'un groupe de consigne peuvent être de dimensions identiques ou différentes. Suivant un exemple de réalisation particulièrement avantageuse, l'installation de livraison automatisée selon l'invention peut être combinée/intégrée, au moins en partie, à une installation existante et en particulier à une installation d'utilisation partagée, sous forme d'une location, de véhicules électriques. Dans ce cas, au moins une consigne ou groupe de consignes peut être intégré(e) dans une station de prise ou dépose de véhicules, permettant ainsi de partager une infrastructure existante.
De plus : - au moins une borne de gestion peut être une borne de gestion d'une station, de prise ou dépose de véhicules ;
- au moins un opérateur peut être un opérateur ou un utilisateur de l'installation d'utilisation partagée de véhicules ;
- au moins un serveur ou une base de données ou un serveur ou un moyen de communication de l'installation selon l'invention peut être intégré, au moins en partie sur un site de gestion centrale de ladite installation d'utilisation partagée de véhicules.
La FIGURE 8 est une représentation schématique d'un exemple non limitatif d'une consigne pouvant être utilisée dans le cadre de la présente invention.
La consigne 800, représentée sur la FIGURE 8, est intégrée dans une structure 802 existante sur la voirie. Une telle structure 802 peut être par exemple un abribus, une station de location automatisée de véhicules électriques. Alternativement, une telle consigne 800 peut être adossée à une borne existante sur la voirie, telle qu'une borne de location automatisée de véhicules électriques, une borne d'achat de titres de voyages, un panneau publicitaire, etc. De cette manière, la consigne 800 peut bénéficier de connexions électriques existantes au niveau de la structure 802 existante, que ce soit une connexion à une source électrique et/ou une connexion à un réseau de communication.
La consigne 800 comprend un module 804, dit module maître, et trois modules 8O61-8O63, dits modules esclaves. Chaque module esclave 806 se présente sous la forme d'un ensemble, par exemple monobloc, indépendant du module maître 804 et des autres modules esclaves 806.
Le module maître 804 est fixé sur le sol à l'intérieur de la structure 802. Le premier module esclave 8O61 est fixé au module maître 804 par une de ses parois latérales et le deuxième module esclave 8Ο62 est fixé au premier module esclave 8O61 par une de ses parois latérales également. La fixation d'un module à l'autre est démontable et est réalisée par des vis par exemple. Le troisième module esclave 8Ο63 est déporté par rapport à l'ensemble formé par le module maître 804 et les deux premiers modules esclaves 806i et 8Ο62.
Le module maître 804 comporte au moins un casier, dit casier maître, et chaque module esclave 806 comporte chacun plusieurs casiers, dits casiers esclaves, prévus pour recevoir un ou des objets à livrer. Ces casiers sont de tailles identiques ou variables.
Chaque casier esclave comporte une porte verrouillée ou déverrouillée grâce à une serrure électrique équipant le casier esclave. Chaque casier esclave comporte en outre un conduit technique, adossé sur une paroi latérale du casier esclave, et permettant le passage dudit casier vers un casier adjacent d'une connexion électrique filaire comprenant :
- un câble électrique d'alimentation du casier adjacent, notamment de la serrure électrique du casier adjacent et/ou d'un moyen d'affichage d'un code dans le casier adjacent ;
- un câble de communication avec le casier maître permettant audit casier maître de commander les composants du casier esclave, en particulier la serrure électrique du casier adjacent et/ou un moyen d'affichage d'un code dans le casier adjacent. La porte de chaque casier esclave est montée sur deux charnières à 90° permettant une ouverture maximale de ladite porte.
Le module maître, comprend en plus des casiers esclaves, un casier technique, dit casier maître, comme indiqué ci-dessus, qui n'est pas prévu pour recevoir un objet à livrer. Ce casier maître réalise une passerelle entre les casiers esclaves (du module maître 804 et de chaque module esclave 806) et une source d'alimentation électrique et/ou un réseau de communication pour communiquer avec un serveur distant. De plus, le casier maître comprend des moyens pour commander indépendamment le verrouillage ou le déverrouillage de la serrure électrique de chaque casier esclave.
Le casier maître comporte une porte qui peut être verrouillée ou déverrouillée grâce à une serrure électrique équipant le casier maître.
Le casier maître peut comprendre un support monté coulissant dans le casier maître, à l'aide de deux glissières, et prévu pour accueillir les moyens de gestion technique de la consigne (non représentés), à savoir : - des moyens de commande du verrouillage/déverrouillage de chaque casier esclave de la consigne 800,
- des moyens de communication avec un serveur distant au travers d'un réseau de communication,
- des moyens d'alimentation de chaque casier de la consigne
800, et
- des moyens de traitement de données.
Ces moyens de gestion technique peuvent se présenter sous la forme d'un ordinateur intégrant les moyens listés ci-dessus.
Le support monté coulissant permet d'extraire les moyens de gestion technique en cas d'intervention sur ces moyens.
La porte du casier maître est montée sur deux charnières à 90° permettant une ouverture maximale de ladite porte.
En outre, le casier maître peut comprendre, intégrés dans/sur sa porte, un lecteur sans contact, de type RFID ou NFC, et un lecteur infrarouge, prévus pour lire une donnée d'identification depuis une carte d'identification d'une personne, tel qu'un opérateur ou un utilisateur, autorisée à accéder à un casier et/ou une donnée d'un objet qui va être déposé dans un (ou retiré d'un) casier esclave.
Le casier maître peut également comprendre, intégré dans/sur sa porte, un écran tactile formant une interface utilisateur et permettant de réaliser différentes fonctions, à savoir :
sélectionner, par son numéro, un casier esclave ; et/ou entrer manuellement une donnée d'identification d'un objet ne possédant pas de support d'identification sans contact ; et/ou
entrer manuellement une donnée d'identification d'une personne ne possédant pas de support d'identification sans contact ; et/ou
- entrer un code de vérification, par exemple un code de vérification généré à la volée ;
etc. Chaque casier d'une consigne mise en œuvre dans la présente invention, par exemple la consigne 800, prévu pour recevoir un ou plusieurs objets peut être utilisé pour un utilisateur unique et un objet unique à livrer à cet utilisateur.
Alternativement, chaque casier peut être utilisé pour recevoir plusieurs objets provenant de la même source ou de sources différentes et destinés à un utilisateur. Cette alternative permet d'optimiser l'utilisation des casiers de la consigne.
Selon encore une autre alternative permettant d'optimiser encore plus l'utilisation de la consigne, chaque casier de la consigne peut être utilisé pour recevoir plusieurs objets provenant de la même source ou de sources différentes et destinés à plusieurs utilisateurs, dans le cadre d'un partage de casier entre différents utilisateurs.
Bien entendu, l'invention n'est pas limitée aux exemples qui viennent d'être décrits.

Claims

REVENDICATIONS
1. Procédé ( 100) de gestion de consignes pour la livraison d'objets, en particulier de colis, ledit procédé comprenant les étapes suivantes :
• lors d'une phase ( 102), dite de dépose :
- réception ( 104), au niveau d'un site central (602), de données de livraison d'un objet, lesdites données comprenant des données relatives à une adresse de livraison,
- en fonction desdites données, identification ( 106) d'au moins une consigne disponible pouvant accueillir ledit objet par consultation d'une base de données (606), dite de consignes,
- authentification ( 114) d'un opérateur livrant ledit objet auprès de ladite consigne pour un déverrouillage de ladite consigne, et - dépôt ( 118) dudit objet dans ladite consigne par ledit opérateur ;
• lors d'une phase (300), dite de retrait :
- authentification (302) d'un utilisateur destinataire dudit objet auprès de ladite consigne pour un déverrouillage de ladite consigne,
- retrait (306) dudit objet de ladite consigne par ledit utilisateur ; caractérisé en ce qu'au moins une étape d'authentification est réalisée avec un code d'accès communiqué audit opérateur, respectivement audit utilisateur, au travers d'un réseau de communication sans fil, avant ladite étape d'authentification .
2. Procédé ( 100) selon la revendication précédente, caractérisé en ce qu'il comprend, entre la phase de dépôt ( 100) et la phase de retrait (300), une phase (200), dite de gestion de fin de consignes, comprenant les étapes suivantes réalisées pour chaque consigne :
mémorisation (202) d'une donnée horaire à la fin de ladite phase de dépôt ( 100) en association avec une donnée d'identification de ladite consigne, déclenchement (202) d'une minuterie à partir de ladite donnée horaire,
lorsque la minuterie atteint une durée prédéterminée et que la phase de retrait n'est pas réalisée, transmission (204) vers l'utilisateur d'un message d'alerte depuis le site central (602).
3. Procédé (100) selon la revendication précédente, caractérisé en ce qu'il comprend, suite à la transmission (204) du message d'alerte, une transmission (206) de l'utilisateur vers le site central (602) d'un message de demande de :
- prolongation de la minuterie pendant une durée additionnelle, ou
- déplacement dudit objet depuis ladite consigne vers une autre localisation ;
lorsque ladite transmission (206) dudit message de demande est réalisée pendant une durée prédéterminée suite à ladite transmission (24) dudit message d'alerte.
4. Procédé (100) selon la revendication précédente, caractérisé en ce que, lorsque la phase de retrait (300) est réalisée après la transmission du message de demande, ladite phase de retrait (300) comprend en outre à une étape (312) de paiement d'un montant par l'utilisateur après l'étape d'authentification (302).
5. Procédé (100) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend une phase (400), dite de retour, suite à la phase de retrait (300), ladite phase de retour (400) comprenant les étapes suivantes :
- transmission (402) vers le site central (602), d'un message, dit de retour, comprenant une donnée d'identification du destinataire et éventuellement une donnée d'identification de l'objet et éventuellement une donnée d'identification de l'utilisateur, - identification (404) d'au moins une consigne disponible pouvant accueillir ledit objet par consultation d'une base de données (606), dite de consignes,
- authentification (412) de l'utilisateur au niveau de ladite consigne,
- dépôt (416) de l'objet dans ladite consigne par l'utilisateur.
6. Procédé (100) selon la revendication précédente, caractérisé en ce qu'il comprend en outre, après la phase de retour (400), une phase (500), dite d'enlèvement de l'objet, par un opérateur, ladite phase d'enlèvement (500) comprenant les étapes suivantes :
- authentification (502) de l'opérateur au niveau de ladite consigne pour un déverrouillage de ladite consigne,
- enlèvement (506) dudit objet de ladite consigne par ledit opérateur.
7. Procédé (100) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend, pour chaque consigne, une modification (108, 124, 212, 310, 406, 422, 510) d'une donnée d'état de ladite consigne mémorisée avec un identifiant de ladite consigne dans la base de données de consignes (606) :
- après une étape (106, 404) d'identification d'une consigne, pour signaler que ladite consigne est réservée pour une livraison, et/ou
- après une étape de dépôt (118, 416), pour signaler que ladite consigne est occupée, et/ou
- après une étape de retrait (210, 306, 508) et/ou une phase d'enlèvement, pour signaler que ladite consigne est disponible.
8. Procédé (100) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins une étape d'authentification (114, 502) de l'opérateur comprend une entrée par ledit opérateur, au niveau de ladite consigne d'un code d'accès dudit opérateur.
9. Procédé (100) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins une étape (302, 412) d'authentification de l'utilisateur comprend une entrée, au niveau de ladite consigne, d'un code d'accès par ledit utilisateur.
10. Procédé (100) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins une étape (118, 416) de dépôt de l'objet, et/ou au moins une étape (306) de retrait de l'objet, et/ou au moins une étape d'enlèvement (506) de l'objet comprend une entrée d'une donnée d'identification de l'objet au niveau de la consigne.
11. Procédé (100) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend une étape (120, 210, 308, 418, 508) de signalisation :
- du dépôt (118) de l'objet dans ladite consigne lors d'une phase de dépôt (100), et/ou
- du dépôt (418) de l'objet dans ladite consigne lors d'une phase de retour (400), et/ou
- du retrait (306) de l'objet de ladite consigne lors d'une phase de retrait (300), et/ou
- du prélèvement (506) de l'objet de ladite consigne lors d'une phase (500) d'enlèvement.
12. Procédé (100) selon l'une quelconque des revendications précédentes, mis en œuvre pour la gestion de plusieurs consignes ou groupes de consignes distant(e)s les un(e)s des autres.
13. Système (600) de gestion de consignes pour la livraison d'objets, en particulier de colis, comprenant :
- un serveur central (604), distant desdites consignes, connecté à chacune desdites consignes au travers d'un réseau de communication (612), - une base de données de consignes (606) mémorisant, pour chaque consigne, une donnée d'état de ladite consigne en association avec un identifiant de ladite consigne, et
- pour chacune desdites consignes, un moyen de communication (622i-622k) de ladite consigne avec ledit serveur central (602) ;
lesquels étant configurés pour mettre en œuvre toutes les étapes du procédé selon l'une quelconque des revendications précédentes.
14. Installation (700) comprenant :
- plusieurs consignes ou groupes de consignes (702i-702k), pour la livraison d'objets, chacune desdites consignes pouvant être verrouillée/déverrouillée indépendamment des autres consignes, et
- un système (600) de gestion de consignes selon la revendication précédente.
PCT/EP2015/076557 2014-11-27 2015-11-13 Procede et systeme de gestion de consignes de livraison, et installation de livraison mettant en oeuvre un tel procede et/ou un tel systeme WO2016083161A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1461610A FR3029329B1 (fr) 2014-11-27 2014-11-27 Procede et systeme de gestion de consignes de livraison, et installation de livraison mettant en oeuvre un tel procede et/ou un tel systeme
FR1461610 2014-11-27

Publications (1)

Publication Number Publication Date
WO2016083161A1 true WO2016083161A1 (fr) 2016-06-02

Family

ID=52988153

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/076557 WO2016083161A1 (fr) 2014-11-27 2015-11-13 Procede et systeme de gestion de consignes de livraison, et installation de livraison mettant en oeuvre un tel procede et/ou un tel systeme

Country Status (2)

Country Link
FR (1) FR3029329B1 (fr)
WO (1) WO2016083161A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002023426A1 (fr) * 2000-09-13 2002-03-21 First Cube Pte Ltd. Procede et systeme mettant en oeuvre la notification par service de message court (sms) pour faciliter la distribution de marchandises
US20100004960A1 (en) * 2006-11-13 2010-01-07 Deutsche Post Ag Method and arrangement of devices for operating an electronic parcel postbox
FR2975273A1 (fr) 2011-05-19 2012-11-23 Decayeux Ets Dispositif de casiers de reception de colis et procedes de livraison et de reception d'un colis

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002023426A1 (fr) * 2000-09-13 2002-03-21 First Cube Pte Ltd. Procede et systeme mettant en oeuvre la notification par service de message court (sms) pour faciliter la distribution de marchandises
US20100004960A1 (en) * 2006-11-13 2010-01-07 Deutsche Post Ag Method and arrangement of devices for operating an electronic parcel postbox
FR2975273A1 (fr) 2011-05-19 2012-11-23 Decayeux Ets Dispositif de casiers de reception de colis et procedes de livraison et de reception d'un colis

Also Published As

Publication number Publication date
FR3029329B1 (fr) 2018-07-13
FR3029329A1 (fr) 2016-06-03

Similar Documents

Publication Publication Date Title
EP1330805A1 (fr) Procede et dispositif de reservation d'une place de stationnement
EP3211575B1 (fr) Procédé de gestion d'acheminement de colis, et système informatique de gestion et conteneurs associés
JP6738143B2 (ja) ロッカーシステム
EP1709598A2 (fr) Dispositif transactionnel a pre-traitement anticipe
EP3752990A1 (fr) Dispositif de stockage d'objets, et procédé mettant en oeuvre un tel dispositif
EP3472794B1 (fr) System de mise a disposition de véhicules partages amarres a des stations, et dispositifs associes
FR2915606A1 (fr) Procede et systeme de controle d'acces a un evenement ou a un service
FR3078192A1 (fr) Dispositif de stockage d'objets, et procede mettant en oeuvre un tel dispositif
WO2016083161A1 (fr) Procede et systeme de gestion de consignes de livraison, et installation de livraison mettant en oeuvre un tel procede et/ou un tel systeme
WO2016083101A1 (fr) Procede et systeme de gestion de consignes de livraison, et installation de livraison mettant en oeuvre un tel procede et/ou un tel systeme
EP1578055A1 (fr) Procédé de consultation sécurisée de récépissés de livraison d'objets
WO2016083160A1 (fr) Procede, systeme et installation de depot et/ou de retrait automatise(s) d'objets
EP3369067A1 (fr) Procédé de traitement de données sur borne multimédia de paiement, dispositifs et programmes d'ordinateur correspondants
EP1163646B1 (fr) Systeme et procede de gestion de transaction dans un site mobile, et equipements mis en oeuvre dans ce systeme
EP3220327B1 (fr) Sytème d'acheminement d'objets par des individus d'une communauté, mettant en oeuvre un système de traçabilité spatiotemporelle
FR2932296A1 (fr) Procedes et dispositif pour entites electroniques pour l'echange et l'utilisation de droits
EP4254286B1 (fr) Système d'acheminement d'objets contenus dans des boîtes sur lesquelles sont prévus des moyens d'identification du destinataire
WO2016083158A1 (fr) Procédé et système de livraison d'un objet, installation mettant en œuvre un tel procédé et/ou un tel système
WO2018229089A1 (fr) Procédé de gestion d'identifiants de fidélité, procédé de traitement de données de fidélité, serveur, dispositif de transaction et programmes correspondants
WO2023094744A1 (fr) Procédé d'établissement d'une transaction entre un objet communicant et un module de controle de la transaction associé à un dispositif de fourniture de bien(s) ou de service(s)
FR2985347A1 (fr) Procede et systeme d'enregistrement d'au moins un bagage.
IL284932A (en) Systems, devices and methods for dispensing and collecting an item, which are controlled remotely
FR3089670A1 (fr) Dispositif de stockage d’objets, et procédé mettant en œuvre un tel dispositif
FR3081305A1 (fr) Boite a colis mutualisee pour systeme collectif de distribution de courrier et systeme integrant une telle boite
FR3090955A1 (fr) Procédé de gestion d’un système de commerce électronique comprenant des étapes de commandes en ligne

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15801704

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15801704

Country of ref document: EP

Kind code of ref document: A1