Reducing energy consumption for providing services to recipients at postal addresses

Abstract

A recipient of a service, such as a package pickup, regularly carries a mobile device. The recipient has installed an app on the mobile device (1110) that is linked to a delivery agent (1105) and a time prediction system (1115). An identification code is assigned to the mobile device (1110). The app periodically transmits its location along with the identification code to the time prediction system (1115). When the delivery agent (1105) receives an order to deliver a package to a recipient, the delivery agent (1105) sends a request (1130) to the time prediction system (1115) requesting the recipient's predicted core presence time at the delivery address. The time prediction system (1115) transmits the predicted core presence time of the recipient at the delivery address to the delivery agent (1105). With the help of the predicted core time, the delivery agent (1105) can schedule a delivery (1140) to the recipient.

Description

[Technical Field]

[0001] The present invention relates to determining the core presence time of at least one recipient of a service at a postal address. The present invention also relates to a data processing system comprising means for performing the above-mentioned method, as well as a computer program product and a computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to perform the above-mentioned method. [Background technology]

[0002] Various methods are known to predict the presence or absence of a person at a specific location during a specific time frame, the results of which can be communicated to the terminals of the courier company to optimize the delivery time of goods or to avoid unnecessary visits that would be economically and environmentally damaging.

[0003] For example, predictions can be made based on data representing the amount of electricity consumed in a given location (e.g., home, workplace, etc.). However, this approach lacks functionality and reliability. In fact, a quarter of the surveyed homes had to be excluded from the study because their energy consumption did not change enough to create a profile according to the results of a dedicated survey. Energy use does not necessarily reflect the consumer's activity or presence; automated appliances, running washing machines, or heaters operated by thermostats can distort the results. Participants had to fill out an extensive questionnaire about their personal lives, and conclusions had to be drawn by energy experts. Furthermore, obtaining consumer energy use data is not easy and is not real-time unless the consumer has a smart home. Consumers are not accustomed to sharing energy data. Despite the innovative research approach, these issues hinder practical application. Furthermore, the study did not use data protection or security technologies.

[0004] Another approach utilizes data shared by users when visiting specific locations to determine popular times and visit durations. In particular, it is possible to determine how active a location is at a particular moment compared to its usual activity level. Furthermore, it is possible to determine how much time a user typically spends at a location by extrapolating based on the user's visit patterns over the past few weeks. This approach generates results for public places or stores. The user's exact location is collected and stored, which can be obtained if a hacker gains access to the data. In other words, confidential information such as which streets the user walked, which stores they visited, where they live, and the user's habits and preferences can be used fraudulently.

[0005] According to another approach, a user's location is predicted based on mobile location data. In the first step, the user's points of interest are identified using density-based clustering. Next, the thematic location of the user's points of interest (home or work) is discovered based on a temporal assumption. Finally, future locations are predicted using a decision tree model trained on each user's historical location data. This approach only creates a weekly schedule and does not provide further updates or optimizations, for example, during deliveries. Furthermore, this approach does not measure the user's distance to the delivery address or remove time windows from the schedule if the delivery cannot be made on time. Apart from the user's authorization for their location within the respective app, no privacy or security techniques, such as encryption or verification mechanisms, are used in this approach, and data processing is linked to actual map data (location longitude and latitude). Summary of the Invention [Problem to be solved by the invention]

[0006] It is therefore an object of the present invention to address or at least mitigate some of the above problems and reduce energy consumption for the provision of services to recipients. [Means for solving the problem]

[0007] This object is achieved by the invention as defined in the independent claims. Advantageous embodiments are defined in the dependent claims.

[0008] The object of the present invention is achieved by a method. In the following, the individual steps of the method are described in more detail. The steps do not necessarily have to be performed in the order given in the text. Furthermore, further steps not explicitly mentioned may also be part of the method.

[0009] The inventors propose a method to reduce energy consumption for delivering services to service recipients at their postal address or geographic location.

[0010] Typically, the recipient is a natural person, however, it is also conceivable that the recipient is a robot or machine that needs to be replenished and / or replaced with spare parts.

[0011] A postal address is usually the home address or place of work of a natural person. It can consist of typical information such as state, city, zip code, street with house number, etc. For high-rise buildings, it can also include floor number, suite number or room number. However, in remote areas where there is no postal address, for example, a geographic location given in geographic coordinates of some reference system can also be useful to indicate where the service should be delivered.

[0012] In its most practical case, a service is the delivery of a parcel or an item. However, it can also be the service of a craftsman, mechanic, nurse, etc. Generally speaking, a service is an action that requires the presence of at least two people at a postal address or geographical location. In an even more generalized way, a service can be delivered by a robot or drone, thus requiring only the robot or drone and the recipient, a natural person or machine, to be simultaneously present at the postal address or geographical location.

[0013] The method requires several steps: The recipient's mobile device transmits at least an identification code corresponding to the recipient and data representing the location of the mobile device at regular time intervals to the time prediction system.

[0014] Typically, a mobile device has an activated location sensor. The activated location sensor is usually a built-in GPS sensor. However, any other means for determining the location of the mobile device may be used. For example, the location of the mobile device can be determined by triangulation with different base stations of a mobile network. Similarly, the mobile device can determine its location using Wi-Fi or Bluetooth.

[0015] Typically, an application runs on the recipient's mobile device that has the authority to transmit these data to the time prediction system. It does so once it is installed on the recipient's mobile device. This occurs at regular intervals, for example, every 15 minutes, every minute, etc. Alternatively, updates can be sent more regularly if the mobile device is moving, or less frequently if the mobile device is stationary.

[0016] The time prediction system receives and stores data representing the location, along with the recipient's identification code and a timestamp.

[0017] An entity receives an order to deliver a service to a recipient at a postal address or geographic location. This entity may be the routing system of a delivery service, as well as the person delivering the package. It may also be the scheduling system of a childcare service, an online shop, etc.

[0018] The order contains at least a postal address or geographic location and data identifying the recipient, which may for example be the recipient's name or online shop customer number.

[0019] The entity further receives the recipient's identification code or calculates the recipient's identification code based on information about the recipient. This identification code may be generated by an app on the recipient's mobile device or by a delivery service or routing system and then sent to the app on the recipient's mobile device. The identification code may also be generated by an online shop where the recipient purchased a particular product. If a specific algorithm is used to calculate the identification code, different players, such as entities, may also calculate the identification code based on information about the recipient they possess.

[0020] After receiving the service order, the entity may send a request to the time prediction system to provide the entity with a predicted core presence time of the recipient at the geographic location of the mailing address. The request may include at least the mailing address or geographic location and an identification code corresponding to the recipient. It may further include the earliest date and time feasible for the entity to provide service to the recipient at the mailing address or geographic location.

[0021] After receiving the request, the time prediction system provides the entity with the predicted core presence time for the requested recipient, thereby enabling the entity to deliver the service to the recipient at the postal address or geographic location at the recipient's predicted core presence time at the postal address. Typically, the time prediction system returns predicted core presence times for the next few days, e.g., the next 2-7 days, preferably the next 2-5 days, and most preferably the next 2-3 days. For example, in a parcel delivery use case, these predictions can be further limited to preferred times for accepting shipments, such as Monday through Saturday, 8:00-21:00.

[0022] If the request includes the earliest date and time feasible for the entity to service the recipient at the postal address or geographic location, the provided predicted core time may start from this earliest date and time. Otherwise, the provided predicted core time begins, for example, from the moment of receipt of the request.

[0023] This approach not only significantly prevents unnecessary delivery visits, but also saves up to 45% of the average time and energy spent on a delivery visit.

[0024] By increasing the probability that the delivery agent and the recipient will meet each other at the postal address or geographic location, the proposed method also largely avoids customers having to wait in vain for service delivery, a situation that has been shown from experience to cause significant customer dissatisfaction.

[0025] Focusing only on the time prediction system, the proposed method is expressed from the perspective of the time prediction system as follows: The method for calculating the predicted core presence time of a recipient of a service at a postal address or geographic location includes the following steps from the perspective of the time prediction system:

[0026] The time prediction system receives data from the recipient's mobile device at regular time intervals that represent at least an identification code corresponding to the recipient and a location of the mobile device.

[0027] The time prediction system stores data representing the location along with the recipient's identification code and a timestamp.

[0028] When delivery of a service is requested from an entity, the time prediction system receives a request from the entity providing a predicted core presence time of the recipient at a postal address or geographic location.

[0029] The request includes at least a postal address or geographic location and a recipient's identification code. It may further include the earliest time and date feasible for the entity to service the recipient at the postal address or geographic location.

[0030] After receiving the request, the time prediction system provides the entity with the requested predicted core presence time, thereby enabling the entity to deliver the service to the recipient at the mailing address at the recipient's predicted core presence time at the mailing address.

[0031] To this end, the invention requires a time prediction system comprising means for carrying out the above-mentioned method.

[0032] Furthermore, the object of the present invention can be achieved by a computer program comprising instructions that cause a computer to carry out the above-mentioned method when the program is executed by a computer.

[0033] To this end, computer readable media may be offered on the market having stored thereon a computer program according to the immediately preceding claims.

[0034] Correspondingly, the present invention requires a computer program for a mobile device of a recipient of a service, the program transmitting at regular time intervals at least an identification code corresponding to the recipient and location data of the mobile device to a time prediction system which executes a method executed by the time prediction system.

[0035] From the perspective of an entity involved in the delivery of a service to a recipient at a postal address or geographic location, the proposed method includes the step of the entity receiving an order to deliver a service to a recipient at a postal address, the order including at least the postal address or geographic location and the name of the recipient.

[0036] The entity further receives the recipient's identification code or calculates the recipient's identification code based on information about the recipient.

[0037] After receiving the service order, the entity sends a request to the time prediction system to receive from the time prediction system a predicted core presence time of the recipient at the postal address or geographic location. The request includes at least the postal address or geographic location itself and an identification code corresponding to the recipient. It can further include the earliest time and date feasible for the entity to provide service to the recipient at the postal address or geographic location.

[0038] After sending the request, the entity receives from the time prediction system the requested predicted core presence time of the recipient at the postal address or geographic location, thereby enabling the entity to deliver the service to the recipient at the postal address at the predicted core presence time of the recipient at the postal address.

[0039] Preferably, data representing the location of the recipient's mobile device is transformed on the recipient's mobile device before sending it to the time prediction system so that the time prediction system cannot locate the mobile device's location on Earth. However, the transformed location data allows the time prediction system to measure distances between different locations of the mobile device within a predetermined distance range. Correspondingly, postal addresses or geographic locations to which the service is to be delivered are transformed in the same way by the entity before sending it in a request to the time prediction system or at the time prediction system.

[0040] This prevents the time prediction system from being able to determine the recipient's exact location at any given time. The time prediction system can predict when the service recipient will be near the postal address or geographic location where the service will be delivered. However, the time prediction system only has this relative information, not absolute information on the surface of the Earth. The time prediction system can infer that the recipient is at home, but the time prediction system does not know whether this home is in the United States or Europe.

[0041] This step will further improve compliance with data protection regulations.

[0042] Preferably, the transformation of the data representing the location of the mobile device is performed by using a method selected from the group comprising at least the following: Geohashing the location data and removing an appropriate number of leading digits of the geohash code, preferably the first three digits; and - Removing an appropriate number of leading digits of the geographic coordinates of the location data, preferably removing integer geographic degrees, and preserving geographic minutes and seconds.

[0043] Thus, both the recipient's mobile device, which transmits the postal address or geographic location and further location information to the time prediction system, and any entity involved in the delivery only transmits the postal address and location data to the time prediction system in a converted format, and therefore the time prediction system cannot reconstruct the recipient's actual location on Earth.

[0044] To prevent the time prediction system from reconstructing the recipient's identity, an identification code corresponding to the recipient is established so that the time prediction system cannot reconstruct the recipient's name and postal address. For this purpose, an identification code can be assigned to each recipient of the service. Preferably, the identification code is generated by hashing data identifying the recipient, preferably by hashing the recipient's email address. If the entity sending the request to the time prediction system knows, for example, the recipient's email address and the algorithm used to calculate the identification code, the entity can calculate it itself, for example, without receiving the identification code from the service recipient's mobile device. Similarly, the recipient's identification code can be generated by any entity involved in the delivery of the service or by the recipient's mobile device. Whenever a recipient's identification code is generated, it must be distributed to other players involved in the delivery of the service, except for the time prediction system.

[0045] To further improve the probability of encountering a recipient at a postal address or geographic location, and thus the probability of successful delivery of the service, more people in the recipient's household can be included in the service. To this end, a group of mobile devices in a corresponding group of recipients can transmit to the time prediction system at least identification information corresponding to each recipient in the group or an identification code common to all recipients, and data representing the location of each recipient's mobile device at regular time intervals. This requires that additional potential recipients of the service also be regularly present at the recipient's postal address or geographic location. For example, additional family or household members of the recipient can participate in the described method. The time prediction system then calculates a predicted core presence time for any of the recipients in the group of recipients at the postal address or geographic location.

[0046] Using this preferred embodiment of the present invention, energy consumption for the delivery of services can be further reduced.

[0047] Preferably, the time prediction system calculates the probability that the mobile device is within a predetermined distance to a postal address or geographic location at a given time. The predetermined distance may be a distance that indicates a high probability of reaching the recipient when delivering to the postal address or geographic location. Thus, the predetermined distance may be 10 m, 20 m, 30 m, 40 m, or 50 m.

[0048] The simplest way to calculate the probability that a mobile device is within a given distance to a postal address or geographic location would be to calculate the relative frequency with which the recipient is at the postal address or geographic location.

[0049] The predicted core presence time of the recipient at the postal address or geographic location is preferably derived by comparing the calculated probability to a predetermined threshold probability, which may be, for example, 80%, 90%, or 95%.

[0050] A more accurate, flexible, sophisticated, and reliable way to calculate the probability that a mobile device, and therefore a recipient, is within a given distance to a postal address involves using machine learning or deep learning techniques to predict core presence times, preferably using recurrent neural network models, or long-short-term memory (LSTM) models such as periodic LSTM with weather-aware gating mechanisms (PewLSTM), or transformer-based models. These improvements help to further reduce energy consumption in the service delivery process.

[0051] To further improve the probability of finding the recipient at the mailing address or geographic location when delivering the service, additional information can be provided to the time prediction system, most preferably weather data. The time prediction system then calculates the predicted core presence time of the recipient at the mailing address or geographic location as a function of or by taking into account the additional information.

[0052] To improve the data security of the described method, several steps can be taken. For example, an authentication code can be used to verify whether the mobile device is authorized to transfer data representing its location to the time prediction system. This authentication code should have been exchanged at some point between the time prediction system, the entity, and the mobile device.

[0053] Another possibility to further improve data security is to use a proxy server to transmit location data from the mobile device to the time prediction system, so that the time prediction system does not even know the IP address of the recipient's mobile device.

[0054] Yet another possibility would be for the time prediction system to generate an event token after receiving a request by an entity, e.g., an online shop. The event token would be linked to a specific delivery event. After receipt of the event token by the entity, the entity or, e.g., a delivery agent responsible for delivering a package, can use the event token for all future requests to the time prediction system related to this delivery event. The event token can also be passed from the online shop to the delivery agent. This event token is invalidated after successful delivery of the service to the recipient at the postal address.

[0055] The method determines a predicted core presence time of a recipient at a postal address or geographic location to which the service is to be delivered. Unnecessary delivery attempts can be further avoided if the recipient's actual presence at the postal address is checked immediately prior to delivery of the service to the recipient at the postal address. The check can be performed by sending a corresponding request from the entity to the time prediction system.

[0056] Alternatively, the time prediction system monitors the distance between the mobile device's location and a postal address or geographic location. It then determines whether the mobile device is at the postal address or geographic location or whether it can reach the postal address or geographic location within the predicted core presence time. The time prediction system updates the predicted core presence time if the mobile device is unlikely to be at the postal address or geographic location during the predicted core presence time. Updates can be actively sent to the entity (push service). Or, the entity periodically requests such updates from the time prediction system (pull service).

[0057] In other words, the time prediction system can check the distance between the moving transformed location of the mobile device in the time prediction system and the fixed transformed postal address or transformed geographic location so that during the predicted core time, the time prediction system does not predict a core presence time where the moving transformed location cannot reach in time to establish presence at the fixed transformed location.

[0058] To achieve the object of the invention, the inventors also propose a method including the following steps: - collecting data at the point of collection; - anonymizing the data at the point of collection; - transferring the anonymized data to a data room; - Enriching the anonymized data in the data room, where personalization recommendations or insights are derived from the data by enriching the anonymized data using, for example, a deep learning model; and Obtaining personalized recommendations or insights using the cryptographic key, wherein the possibility of obtaining personalized recommendations or insights is limited in time.

[0059] With the help of this method, insights can be generated in a data protection compliant manner, which can be useful for many applications, among others, to reduce energy consumption in the delivery of services. [Brief explanation of the drawings]

[0060] Other objects and advantages of the present invention can be ascertained by reading this specification and the appended claims in conjunction with the drawings. For a more complete understanding of the present invention, reference is made to the following description of the embodiments, taken in conjunction with the accompanying drawings. The possibilities for solving the problem are not limited to the embodiments. Exemplary embodiments are illustrated diagrammatically in the drawings. The same reference numerals in the different figures indicate elements that are identical or functionally identical or correspond in terms of their functionality. In particular, the figures show:

[0061] [Figure 1] FIG. 1 is a flow diagram of a method for calculating a user's predicted core presence time, according to one embodiment. [Figure 2] 2 is a schematic diagram of method steps performed by a temporal prediction system according to one embodiment; [Figure 3] FIG. 1 is a schematic diagram of an information exchange overview between a user, an app operator, and a time prediction system, according to one embodiment. [Figure 4] FIG. 10 is a flow diagram of a method for c to request a user presence prediction, according to one embodiment. [Figure 5]FIG. 1 is a schematic diagram outlining the information exchange between a user, an app operator, and a time prediction system upon creation of an event by a user, according to one embodiment. [Figure 6] FIG. 10 is a flow diagram of the Post Location API and the Event Token API, according to one embodiment. [Figure 7] FIG. 10 is another flow diagram of the Post Location API and Event Token API, according to one embodiment. [Figure 8] FIG. 10 is a flow diagram of the Core Time API and the Backup Check API, according to one embodiment. [Figure 9A] FIG. 1 is a schematic diagram of an RNN cell. [Figure 9B] FIG. 1 is a schematic diagram of an LSTM cell. [Figure 9C] Schematic diagram of a PewLSTM cell. [Figure 10] Schematic diagram of the PewLSTM architecture. [Figure 11] FIG. 1 is a schematic diagram of one embodiment of the described method. [Figure 12] FIG. 1 is a schematic diagram of another embodiment of the described method. DETAILED DESCRIPTION OF THE INVENTION

[0062] The present approach allows a user (i.e., a consumer) to know the core time at an address in compliance with the General Data Protection Regulation (GDPR). For this, an operator, such as an app operator 22 (see FIG. 3), interacts with the time prediction system 3 (see FIGS. 2 and 3), as described below. The app operator 22 may be, for example, an online shop.

[0063] The time prediction system 3 is configured to provide a data protection compliant core presence time prediction (DCP), and therefore the time prediction system 3 according to the present disclosure may also be intended as a DCP system.

[0064] 1 and 2 , a method 100 for calculating a user's predicted core presence time 7 includes, in one embodiment, transferring the user's postal address information data 1 together with identification data 2 to a time prediction system 3 in step S101. In particular, these information data are sent to the time prediction system 3 by an app operator via a transfer element, such as an app operator 22. The postal address data 1 and the identification data 2 may be referred to as first input data 4.

[0065] In step S102, location information data 5 of the app user is transferred to the time prediction system 3 together with the application user's identification data 2. The application user is the recipient of the service. The location data 5 and the identification data 2 may be referred to as second input data 6. These data are transferred sequentially, i.e., sent multiple times at different times or at regular intervals. In step S103, the authentication of the app operator is confirmed by the time prediction system 3.

[0066] The first input data 4 and the second input data 6 are then processed in step S104 to calculate a predicted core presence time 7 of the app user. This results in a prediction of the core presence time 7 as output data 8 based on at least the postal address information data 1 and the app user's location information data 5. The predicted core presence time 7 is a time window DCP calculated as being likely to have at least one person present at the postal address.

[0067] The processing of the input data includes a conversion step (S105). In particular, the app user's postal address information data 1 is converted into the location of the postal address on a relative map. The relative map is used to specify an arbitrary coordinate system that does not allow for identification of the location on Earth of any coordinate on the relative map. However, the coordinates on the relative map allow for measuring the distance between different coordinates on the relative map within a predetermined distance range.

[0068] After converting the app user's 22 geographic coordinates into relative map coordinates, the relative map coordinates are hashed using a hash function into an address geohash 9. The app user's location data 5 is converted into a relative map location, which is then transformed using a geohash function 10. Advantageously, attempts to revert the geohash back to the original data provide only fictitious information unrelated to the actual personal data and postal address and location data provided by the app user, thereby improving data protection and security for the app user. As described in more detail below, the DCP system uses multiple layers of data protection and security technologies to meet global data protection standards.

[0069] It should be noted that the DCP system uses prescriptive analytics, which means that it provides automated recommendations for action regarding the future based on facts and probability-weighted predictions based on predictive analytics. Predictive analytics encompasses various statistical techniques, such as data mining, predictive modeling, machine learning, and AI, to analyze current and past facts to make predictions about future or other unknown events.

[0070] As input data (first and second input data), the mobile location data of the app user can be considered as core data. However, additional data, such as local information data such as observed weather conditions or forecasts, can also be used.

[0071] In another embodiment of the present invention, the method 100 includes providing additional information 15 as third input data 16 to the time prediction system 3, where in particular the additional information data 15 includes weather data. Automated analysis of this information is used to learn the impact of such conditions (i.e., weather) on presence patterns at the address and improve predictions. Note that the local information data is not limited to information such as weather information, and additional data sources can be added. The additional data sources can include, but are not limited to, information such as traffic or holidays.

[0072] 2 shows a schematic representation of the refinement of input data 4, 6, 16 into output data 8. In one embodiment, the first input data 4 includes at least postal address information data 1 and identification data 2 of the app user. These data are provided to the time prediction system 3 or the DCP system only once. The second input data 6 includes at least location information data 5 and identification data 2 of the app user. These data are provided to the time prediction system 3 sequentially. Furthermore, third input data 16 is provided to the time prediction system 3. These data include additional information data 15, such as weather information, among others.

[0073] The time prediction system 3 includes a conversion module 12 for converting the postal address information data 1 and location information data 5 received by the app operator into hashes. This conversion module 12 is provided in the form of a software development kit (SDK). Specifically, the app user's postal address information data 1 is converted into the location of the postal address on a relative map to form a geohash associated with the postal address (i.e., address geohash 9), and the app user's location information data 5 is converted into the location of the location on the relative map to form a geohash associated with the location (i.e., location geohash 10). This is performed via a hash function module 11. The coordinates are then hashed using a hash function to obtain the geohash. In other words, when converting the app user's location information data 5 and postal address information data 1 into a postal address and the location location on the relative map, the exact location of the app user's location on Earth is removed from the address geohash 9 and location geohash 10. An identification code is calculated by hashing the app user number.

[0074] In some embodiments, the location of the address geohash 9 is periodically compared with the placement of the location geohash 10 on the relative map to obtain comparison result data 14 for predicting the app user's core presence time 7. To this end, the time prediction system 3 also includes a comparison processing module 13. In particular, to obtain the comparison result 14, the distance between the placement of the postal address on the relative map and the placement of other visited locations on the relative map is calculated.

[0075] The periodic comparison serves as the basis for providing a forecast of core time over a determined time frame. The periodic comparison also ensures continuous learning of core time and ensures updates of core time if changes in patterns or behavior are detected.

[0076] To further improve data security, core time predictions are calculated only when there is a prediction request from the entity and are repeated only until the event, i.e., delivery, is completed. In other words, the app user's presence at the determined postal address is predicted only if it is necessary for the delivery of the service. If no delivery event is scheduled, core time is not calculated.

[0077] Figure 3 illustrates an application of the method 100. In the embodiment of Figure 3, first input data 4 and second input data 6 are transferred by an app operator 22 to the time prediction system 3.

[0078] DCP systems can be integrated via application programming interfaces (APIs). To function at their full potential, DCPs need to be integrated into flexible systems capable of processing live data. As an added feature, DCPs can further operate as white-label solutions that are invisible within the systems they are integrated into. Examples of essential systems that can be connected to a DCP for last-mile logistics use cases could be an online retailer's offer processing system, as well as transportation management systems, trip planning systems, and delivery service routing systems.

[0079] Referring to Figure 3, an app user (or consumer) authorizes location utilization within an app with an app operator 22. When this occurs, the app operator 22 automatically forwards postal address information data 1 along with the app user's (service recipient's) user ID number 2 to a time prediction system 3 (i.e., DCP system). Additionally, the app user's location information data 5 and ID number 2 are sequentially forwarded by the app operator 22 to the DCP system 3. Note that sequential transmissions of data are identified in the figure by dashed lines, while single transmissions are identified by solid lines.

[0080] As soon as any message is directed to the DCP API system, the first step is authentication. A new application operator receives an authentication code in the DCP integration process, which must be sent with each message the application operator sends to the DCP API. In particular, the method 100 includes checking this authentication code by the time prediction system 3 upon receiving at least first input data 4 and second input data 6. Messages without a valid authentication code will not be processed, and incoming data without an authentication code will be automatically rejected.

[0081] 4 is a flowchart of one embodiment of a method 200 for requesting a presence prediction for an app user, particularly for requesting a presence prediction for at least one user at a particular postal address, which may be useful when there are multiple users at the same postal address.

[0082] In step S201, a predicted core presence time 7 of the app user is calculated. This prediction is obtained according to the method 100 described above. Therefore, not all of the detailed steps are repeated. In step S202, an event 23 is generated by the app user or an entity involved in the delivery of the service. The event 23 can be, for example, a commercial order. A presence prediction request 17 (see FIG. 5) is then forwarded to the time prediction system 3 (S203), typically by an entity involved in the delivery of the service.

[0083] In some embodiments, the presence prediction request 17 includes a delivery address 18, a user number or identification information of the app user, an authentication code of the app operator, and event information data, which, among other things, notifies that an event 23 is occurring.

[0084] In step S204, the time prediction system 3 creates an event token 19, and sends an information request 20 regarding the application user's core presence time 7 together with the event token 19 to the time prediction system 3 (S205).

[0085] Finally, in step S206, the validity of the event token 19 is analyzed and result information 21 is sent, which includes the app user's previously calculated predicted core presence time 7 at the requested delivery address. Note that result information 21 does not include the app user's personal data, and map data connected to their actual geographic location on Earth.

[0086] In some embodiments, the method includes authenticating and hashing the presence prediction request 17 by the temporal prediction system 3. This is performed in step S207.

[0087] Once the event 23 generated by the app user is completed, the method may include deleting the event token 19 (step S208).

[0088] FIG. 5 illustrates one embodiment of the application of method 200.

[0089] An event 23 (e.g. an order with expected home delivery) is generated. As soon as said defined event 23 occurs, the information that this event has occurred is forwarded to the DCP system 3 in a presence prediction request 17 together with the identification information and postal address of the corresponding customer number R.

[0090] After successfully authenticating and hashing this request 17, the DCP system 3 automatically creates and returns an event token 19. This event token 19 can be used to send an information request 20 to the DCP API system 3 to obtain result information 21. If the event token 19 is valid, the DCP system 3 responds with result information 21. Only the predicted core presence time 7 at the postal address is present in this result information 21. The delivery address itself and the app user number 2 are not present in this result 21, meaning that the result 21 does not contain personal data. In other words, in the complete relationship between the app operator 22 and the DCP system 3, the name of the app user / consumer remains unknown to the DCP system 3. Because the app operator 22 knows for which app user the event token 19 was requested, only the qualified app operator 22 who provided the app information in the first place can link the result to the postal address.

[0091] As soon as the purpose of the event token 19 is achieved (e.g., the shipment is delivered), this information is automatically forwarded to the DCP system 3. The DCP system 3 automatically and immediately deletes the event token 19 and returns information that the event token 19 has been deleted. Information that the token has been deleted cannot be obtained and any request for the token to be deleted is automatically denied.

[0092] It should be noted that the DCP System 3 software was built to exceed all global data protection standards to ensure global applicability and acceptance. Therefore, a minimum personal data approach was pursued, i.e., the use of the absolute minimum amount of personal data necessary to achieve the purposes agreed upon by app users in the app (mobile application) of the app operator 22 that uses the DCP System 3.

[0093] As described above, the present approach improves data protection and security. The DCP System 3 processes mobile location data under significantly stricter standards than those known from typical location-based services (LBS). The DCP System 3 sets new standards for data protection and security through a variety of means, including:

[0094] 1.Authentication Code The authentication code allows only qualified app operators 22 to interact with the system regarding their app users' events 23.

[0095] 2. All incoming data is unnamed and unhashed The system cannot process or accept names, so the names remain unknown to the system. App user numbers, postal addresses, and location data are hashed. There is no cleartext data in the system.

[0096] 3. Relative map (no real address, no real location) Postal address and location data 1, 5 are stored in the system as geohashes 9, 10. These geohashes 9, 10 are stored as relative map locations. Because there is no actual map data, even if the system were hacked and the hacker found a way to "unhash" the hashed locations and hashed addresses, the data would be inaccessible because they are merely relative map locations (no address, no city, no country). In contrast to typical LBSs, our approach does not track which streets app users use or which addresses and stores they visit during their travels. Furthermore, the DCP system 3 does not analyze purchasing preferences and is never used to influence users / consumers.

[0097] 4. No confirmation or prediction of absence DCP System 3 does not predict absence time frames, and results do not confirm absence. In general, time frames at an address can be divided into categories of core presence time, core absence time, and variable behavior. DCP System 3 cannot distinguish between and does not analyze core absence time and variable behavior. Instead, the method only predicts core presence time when someone is typically always at the postal address and updates these time frames.

[0098] 5. Location usage permission The DCP system 3 only processes data of app users who have confirmed continuous location usage in the app of the app operator 22 using DCP integration, for the purposes made available to the app user in the confirmation process.

[0099] 6. Event token / Provision of address / personal data free result / Time limit The results generated by the DCP can only be accessed with a valid event token 19. This token is sent to the party that originally provided the app user information. Processing results, available only with a valid event token 19, do not contain the app user's address or personal information until the purpose of the event 23 is accomplished (e.g., a shipment is delivered). Only the qualified app operator 22 who requested the event token 19 can link the results to a postal address during the event 23 (e.g., delivery).

[0100] Figures 6, 7, and 8 show flow diagrams for operational aspects of the above-described methods for some embodiments. These flow diagrams represent application programming interfaces (APIs), which are public endpoints that check authorization, collect and transfer data, and return information.

[0101] In Figure 6, the Post location API in this embodiment collects the authentication code and checks whether it is valid. If it is not valid, the request is rejected. If it is valid, the request is authenticated, the customer ID2 is hashed and stored in persistent storage, and the location on the relative map is converted to a geohash that is stored in persistent storage.

[0102] In Figure 7, the Event API collects the authentication code and checks whether it is valid and whether the user exists. If it is not valid, the request by the entity is rejected. If it is valid, the request is authenticated. The latitude and longitude of the delivery address on the relative map are hashed as a geohash 9. The geohash 9 of the postal address is then stored in persistent storage along with the hashed customer ID and information that a defined event 23 has occurred. The relative map calculates the distance using the stored data, and then supplies the delivery address distance to the model to train the model.

[0103] In Figure 8, the Core Time API collects the event token and checks whether it is valid. If it is not valid, the request is rejected. If it is valid, the system fetches predicted core times based on the trained model and returns them as an array of core times. If the event has not ended, the fetching and prediction of core times 7 is repeated to recheck the predictions and respond to changes in the app user's behavior.

[0104] In some embodiments, an app user's core presence time 7 can be updated if a change in the match between the location of an address geohash 9 and the location geohash 10 on the relative map occurs within a predetermined time period. Thus, capturing changes in presence behavior and updating presence predictions accordingly is essential to adapt to situations such as changes in work hours or changing habits. For example, someone working the night shift, or someone starting their walk in the park at noon, and similar changes can affect presence predictions. These changes are particularly important to capture for certain services related to consumer presence, such as home delivery.

[0105] As described in more detail below, the data is processed using machine learning or deep learning techniques to predict the app user's core presence time 7. The machine learning or deep learning model is trained to calculate the app user's presence during a specific time frame. Specifically, comparison result data 14 obtained by calculating distances between the postal address location and the locations of other visited places on a relative map is fed into the machine learning or deep learning algorithm to perform the core presence time prediction.

[0106] Our model aims to predict the core presence time window of app users at a postal address based in part on historical data. This type of problem is called "time series forecasting." Many models have been used to solve this problem. For example, the univariate "autoregressive moving average (ARMA)" model, which combines an autoregressive (AR) model with a moving average (MA) model for a single time series, or the univariate "autoregressive integrated moving average (ARIMA)" model, which considers differences compared to ARMA, are all traditional methods for time series forecasting. In recent years, with the spread of machine learning (ML) and deep learning (DL) techniques, new methods have been introduced. The most successful algorithms have been based on deep learning, such as recurrent neural networks (RNNs), especially long-short-term memory (LSTM). "PewLSTM" is a novel periodic weather-aware LSTM model. PewLSTM evaluates historical data along with weather and weekdays to estimate future parking behavior, achieving approximately 20% better accuracy than state-of-the-art parking behavior prediction methods. Since the problem of predicting core time presence of a person at a particular postal address is weekday and weather dependent, PewLSTM appears suitable for use in the present method.

[0107] Time series data are a collection of continuous quantities collected over uniform intervals in time. These measurements are used to track fluctuations in the data. Analyzing them using statistics and models to predict future variables is called time series forecasting. Time series forecasting can be either univariate, where a single feature is used, or multivariate, where multiple features are used (which is more complex). Predicting a single value for a future time step or multiple time steps is called one-step and multi-step time series forecasting, respectively. As mentioned above, the difference between univariate and multivariate forecasting is the number of features used to train the model, so only the dimensionality of the input vector needs to be changed. However, there are many methods for multi-step forecasting compared to one-step, including direct multi-step, recursive multi-step, and multi-output forecasting. In direct multi-step forecasting, a different model is trained for each forecast time step, which differs from recursive multi-step forecasting, in which a one-step model is used recursively each time for prediction. In multi-output forecasting, a model is trained to predict the entire output of a single time step as a vector.

[0108] One deep learning method for time series forecasting is the recurrent neural network (RNN). Recurrent neural networks are deep learning models that take sequential data, such as time series data, as input. Their output depends on the preceding elements in the sequence. RNNs can process variable-length sequence inputs using their internal state (memory), which is called the recurrent hidden state.

[0109] Input Sequence Define JPEG2026502309000002.jpg1681 and define the iterative hidden state ht at time step t. ht is updated using the following formula: JPEG2026502309000003.jpg17107 where the nonlinear activation function is denoted by σ, which can be, for example, a logistic sigmoid, a hyperbolic tangent function, or a rectified linear unit (ReLU). x , Wh is the weight matrix, b t is a constant bias.

[0110] An RNN cell is shown in Figure 9A.

[0111] RNNs have shown difficulty learning long-term dependencies because they suffer from the "vanishing gradient" problem. A gradient is the partial derivative of a function with respect to its input, measuring the effect of a change in the input on the output. The "vanishing gradient" problem occurs when the weight matrix becomes so small that the model no longer learns. Since long sequences mean many layers, gradients tend to vanish easily. This problem is addressed by the Long Short-Term Memory (LSTM) model.

[0112] The variables are as follows: JPEG2026502309000004.jpg77121

[0113] where: JPEG2026502309000005.jpg88 stands for Hadamard or element-wise product, and f t represents the forget gate, which determines what information needs to be forgotten from the LSTM memory. The input gate that determines whether new information is stored in the LSTM memory is represented by g t is the cell input activation at which a new candidate vector is stored in the LSTM memory. t is the output gate that determines the value of the next hidden state. t h memorizes information from the previous interval in the LSTM cell and is in the hidden state. t carries information from the previous cell to the next cell. The weight matrix W represents how much a change in the input affects the output, and the bias b determines the difference between the function's output and the desired result.

[0114] The LSTM cell is shown in Figure 9B.

[0115] LSTM models solve the "vanishing gradient" problem, but lack the ability to learn periodic patterns and weather information. These problems are solved by a periodic LSTM with a weather-aware gating mechanism called PewLSTM. A PewLSTM cell is shown in Figure 9C.

[0116] PewLSTM differs from typical LSTMs in that new gates are added for historical periodic observations and weather data. The behavior at the same time in the previous day, week, and month can affect the current behavior. Biweekly behavior can also be taken into account, as it often occurs in human activities such as work and study. The variable h day , h week , h biweekly and h month describes the hidden states that represent these behaviors. These hidden states are then transformed into the hidden states h of the LSTM using a special weight gate δ. t-1 and is integrated into the following equation: The purpose of the weight gate is to continuously update the weight of each parameter. JPEG2026502309000006.jpg12131

[0117] Weather condition vector e t can be introduced to capture the effect of weather information on presence behavior, which is integrated into the forget gate, input gate, and output gate. The weather at time step t is used as the input of a standard feedforward layer with a sigmoid activation function. JPEG2026502309000007.jpg1892

[0118] weighted hidden state h o and weather input t are then the forget gate, input gate and output gate f t , i t and o t However, the hidden state h t and cell state c t The formula for the periodic and weather information is already included in the correction variable f as shown in the following formula:t , i t , and o t This remains the same as for LSTMs, as it is computed and stored by JPEG2026502309000008.jpg56128

[0119] In some embodiments, the calculation of the predicted core time 7 for at least one user at a particular postal address is repeated in sequence using different data processing techniques.

[0120] Successive iterations using different techniques, along with hashed location data on a relative map and distance calculations for hashed postal addresses, determine live optimization. In particular, predicted core presence times are removed if it is determined that a presence cannot be established in time at a postal address. Therefore, even if there are errors in the core presence time predictions for the next few days, live optimization automatically eliminates the errors if there are no outlier cases. Outlier cases include, but are not limited to, situations where an app user turns off their mobile phone, their mobile phone runs out of battery, their mobile phone is forgotten, or the unlikely event of a server failure.

[0121] Loss functions are used during model training to determine how the model performs by expressing the error between the model output and the target variable (the variable to be predicted). Since loss refers to the closeness between the predicted data and the actual data, the goal is to make it as small as possible. There are many loss functions, such as mean absolute error (MAE), mean squared error (MSE) for continuous output data, and binary cross entropy (BCE) for binary data. Since the output is binary (no predicted core presence time or no predicted core presence time within the time window), binary cross entropy (BCE) loss is introduced, along with a derivative of this loss, which makes it possible to improve the results of the trained model.

[0122] The formula for binary cross entropy loss is given by: JPEG2026502309000009.jpg40166where, p i and y i are the i-th scalar values ​​of the model output and the target, respectively. N represents the output size.

[0123] Binary cross entropy loss requires the use of a sigmoid activation function before the target layer, because a sigmoid compresses the output between 0 and 1. This works as follows: when the actual class value is 1, the second part disappears, and vice versa. For a target value p i is between 0 and 1, so p i or 1-p i The logarithm of lies between -infinity and 0. Thus, the closer the prediction is to the true class, the smaller the loss.

[0124] Weighted binary cross-entropy loss is an extension of binary cross-entropy loss. This extension works by adding more weight to positive examples to punish their incorrect predictions. In particular, it penalizes incorrect prediction core time at a particular position. The formula for weighted binary cross-entropy loss is given by: JPEG2026502309000010.jpg40166 formula, p i , y i and N are the same as before, and w i is the weight of the positive examples.

[0125] Regarding the input data for calculating the predicted core presence time 7 by the present method, these are the distances between the location and the postal address, as described above. Then, the distance d between the location of the postal address on the relative map and the location of other visited locations on the relative map is calculated using the distance formula on a 2D plane, which is: JPEG2026502309000011.jpg40166 where (x1, y1) is the location of the first point on the relative map and (x2, y2) is the location of the second point.

[0126] The x and y values ​​can be calculated, for example, by transforming the geographic minutes and seconds into the x,y plane. For example, if a geohash was used, the x and y values ​​can be obtained by decrypting the geohash value of the transformed location data. In general, the method used to find the x and y values ​​must be suitable for retransforming the transformed location data.

[0127] Distances are given in meters. Outliers are then filtered using a Z-score of 3, which is set as the minimum outlier value. A Z-score of 3 means that any distance outside three standard deviations of the data distribution is an outlier.

[0128] Weather data, along with distance, are used as input data for the model. Weather features include, but are not limited to, temperature, relative humidity, wind speed, and precipitation. The data is normalized using a MinMax scaler before being fed into the model.

[0129] Referring to model training, note that a custom periodic LSTM with a weather-aware gating mechanism is implemented using the variables defined above. For each batch size, the hidden states for the previous day, week, biweekly, and month are captured along with weather information to calculate the next hidden state, which is then used in backpropagation to update the model's parameters. Backpropagation represents the calculation of the gradient of the loss function with respect to the network's weights. To train a deep learning model, an optimizer, a learning rate, the number of epochs, and a batch size are required. The optimizer is a function that searches for the best parameters and weights and optimizes the results. The learning rate is the step used by the optimizer at each iteration to minimize the loss function. The number of epochs represents the number of times the model is trained on the entire training data, and the batch size defines the number of samples used each time to update the model's weights. In particular, the Adam optimizer, with a learning rate of 0.01, epochs of 150, and a batch size of 156 can be used for training.

[0130] An example of a PewLSTM model architecture with possible input and output sizes is shown in Figure 10. The PewLSTM model consists of one input layer, two hidden layers, and one output layer. The input layer has three dimensions. The first dimension corresponds to the batch size. The second corresponds to the number of past distances used to make the prediction (if the location is captured every 5 minutes between 08:00 and 21:00, the number of past distances is 156 data points). The third corresponds to the number of features used depending on the number of weather features. For example, the third dimension of the input vector is 3 if temperature and humidity are used as weather features, because the first feature is the distance vector, and therefore the temperature and humidity vectors are the second and third features. The second and third layers in the architecture shown in Figure 10 are hidden layers that identify features from the input data and use them to correlate distances with core presence time. The final layer is the output layer, which constructs the PewLSTM output after applying a sigmoid activation function and calculating the binary cross-entropy loss. For example, an output vector of size 26 is used to predict core presence times at 30 minute intervals between 8:00 and 21:00 for the next three days.

[0131] 11 shows a schematic overview of one embodiment of the described method for saving energy in the delivery of services. A recipient regularly carries a mobile device. The recipient has installed an app on the mobile device 1110 that is linked to an entity 1105 involved in the delivery and a time prediction system 1115. During the installation process, an identification code was assigned to the app on the mobile device 1110, the mobile device, or the recipient. In step 1112, the app periodically transmits its location along with the identification code to the time prediction system 1115.

[0132] In an embodiment according to Figure 11, an entity 1105 receives an order to deliver a package to a recipient. The entity can then notify the recipient of the scheduled delivery of the package via an app on the mobile device 1110 in step 1120. This allows the recipient of the service to track the status of the delivery (1125).

[0133] Following receipt of an order to deliver a package to a recipient, entity 1105 sends a request 1130 to time prediction system 1115. The request includes an identification code, a delivery address in the form of either a postal address or a geographic location to which the package is to be delivered, and the earliest delivery time and delivery date feasible for entity 1105. With this request, entity 1105 asks time prediction system 1115 to send the recipient's predicted core presence time at the delivery address.

[0134] The time prediction system 1115 uses the information received in the request 1130 from the entity 1105 and the continuously received location data 1112 of the recipient's mobile device to calculate the recipient's core presence time at the delivery address. In step 1135, the time prediction system 1115 sends the recipient's core presence time at the delivery address to the entity 1105. The core presence time is given for a period starting from the earliest delivery time and delivery date achievable for the entity 1105, for example, spanning two or three days.

[0135] With the help of core time, entity 1105 can schedule deliveries to recipients 1140. This approach reduces failed delivery attempts and inefficiencies associated with delivery appointments, thus reducing the energy consumption of the delivery service.

[0136] Figure 12 illustrates another embodiment of the described method for saving energy in a delivery service. Figure 12 illustrates an embodiment of a recipient 1205 ordering a product from an online shop 1210. Many of the steps illustrated in Figure 12 are identical to the corresponding steps in Figure 11. They have the same reference numbers and will not be repeated again in the description of Figure 12.

[0137] The recipient 1205 must register with the online shop 1210. During this registration process, the online shop 1210 collects the name and postal address or geographic location of the recipient 1205. In the embodiment of FIG. 12, the online shop 1210 then generates an identification code for the recipient 1205. In step 1215, this identification code is sent from the online shop 1210 to an app on the recipient's 1205's mobile device 1110 (alternatively, the identification code can be generated in an application on the mobile device). This allows the mobile device 1110 to periodically send its converted location along with its ID to the time prediction system 1115 in step 1112.

[0138] Ordering a product in the embodiment shown in FIG. 12 begins with a recipient 1205 ordering a product from an online shop 1210 in step 1220. After receiving the order, the online shop 1210 sends a delivery order to a delivery agent 1105. This delivery agent 1105 may be either separate from the online shop or a division of the online shop. The delivery order contains information necessary for the delivery agent 1105 to fulfill the delivery order. This requires that the delivery order include the name and postal address or geographic location of the recipient 1205. Additionally, the order must include at least information about the product or package to be delivered and the location to receive it.

[0139] Upon receiving a delivery order, the delivery agent 1105 may proceed with the same steps as described in connection with FIG.

[0140] While the present invention has been described and illustrated with reference to several specific embodiments, those skilled in the art will recognize that variations and modifications can be made without departing from the principles of the invention as exemplified herein, as described and claimed. The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are considered in all respects to be illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims, rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. A method for reducing energy consumption for delivery of a service to a recipient (1205) of said service at a postal address (1) or geographic location, said method comprising the following steps: 1.1 said recipient's mobile device (22; 1110) comprises at least 1.1.1 An identification code (2) corresponding to said recipient (1205); 1.1.2 data representative of the location (5) of said mobile device (22; 1110); 1.1.3 A step of transmitting (S102; 1112) to a time prediction system (3; 1115) at regular time intervals; 1.2 said time prediction system (3; 1115) receiving and storing said data representing said location (5) and storing them together with said identification code (2) of said recipient (1205) and a timestamp; 1.3 An entity (1105) receiving an order (1230) to deliver said service to said recipient (1205) at said postal address (1) or geographic location; 1.3.1 The order (1230) is at least 1.3.1.1 said postal address (1) or geographic location; and 1.3.1.2 said data identifying said recipient; 1.3.2 said entity (1105) further receives said identification code (2) of said recipient (1205) or calculates said identification code of said recipient based on data identifying said recipient; 1.4 after receiving the order (1230), the entity (1105) sends to the time prediction system (3; 1115) a request (S205; 1130) to provide the entity with a predicted core presence time (7) of the recipient (1205) at the postal address (1) or geographic location; 1.4.1 The request (S205; 1130) includes at least: 1.4.1.1 said postal address (1) or geographic location; and 1.4.1.2 The identification code (2) corresponding to the recipient (1205), 1.5 After receiving the request (S205; 1130), the time prediction system (3; 1115) calculates (S201) the requested predicted core presence time (7) of the recipient at the postal address (1) or geographic location using the location (5) and the postal address (1) or geographic location received from the mobile device; 1.5.1 providing (8; 1135) the entity with the requested predicted core age (7) of the recipient (1205); 1.5.2 thereby assisting the entity (1105) in delivering the service to the recipient (1205) at the postal address (1) or geographic location at the predicted core presence time (7) of the recipient at the postal address.

2. 1. A method for reducing energy consumption for delivery of a service to a recipient (1205) of said service at a postal address (1) or geographic location, comprising: 2.1 A time prediction system (3; 1115) receives from the recipient's mobile device (22; 1110) at least one time interval. 2.1.1 an identification code (2) corresponding to said recipient; 2.1.2 receiving (S102; 1112) data representative of the location (5) of said mobile device (22; 1110); 2.2 The time prediction system 2.2.1 the data representing the location (5), 2.2.2 said identification code of said recipient (2); and 2.2.3 storing with a timestamp; 2.3 said time prediction system (3; 1115) receiving a request from an entity to provide a predicted core presence time (7) of said recipient at said postal address (1) or geographic location; 2.4 The request (S205; 1130) is at least 2.4.1 said postal address (1) or geographic location; 2.4.2 The identification code (2) corresponding to the recipient (1205), 2.5 After receiving the request (S205; 1130), the time prediction system provides (8; 1135) the requested predicted core existence time (7) to the entity; 2.5.1 thereby enabling the entity (1105) to deliver the service to the recipient at the postal address or geographic location at the predicted core presence time (7) of the recipient at the postal address (1).

3. A time prediction system comprising means for carrying out the method of claim 2.

4. A computer program comprising instructions that, when executed by a computer of the time prediction system (3; 1115) of claim 3, cause said computer to carry out the method of claim 2; or 4.1 A computer-readable medium storing said computer program.

5. A computer program for a mobile device (22; 1110) of a recipient (1205) of a service, said program including on said mobile device at least 5.1 an identification code (2) corresponding to said recipient; 5.2 data representative of the location of said mobile device (5); 5.3 A computer program for transmitting at regular time intervals to a time prediction system (3; 1115) which executes the method according to claim 2.

6. 1. A method performed by an entity (1105) involved in the delivery of a service to a recipient (1205) at a postal address (1) or geographic location, said method comprising the steps of: 6.1 said entity (1105) receiving an order to deliver said service to said recipient (1205) at said postal address (1) or geographic location; 6.1.1 The order (1230) is at least 6.1.1.1 said postal address (1) or geographic location; and 6.1.1.2 the name of the recipient; 6.1.2 the entity further receives an identification code (2) corresponding to the recipient or calculates the identification code (2) corresponding to the recipient based on information about the recipient; 6.2 after receiving the order (1230), the entity sends a request (S205; 1130) to the time prediction system (3; 1115) of claim 3 to receive from the time prediction system the predicted core presence time (7) of the recipient at the postal address (1) or geographic location; 6.2.1 The request is at least 6.2.1.1 said postal address (1) or geographic location; and 6.2.1.2 said identification code (2) corresponding to said recipient (1205); 6.3 After sending the request (S205; 1130), the entity receives (8; 1135) from the time prediction system the predicted core existence time (7) of the recipient of the request; 6.3.1 thereby enabling the entity (1105) to deliver the service to the recipient at the postal address (1) or geographic location at the predicted core presence time (7) of the recipient at the postal address or geographic location.

7. 7.1 The data representing the location (5) of the mobile device (22; 1110) of the recipient (1205) are transformed on the mobile device of the recipient before transmitting them to the time prediction system (3; 1115), whereby 7.1.1 the location of the mobile device cannot be located on Earth by the time prediction system; 7.1.2 However, the transformed location data enables the time prediction system (3; 1115) to measure distances between different positions of the mobile device within a predetermined distance range; 7.2 The postal address (1) or geographic location to which the service is to be delivered is converted in the same way; 7.3 Preferably, the transformation of the data representing the location of the mobile device comprises at least: 7.3.1 Geohashing the location data and removing an appropriate number of leading digits of the geohash code, preferably the first three digits; and 7.3.2 removing an appropriate number of leading digits of the geographic coordinates of the location, preferably removing the integer geographic degrees and preserving the geographic minutes and seconds; 3. The method according to claim 1 or 2.

8. 8.1 said identification code (2) corresponding to said recipient (1205) is established in such a way that said time prediction system (3; 1115) is unable to reconstruct said name and postal address (1) or geographic location of said recipient, 8.2 Preferably, the identification code (2) is generated from data identifying said recipient, preferably by hashing said data identifying said recipient, preferably by hashing said recipient's email address, such that data identifying said recipient (1205) cannot be reconstructed from said identification code; 4. A method according to any of the preceding method claims.

9. 9.1 The group of mobile devices of the corresponding group of recipients is at least 9.1.1 an identification code (2) corresponding to said individual recipient, or an identification code common to all recipients of said recipient group, and 9.1.2 data representing the location of the mobile device of the individual recipient; 9.1.3 transmit to the time prediction system at regular time intervals; 9.2 The time prediction system calculates the predicted core presence time (7) of any recipient of the group of recipients at the postal address (1) or geographic location; 4. A method according to any of the preceding method claims.

10. 10.1 said time prediction system (3; 1115) calculates the probability that said mobile device (22; 1110) is within a predetermined distance to said postal address (1) or geographic location at a given time; 10.2 By comparing the calculated probability with a predetermined threshold probability, the predicted core presence time (7) of the recipient (1205) at the postal address (1) or geographic location is derived; 4. A method according to any of the preceding method claims.

11. The prediction of the core existence time (7) is performed using machine learning or deep learning techniques, preferably using a recurrent neural network model or a long short-term memory (LSTM) model such as a periodic LSTM or a transformer-based model with a weather-aware gating mechanism.

11. The method according to claim 10.

12. 12.1 Providing additional information (15), preferably weather data, to said time prediction system (3; 1115); 12.2 the time prediction system calculating the predicted core presence time (7) of the recipient (1205) at the postal address (1) or geographic location as a function of the additional information; 12. The method (100) of claim 10 or 11, further comprising:

13. The following steps, 13.1 Using an authentication code, verifying whether the mobile device is authorized to transfer data representing its location to the time prediction system; 13.2 Using a proxy server to transmit the data representing the location from the mobile device to the time prediction system; 13.3 generating an event token used to authorize requesting a predicted core presence time (7) of the recipient at the postal address (1) or geographic location from the time prediction system for this delivery event, and invalidating the event token after successful delivery of the service to the recipient at the postal address (1) or geographic location (S208); 10. The method of any of the preceding claims, further comprising:

14. 14.

1. A step of checking the actual presence of the recipient (1205) at the postal address (1) or geographical location immediately before the delivery of the service to the recipient (1205) at the postal address (1) or geographical location, said step of checking being carried out by sending a corresponding request from said entity (1105) to said time prediction system (3; 1115); 14.2 In the time prediction system, monitoring the distance between the transformed location of the mobile device and the transformed postal address (1) or transformed geographic location, determining whether the mobile device is at the transformed postal address (1) or transformed geographic location or can reach the transformed postal address (1) or transformed geographic location in time for the predicted core presence time, and updating the predicted core presence time if the mobile device is unlikely to be at the transformed postal address (1) or transformed geographic location during the predicted core presence time.

10. The method of any preceding claim, further comprising any of the steps of:

15. 1. A method for data protection compliant data enrichment, comprising the steps of: 15.1 Collecting data at collection points; 15.2 Anonymizing said data at the time of collection; 15.3 Transferring the anonymized data to a data room; 15.4 Enriching the anonymized data in the data room, 15.4.1 personalized recommendations or insights are obtained from the anonymized data by enriching the data; and 15.5 Obtaining the personalized recommendation or insight using a cryptographic key, 15.5.1 the possibility of obtaining said personalized recommendations or insights is limited in time; The method further comprises:

Images