Method and device for offline processing delivery-related data for delivery management application, and recording medium having recorded thereon instructions

Abstract

A method performed by an electronic device, according to an embodiment of the present disclosure, may comprise the steps of: in a normal mode, acquiring an incident flag indicating whether or not an incident has occurred in a server for a delivery management application; in response to the incident flag indicating that the incident has occurred in the server, switching from the normal mode to an incident mode; in the incident mode, loading delivery list data prestored within a local database of the electronic device; and in the incident mode, on the basis of the delivery list data, generating temporary application data for the delivery management application.

Description

A recording medium recording a method, device and command for processing delivery-related data for an offline delivery management application

[0001] The present disclosure relates to a technique for processing delivery-related data for an offline delivery management application.

[0002] Advances in communications and data processing technology allow delivery workers to efficiently perform delivery tasks by running delivery management applications on their terminals. Through the delivery management application, delivery workers can check their assigned delivery tasks and utilize real-time delivery maps to deliver items.

[0003] However, the proper functioning of a delivery management application relies on the stability of the server providing the relevant data. If a server failure occurs, delivery workers will be unable to use the application properly until the server is restored. This can prevent delivery workers from selecting the correct delivery route, resulting in incorrect deliveries or failure to adhere to scheduled delivery schedules. Furthermore, until the server is restored, delivery workers will not be able to properly record the deliveries they have actually completed, nor will they be able to be assigned new deliveries.

[0004] The present disclosure provides a technology for processing delivery-related data of a delivery management application offline at a delivery agent terminal even if a failure occurs in the server of the delivery management application.

[0005] In one aspect of the present disclosure, a method for processing delivery-related data for a delivery management application offline may be proposed. The method according to the present disclosure may be a method performed by an electronic device. The method according to the present disclosure may include, in a normal mode, the steps of: acquiring an incident flag indicating whether there is an incident on a server of the delivery management application; in response to the incident flag indicating that there is an incident on the server, switching from the normal mode to a failure mode; in the failure mode, loading delivery list data pre-stored in a local database of the electronic device, wherein the delivery list data may indicate a delivery list including one or more delivery items assigned to a delivery person; and in the failure mode, generating temporary application data for the delivery management application based on the delivery list data.

[0006] According to one embodiment, in the normal mode, the step of obtaining the failure flag indicating whether there is a failure in the server of the delivery management application may include the step of transmitting a request for the failure flag to a database linked with the delivery management application; and the step of receiving the failure flag from the database.

[0007] According to one embodiment, in the failure mode, the step of loading the delivery list data pre-stored in the local database of the electronic device may include the step of identifying a specific API for requesting the delivery list data among a plurality of application programming interfaces (APIs) for the delivery management application; and the step of loading the delivery list data most recently stored in the local database as a result of calling the specific API.

[0008] The method according to the present disclosure may further include, in the failure mode, a step of generating an offline page for the delivery management application based on the temporary application data, wherein the offline page may include the delivery list and a warning notification for initialization of the delivery management application; and, in the failure mode, a step of displaying the offline page on a display of the electronic device.

[0009] The method according to the present disclosure may further include, in the failure mode, a step of receiving a normalization notification of the server from the server; and, in response to receiving the normalization notification, a step of switching from the failure mode to the normal mode.

[0010] The method according to the present disclosure may further include, in the normal mode, requesting application data for the delivery management application from the server; in the normal mode, receiving the application data from the server (the application data may include a delivery list for one or more delivery target items assigned to the delivery person); in the normal mode, generating an online page for the delivery management application based on the application data; and in the normal mode, displaying the online page on a display of the electronic device.

[0011] The method according to the present disclosure may further include, in the failure mode, a step of obtaining delivery completion data indicating completion of delivery of an item to be delivered in the delivery list (the delivery completion data may include a delivery completion time of the item to be delivered and an image indicating a delivery completion status of the item to be delivered at the delivery completion time); and, in the failure mode, a step of storing the delivery completion data in the local database.

[0012] The method according to the present disclosure may further include, in response to switching from the fault mode to the normal mode, a step of transmitting, in the normal mode, delivery completion data stored in the local database to the server.

[0013] According to one embodiment, in the failure mode, the step of storing the delivery completion data in the local database may include the step of identifying a specific API among a plurality of APIs for the delivery management application for transmitting the delivery completion data to the server; and the step of storing a failure history for a call to the specific API in the local database.

[0014] The method according to the present disclosure may further include, in response to switching from the failure mode to the normal mode, a step of identifying, in the normal mode, a failure history for calling the specific API stored in the local database; and, in response to identifying the failure history for calling the specific API, a step of calling the specific API in the normal mode and transmitting the delivery completion data stored in the local database to the server.

[0015] The method according to the present disclosure may further include, in the failure mode, the step of obtaining identification data for an item not included in the delivery list; the step of obtaining temporary delivery data for the item based on the identification data, wherein the temporary delivery data includes at least one of a recipient name, an expected delivery completion time, a tracking number, a box number, or a delivery address; and the step of updating the delivery list data based on the temporary delivery data so that the item is included in the delivery list.

[0016] In one embodiment, the identification data may be one of a QR code or a two-dimensional barcode for identifying the item.

[0017] The method according to the present disclosure may further include, in the failure mode, updating the temporary application data based on the updated shipping list data; in the failure mode, generating an offline page for the shipping management application based on the updated temporary application data, the offline page including the updated shipping list including the item and a warning notification for initialization of the shipping management application; and in the failure mode, displaying the offline page on a display of the electronic device.

[0018] In one aspect of the present disclosure, an electronic device for processing delivery-related data for an offline delivery management application may be proposed. The electronic device according to the present disclosure may include one or more processors, one or more memories storing instructions to be executed by the one or more processors, and when the instructions are executed by the one or more processors, the one or more processors may be configured to execute a method according to the present disclosure.

[0019] In one aspect of the present disclosure, a non-transitory computer-readable recording medium containing instructions for processing delivery-related data for an offline delivery management application may be proposed. The instructions recorded on the non-transitory computer-readable recording medium according to the present disclosure may be configured to cause one or more processors to execute a method according to the present disclosure.

[0020] According to one embodiment of the present disclosure, even if a server failure of the delivery management application occurs, delivery-related data for the delivery management application can be processed offline at the delivery agent terminal, thereby enabling the delivery agent to perform delivery work through the delivery management application in offline mode even before the server is restored.

[0021] The effects according to the technical idea of ​​the present disclosure are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description of the specification.

[0022] FIG. 1 is a diagram illustrating a system according to one embodiment of the present disclosure.

[0023] FIG. 2 is a block diagram of a computing device according to one embodiment of the present disclosure.

[0024] FIG. 3 is a diagram illustrating a process in which a delivery terminal executes a delivery management application according to one embodiment of the present disclosure.

[0025] FIG. 4 is a diagram illustrating a process in which a delivery terminal in a failure mode switches to a normal mode according to one embodiment of the present disclosure.

[0026] FIG. 5 is a diagram illustrating mapping data indicating a mapping relationship between APIs and API paths according to one embodiment of the present disclosure.

[0027] FIG. 6 is a diagram illustrating the operation of a delivery terminal for an API mapped to an API path according to one embodiment of the present disclosure.

[0028] FIG. 7 is a diagram illustrating the operation of a delivery terminal for an API mapped to an API path according to one embodiment of the present disclosure.

[0029] FIG. 8 is a diagram illustrating the operation of a delivery terminal for an API mapped to an API path according to one embodiment of the present disclosure.

[0030] FIG. 9 is a diagram illustrating the operation of a delivery terminal for an API mapped to an API path according to one embodiment of the present disclosure.

[0031] FIG. 10 is a diagram illustrating an online page for a delivery management application according to one embodiment of the present disclosure.

[0032] FIG. 11 is a diagram illustrating an offline page for a delivery management application according to one embodiment of the present disclosure.

[0033] FIG. 12 is a diagram illustrating the operation of a delivery terminal for delivery completion data of an item to be delivered according to one embodiment of the present disclosure.

[0034] FIG. 13 is a diagram illustrating a process in which a delivery terminal in a failure mode according to one embodiment of the present disclosure scans identification data for an item to update a delivery list.

[0035] FIG. 14 is a diagram illustrating a process in which a delivery terminal in a failure mode according to one embodiment of the present disclosure scans identification data for an item and updates a delivery list.

[0036] FIG. 15 is a diagram illustrating an offline page including a delivery list updated by a delivery terminal in a failure mode according to one embodiment of the present disclosure.

[0037] FIG. 16 is a diagram illustrating a method for processing delivery-related data for an offline delivery management application according to one embodiment of the present disclosure.

[0038] The various embodiments described in this disclosure are exemplified for the purpose of clearly explaining the technical concept of this disclosure and are not intended to be limited to specific embodiments. The technical concept of this disclosure includes various modifications, equivalents, alternatives, and embodiments selectively combined from all or part of the embodiments described in this disclosure. Furthermore, the scope of the technical concept of this disclosure is not limited to the various embodiments presented below or the specific descriptions thereof.

[0039] Terms used in this disclosure, including technical or scientific terms, unless otherwise defined, may have the meaning commonly understood by a person of ordinary skill in the art to which this disclosure belongs.

[0040] In this disclosure, expressions such as "includes," "may include," "comprises," "may have," "has," and "may have" indicate the presence of a target feature (e.g., a function, operation, or component), but do not exclude the presence of other additional features. In other words, such expressions should be understood as open-ended terms that imply the possibility of including other embodiments.

[0041] In this disclosure, singular expressions may include plural meanings unless the context clearly indicates otherwise, and this also applies to singular expressions described in the claims.

[0042] In this disclosure, expressions such as “first,” “second,” or “first,” “second,” etc., unless the context indicates otherwise, are used to distinguish one object from another when referring to multiple similar objects, and do not limit the order or importance among the objects.

[0043] In this disclosure, expressions such as “A, B, and C,” “A, B, or C,” “A, B, and / or C,” or “at least one of A, B, and C,” “at least one of A, B, or C,” “at least one of A, B, and / or C,” “at least one selected from A, B, and C,” “at least one selected from A, B, or C,” “at least one selected from A, B, and / or C,” etc., can refer to each listed item or all possible combinations of the listed items. For example, “at least one selected from A and B” can refer to (1) A, (2) at least one of A, (3) B, (4) at least one of B, (5) at least one of A and at least one of B, (6) at least one of A and B, (7) at least one of B and A, and (8) both A and B.

[0044] In this disclosure, the expression “based on or according to” is used to describe one or more factors that influence a decision, act of judgment, or action described in a phrase or sentence containing the expression, and the expression does not exclude additional factors that influence the decision, act of judgment, or action.

[0045] In the present disclosure, determining B based on A means taking A into consideration in determining B, and does not exclude that other information besides A is additionally considered.

[0046] In the present disclosure, the expression that a component (e.g., a first component) is “connected” or “connected” to another component (e.g., a second component) may mean that the component is directly connected or connected to the other component, as well as connected or connected via a new other component (e.g., a third component).

[0047] In the present disclosure, “configured to” may have the meaning of “set to”, “having the ability to”, “modified to”, “made to”, “capable of”, etc., depending on the context. The expression is not limited to the meaning of “specifically designed in hardware”, and for example, a processor configured to perform a specific operation may mean a special purpose computer structured through programming to perform the specific operation.

[0048] Hereinafter, various embodiments of the present disclosure will be described with reference to the attached drawings. In the attached drawings and the description of the drawings, identical or substantially equivalent components may be assigned the same reference numerals. Furthermore, in the description of various embodiments below, duplicate descriptions of identical or corresponding components may be omitted, but this does not mean that the corresponding components are not included in the embodiments.

[0049] FIG. 1 is a drawing showing a system (100) according to one embodiment of the present disclosure.

[0050] According to one embodiment, the system (100) may include at least one of a delivery terminal (110), a server (120), or a database (130). Meanwhile, FIG. 1 merely illustrates an example of the system (100), and the present disclosure is not limited thereto. For example, other components not illustrated in FIG. 1 may also be included in the system (100).

[0051] According to one embodiment, the delivery terminal (110) may be a device possessed by the delivery person. For example, the delivery terminal (110) may be implemented as a portable terminal device such as a smartphone. However, the present disclosure is not limited thereto, and the delivery terminal (110) may take various forms. The delivery terminal (110) may also be expressed by terms having the same or similar meanings as client, client terminal, user terminal, electronic device, etc.

[0052] For example, a delivery management application may be installed on a delivery worker terminal (110), and when the delivery management application is executed, a user interface of the delivery management application may be displayed on the delivery worker terminal (110). Meanwhile, the delivery management application may be an application that can provide various user interfaces for delivery management, such as a delivery list including one or more delivery target items assigned to the delivery worker, a delivery map, etc. For example, the user interface of the delivery management application may be displayed on the display of the delivery worker terminal (110). Here, the user interface is a physical or virtual medium for interaction between the delivery worker and the delivery worker terminal (110), and the delivery worker can operate the delivery management application through the user interface of the delivery management application displayed on the delivery worker terminal (110). For example, the user interface may include basic elements for displaying specific information, such as images or text, and elements for receiving user input, such as buttons that can be configured by utilizing these basic elements. For example, the selection (click) of a user interface displayed on the display of the delivery terminal (110) by the delivery person may be expressed as the reception of an input from the delivery person corresponding to the user interface. For example, the delivery person may request data corresponding to the selected interface by selecting the user interface of the delivery management application displayed on the display of the delivery terminal (110). For example, the delivery person may request a delivery list including one or more delivery target items assigned to the delivery person by selecting the user interface for the delivery list of the delivery management application displayed on the display of the delivery terminal (110).In this case, the delivery list of the delivery person may be displayed on the display of the delivery person terminal (110) as part of the user interface of the delivery management application.

[0053] For example, the delivery terminal (110) can execute an application according to one or more operating modes. Here, the operating mode of the delivery terminal (110) can be a normal mode, a failure mode, etc. For example, the normal mode can be an online mode for the server (120). For example, the failure mode can be an offline mode for the server (120). For example, the delivery terminal (110) can operate in a normal mode or a failure mode depending on whether the server (120) is faulty. If the server (120) is not faulty, the delivery terminal (110) can execute the delivery management application in the normal mode. If the server (120) is faulty, the delivery terminal (110) can execute the delivery management application in the failure mode.

[0054] According to one embodiment, the server (120) may be a device that manages data related to a delivery management application. For example, the server (120) may transmit application data for the delivery management application to the delivery agent terminal (110). Here, the application data may be data that allows a delivery list, a delivery map, etc., including one or more delivery items assigned to a delivery agent, to be displayed as part of the user interface of the delivery management application. For example, the application data may be data that allows the delivery agent terminal (110) to display an online page including the delivery agent's delivery list, delivery map, etc. The delivery agent terminal (110) may execute the delivery management application based on the application data received from the server (120). For example, the delivery agent terminal (110) may display an online page including the delivery agent's delivery list, delivery map, etc., on the display of the delivery agent terminal (110), based on the application data received from the server (120).

[0055] In one embodiment, the database (130) may be a database linked to a delivery management application. For example, the database (130) may store data necessary for executing the delivery management application. For example, the database (130) may store a failure flag indicating whether the server (120) is faulty. The failure flag may include a first value indicating that the server (120) is faulty and a second value indicating that the server (120) is not faulty. Additionally, the failure flag may indicate the cause of the failure of the server (120) in addition to indicating that the server (120) is faulty. In this case, the failure flag may include a first value indicating that the server (120) is faulty and an error code indicating the cause of the failure of the server (120). For example, when a delivery person terminal (110) queries a database (130) for a failure flag, the database (130) may return a failure flag to the delivery person terminal (110) in response to the query. Meanwhile, the database (130) is a database linked in real time with a delivery management application, and when a change in data required by the delivery management application is detected, notification data regarding the change in data may be transmitted to the delivery person terminal (110) or the server (120). In this case, the notification data may include the changed data. For example, when a failure flag in the database (130) is changed, the database (130) may transmit notification data regarding the change in the failure flag to the delivery person terminal (110) or the server (120). In this case, the notification data may include a failure flag.

[0056] According to one embodiment, the delivery terminal (110), the server (120), or the database (130) may be independent entities. In this case, the delivery terminal (110), the server (120), or the database (130) may exchange data via a network (140) between devices. However, the present disclosure is not limited thereto. For example, at least two of the delivery terminal (110), the server (120), or the database (130) may be implemented as one or more entities. For example, the system (100) may include a device having a module (or processor) for performing the function of the delivery terminal (110) and a module (or processor) for performing the function of the server (120). In this case, the module (or processor) for performing the function of the delivery terminal (110) and the module (or processor) for performing the function of the server (120) may exchange data via a network within the device. For example, the system (100) may include a device having a module (or processor) for performing the functions of a delivery terminal (110) and a server (120). For example, a database (130) may be included as a local database within the delivery terminal (110), or cache data of the database (130) may be stored within the delivery terminal (110).

[0057] Meanwhile, although FIG. 1 illustrates that the delivery terminal (110), server (120), and database (130) are each implemented as a single device, the present disclosure is not limited thereto. For example, the delivery terminal (110) may be implemented as a system including one or more computing devices for performing the same function. For example, the server (120) may be implemented as a system including one or more computing devices for performing the same function. For example, the database (130) may be implemented as a system including one or more computing devices for performing the same function. The computing devices may refer to the description of FIG. 2.

[0058] Additionally, although FIG. 1 illustrates one delivery terminal (110), one server (120), and one database (130), the present disclosure is not limited thereto. The number of each of the delivery terminals (110), the server (120), and the database (130) may vary within the applicable scope of the embodiments of the present disclosure.

[0059] FIG. 2 is a block diagram showing a computing device (200) according to one embodiment of the present disclosure.

[0060] According to one embodiment, the delivery terminal (110), server (120), and database (130) may each be implemented as one or more computing devices (200). For convenience of explanation, the following description will focus on one computing device (200).

[0061] According to one embodiment, the computing device (200) may include one or more processors (210), one or more memories (220), or a communication interface (230). Meanwhile, some components may be deleted from the computing device (200), or other components (such as a display or input device) may be added to the computing device (200). In addition, some components may be implemented in an integrated manner or implemented as a single or multiple entities. In the present disclosure, one or more processors (210) may be referred to as a processor (210). The term “processor (210)” may mean a set of one or more processors, unless the context clearly indicates otherwise. In the present disclosure, one or more memories (220) may be referred to as a memory (220). The term “memory (220)” may mean a set of one or more memories, unless the context clearly indicates otherwise. Alternatively, in the present disclosure, the term communication interface (230) may mean a set of one or more communication circuits, unless the context clearly indicates otherwise.

[0062] According to one embodiment, the processor (210) may perform calculations or information processing related to control or communication of each component of the computing device (200). Specifically, the processor (210) may control at least one component of the computing device (200) connected to the processor (210) by executing software (or a computer program) received from another component. As an example, the processor (210) may load a command (e.g., an instruction, a code, or a code segment) or information into the memory (220), process the command or information stored in the memory (220), and store result information according to the processing in the memory (220). In addition, the processor (210) may be operatively connected to the components of the computing device (200) to perform various operations such as calculations, processing, generation, or processing related to the present disclosure.

[0063] According to one embodiment, the memory (220) can store various information. The information stored in the memory (220) is information acquired, processed, or used by at least one component of the computing device (200), and may include software. The software may include one or more instructions that, when loaded into the memory (220), cause the processor (210) to perform operations according to various embodiments of the present disclosure. That is, the processor (210) can perform operations according to various embodiments of the present disclosure by executing the one or more instructions described above. In addition, the memory (220) may implement (store) a database for recording a history related to a request for inspection of code changes. The memory (220) may include, for example, volatile or non-volatile memory.

[0064] According to one embodiment, the program is software stored in the memory (220), and may include an operating system for controlling the resources of the computing device (200), an application, or middleware for providing various functions to the application so that the application can utilize the resources of the computing device (200).

[0065] According to one embodiment, the communication interface (230) can establish a wired or wireless communication channel with another device and transmit and receive various information with the other device.

[0066] In one embodiment, the communication interface (230) may include at least one port for connecting to another device via a wired cable in order to communicate with another device via a wired connection. In this case, the communication interface (230) may communicate with another device via the wired connection through the at least one port. In one embodiment, the communication interface (230) may be configured to connect to a cellular network (e.g., 3G, LTE, 5G, Wibro, or Wimax) by including a cellular communication module. In one embodiment, the communication interface (230) may include a short-range communication module to transmit and receive information with another device using short-range communication (e.g., Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), UWB).

[0067] According to one embodiment, the communication interface (230) may include a contactless communication module for contactless communication. The contactless communication may include at least one contactless proximity communication technology, such as Near Field Communication (NFC), Radio Frequency Identification (RFID), or Magnetic Secure Transmission (MST). In addition to the various examples described above, the computing device (200) may be implemented in various known ways for communicating with other devices, and the scope of the present disclosure is not limited by the examples described above.

[0068] According to one embodiment, the computing device (200) may include a display. The display may display various screens (e.g., one or more pages) based on the control of the processor (210). For example, when the computing device (200) receives data that causes it to display a specific screen, the processor (210) may control the display to display the specific screen. In addition, in order to display screens to which various interfaces are applied on the display, for example, a web browser or a dedicated application may be installed on the computing device (200). In addition, the display may be a component that can interact with a user and may receive user input from the user. Such a display may be implemented in the form of a touch sensor panel (TSP) that can recognize the contact or proximity of various external objects (e.g., a user's finger or stylus).

[0069] In one embodiment, the computing device (200) may include an input device (e.g., a mouse or a keyboard). The input device may receive information to be used in components of the computing device (200) from an external source (e.g., a user) of the computing device (200).

[0070] According to one embodiment, the computing device (200) may include a camera. The camera can capture an object and generate an image of the object. Furthermore, the camera can recognize identification data, such as a QR code or a two-dimensional barcode, and obtain data encoded in the identification data. For example, if delivery data, including at least one of the recipient's name, expected delivery completion time, tracking number, box number, or delivery address, is encoded in the identification data of the item, the camera can obtain the delivery data of the item from the identification data of the item.

[0071] The processor (210), memory (220), and communication interface (230) illustrated in FIG. 2 are connected to each other through a bus, GPIO (General Purpose Input / Output), SPI (Serial Peripheral Interface), or MIPI (Mobile Industry Processor Interface), and can send or receive information or signals.

[0072] FIG. 3 is a diagram illustrating a process in which a delivery terminal (110) executes a delivery management application according to one embodiment of the present disclosure.

[0073] In S310, the delivery terminal (110) in normal mode can query the database (130) for a failure flag indicating whether the server (120) is in a failure state. As a detailed step of S310, the delivery terminal (110) can perform the following operations.

[0074] According to one embodiment, a delivery agent terminal (110) in normal mode may request application data for a delivery management application from a server (120). For example, the application data may be data that allows the delivery agent terminal (110) to display a delivery list, a delivery map, etc. including one or more delivery items assigned to the delivery agent as part of a user interface of the delivery management application. For example, the application data may be data that allows the delivery agent terminal (110) to display an online page including a delivery list, a delivery map, etc. of the delivery agent. Subsequently, the delivery agent terminal (110) may monitor a response from the server (120) for a predetermined period of time after requesting the application data from the server (120). In response to not receiving a response from the server (120) for the predetermined period of time, the delivery agent terminal (110) may query the database (130) for a failure flag indicating whether the server (120) is experiencing a failure, thereby determining whether a failure has occurred in the server (120).

[0075] According to one embodiment, the number of times a normal mode delivery terminal (110) can request application data for a delivery management application from a server (120) may be predetermined. For example, the delivery terminal (110) may request application data for a delivery management application from the server (120). After requesting the application data from the server (120), the delivery terminal (110) may monitor a response from the server (120) for a predetermined period of time. In response to not receiving a response from the server (120) for the predetermined period of time, the delivery terminal (110) may re-request the application data from the server (120). Next, the delivery terminal (1100) can monitor the response of the server (120) for a predetermined period of time after re-requesting application data to the server (120). In this way, if the delivery terminal (110) does not receive a response from the server (120), it can request application data from the server (120) a predetermined number of times. In response to not receiving a response from the server (120) despite requesting application data from the server (120) a predetermined number of times, the delivery terminal (110) can query the database (130) for a failure flag indicating whether the server (120) is in a failure state, thereby checking whether a failure has occurred in the server (120).

[0076] In S320, the database (130) can return a failure flag to the delivery terminal (110). That is, the delivery terminal (110) can receive the failure flag from the database (130).

[0077] In S330, the delivery terminal (110) in normal mode can determine whether to switch to failure mode based on the failure flag.

[0078] At S340, in response to the fault flag indicating that there is no fault with the server (120), the delivery terminal (110) in normal mode can maintain the normal mode. Subsequently, at S341, the delivery terminal (110) in normal mode can request application data for the delivery management application from the server (120). At S342, the delivery terminal (110) in normal mode can receive application data for the delivery management application from the server (120). The delivery terminal (110) in normal mode can execute the delivery management application based on the application data received from the server (120). For example, the delivery terminal (110) in normal mode can display a delivery list of the delivery person, a delivery map, etc. on the display of the delivery terminal (110) as part of the user interface of the delivery management application based on the application data. For example, a delivery terminal (110) in normal mode can display an online page including a delivery list of delivery personnel, a delivery map, etc. on the display of the delivery terminal (110) based on application data.

[0079] At S350, in response to the failure flag indicating that there is a failure in the server (120), the delivery terminal (110) in normal mode may switch to failure mode. Subsequently, at S351, the delivery terminal (110) in failure mode may load delivery-related data previously stored in a local database of the delivery terminal (110) and generate temporary application data for the delivery management application based on the loaded delivery data. Here, the local database of the delivery terminal (110) may be a database built in a space allocated for an application in one or more memories (220) of a computing device (200) capable of implementing the delivery terminal (110) and storing and managing data required for executing the application. For example, the delivery-related data may be delivery list data indicating a delivery list including one or more delivery items assigned to a delivery person of the delivery person terminal (110), delivery completion data indicating the completion of delivery of delivery items in the delivery person's delivery list, delivery map data indicating a delivery map in which delivery markers are displayed for the location, number, delivery time zone, etc. of delivery-related items in the delivery person's delivery list, etc. For example, the temporary application data may be data that causes the delivery person's delivery list, delivery map, etc. indicated by the delivery-related data loaded from the local database of the delivery person terminal (110) to be displayed as part of the user interface of the delivery management application. For example, the temporary application data may be data that causes the delivery person's offline page including the delivery list, delivery map, etc. of the delivery person of the delivery person terminal (110) indicated by the delivery-related data loaded from the local database of the delivery person terminal (110). The delivery person terminal (110) in a failure mode may execute the delivery management application based on the temporary application data.For example, the delivery terminal (110) in a failure mode may display a delivery list, a delivery map, etc. of the delivery person on the display of the delivery terminal (110) based on temporary application data as part of the user interface of the delivery management application. For example, the delivery terminal (110) in a failure mode may display an offline page including a delivery list, a delivery map, etc. of the delivery person on the display of the delivery terminal (110) based on temporary application data.

[0080] Meanwhile, although FIG. 3 illustrates an example in which the delivery terminal (110) checks a failure flag while operating in normal mode to maintain normal mode or switch to failure mode, the present disclosure is not limited thereto. For example, the delivery terminal (110) may check a failure flag while operating in failure mode. In response to the failure flag indicating that the server (120) is experiencing a failure, the delivery terminal (110) in failure mode may maintain failure mode and generate temporary application data to execute the delivery management application offline. Alternatively, in response to the failure flag indicating that the server (120) is not experiencing a failure, the delivery terminal (110) in failure mode may switch to normal mode, request application data from the server (120), and receive the application data from the server (120) to execute the delivery management application online.

[0081] FIG. 4 is a drawing showing a process in which a delivery terminal (110) in a failure mode according to one embodiment of the present disclosure switches to a normal mode.

[0082] In S410, the delivery terminal (110) in the failure mode can receive a normalization notification of the server (120) from the server (120).

[0083] In S420, in response to receiving a normalization notification from the server (120), the delivery terminal (110) in the failure mode can switch to the normal mode. Subsequently, the delivery terminal (110) in the normal mode can request application data from the server (120), receive the application data from the server (120), and execute the delivery management application online.

[0084] As described in FIG. 3, the delivery terminal (110) can check whether the server (120) is faulty based on the fault flag stored in the database (130), or as described in FIG. 4, can check whether the server (120) is faulty by directly receiving a normalization notification from the server (120).

[0085] FIG. 5 is a diagram illustrating mapping data (500) indicating a mapping relationship between APIs (511, 512, 513, 514) and API paths (551, 552, 553, 554) according to one embodiment of the present disclosure.

[0086] According to one embodiment, the delivery terminal (110) can call at least some APIs within the API set (510) for the delivery management application and execute the delivery management application based on the call result of the API. Meanwhile, the delivery terminal (110) in normal mode can call an API requesting data from the server (120) and normally receive the call result for the corresponding API from the server (120), whereas the delivery terminal (110) in failure mode cannot normally receive the call result for the corresponding API from the server (120) even if it calls an API requesting data from the server (120) that has a failure. In addition, the delivery terminal (110) in normal mode can call an API that transmits data to the server (120) and receive a response (e.g., ACK) indicating that the server (120) has received the data as a result of the call to the API, whereas the delivery terminal (110) in fault mode cannot receive a response (e.g., ACK) indicating that the server (120) has received the data as a result of the call to the API even if it calls an API that transmits data to the faulty server (120), and this may lead to a problem in which data transmission to the server (120) is omitted. In order to solve this problem, it may be necessary to define an operation that the delivery terminal (110) in normal mode must perform and an operation that the delivery terminal (110) in fault mode must perform for the API.

[0087] According to one embodiment, at least some APIs in the API set (510) may be mapped to at least some API paths in the API path set (550). Accordingly, each API may be mapped to a unique API path. The API path may instruct the operation that the delivery terminal (110) in normal mode should perform and the operation that the delivery terminal (110) in fault mode should perform for the API mapped thereto. Referring to the example of FIG. 5, API 1 (511) may be mapped to API path 1 (551), API 2 (512) to API path 2 (552), API 3 (513) to API path 3 (553), and API 4 (514) to API path 4 (554). API path 1 (551) may instruct the operation that the delivery terminal (110) in normal mode should perform and the operation that the delivery terminal (110) in fault mode should perform for API 1 (511). API path 2 (552) may instruct API 2 (512) on an operation that a delivery terminal (110) in normal mode should perform and an operation that a delivery terminal (110) in fault mode should perform. API path 3 (553) may instruct API 3 (513) on an operation that a delivery terminal (110) in normal mode should perform and an operation that a delivery terminal (110) in fault mode should perform. API path 4 (554) may instruct API 4 (514) on an operation that a delivery terminal (110) in normal mode should perform and an operation that a delivery terminal (110) in fault mode should perform. Meanwhile, although FIG. 5 illustrates four APIs (511, 512, 513, 514) within an API set (510) and four API paths (551, 552, 553, 554) within an API path set (550), the present disclosure is not limited thereto. The number of each API and API path having a mapping relationship may vary within the applicable scope of the embodiments of the present disclosure.

[0088] According to one embodiment, each API path may be assigned a type. For example, the type of the API path may be any one of "save response", which stores the API call result in the local database of the delivery terminal (110), "dummy", which replaces the API call result with other predetermined data, "ignore", which ignores the API call result, and "recover", which stores the failure history in the local database of the delivery terminal (110) and re-requests the API when the API call fails.

[0089] According to one embodiment, the mapping data (500) may indicate a mapping relationship between APIs (511, 512, 513, 514) and API paths (551, 552, 553, 554), types of API paths, etc. For example, the delivery terminal (110) may receive the mapping data (500) from the server (120) and perform an operation for the API based on the mapping data (500) and the operation mode of the delivery terminal (110). Alternatively, the delivery terminal (110) may query the database (130) for the mapping data (500), obtain the mapping data (500) from the database (130), and perform an operation for the API based on the mapping data (500) and the operation mode of the delivery terminal (110).

[0090] FIG. 6 is a diagram illustrating the operation of a delivery terminal (110) for an API mapped to an API path according to one embodiment of the present disclosure. Hereinafter, the type of API path 1 (551) mapped to API 1 (511) is assumed to be "response storage."

[0091] According to one embodiment, for API 1 (511) mapped to API path 1 (551), the operation to be performed by the delivery terminal (110) in normal mode and the operation to be performed by the delivery terminal (110) in fault mode may be different.

[0092] For example, when the operation mode of the delivery terminal (110) is normal mode, the delivery terminal (110) in normal mode can perform the following operations for API 1 (511). At S610, the delivery terminal (110) in normal mode can call API 1 (511). For example, the delivery terminal (110) in normal mode can request data related to API 1 (511) from the server (120) by calling API 1 (511). At S620, the delivery terminal (110) in normal mode can receive a response (call result) to the call of API 1 (511) from the server (120). For example, the delivery terminal (110) in normal mode can receive data related to API 1 (511) from the server (120) as a response to the call of API 1 (511). In S630, the delivery terminal (110) in normal mode can store a response to a call of API 1 (511). For example, the delivery terminal (110) in normal mode can store a response to a call of API 1 (511) in a local database of the delivery terminal (110). Here, if the past call results of API 1 (511) are stored in the local database of the delivery terminal (110), the delivery terminal (110) in normal mode can overwrite the past call results with the new call results of API 1 (511), or can maintain the past call results without deleting them and additionally store the new call results in the local database.

[0093] For example, if the operation mode of the delivery terminal (110) is a failure mode, the delivery terminal (110) in the failure mode can perform the following operations for API 1 (511). In S640, the delivery terminal (110) in the failure mode can load the call result of API 1 (511) that is most recently stored in the local database of the delivery terminal (110) instead of calling API 1 (511) to request data related to API 1 (511) from the server (120). That is, for API 1 (511) mapped to API path 1 (551) of the "response storage" type, the normal mode delivery terminal (110) stores the call result of API 1 (511) in the local database of the delivery terminal (110), so that even if the normal mode delivery terminal (110) switches to failure mode, the delivery management application can be executed based on the call result of API 1 (511) stored in the local database.

[0094] In one embodiment, API 1 (511) may be an API that requests delivery list data for a delivery list including one or more delivery target items assigned to a delivery person on a delivery person terminal (110). For example, a delivery person may request a delivery list including one or more delivery target items assigned to the delivery person by selecting a user interface for the delivery list of a delivery management application displayed on the display of the delivery person terminal (110).

[0095] For example, when the operation mode of the delivery person terminal (110) is the normal mode, the delivery person terminal (110) in the normal mode can perform the following operations in response to API 1 (511) requesting the delivery list data. At S610, in response to the delivery person's request for the delivery list, the delivery person terminal (110) in the normal mode can call API 1 (511) to request the delivery person's delivery list data from the server (120). Subsequently, at S620, the delivery person terminal (110) in the normal mode can receive application data including the delivery person's delivery list data from the server (120) in response to the call of API 1 (511). The delivery person terminal (110) in the normal mode can generate an online page including the delivery person's delivery list indicated by the delivery list data in the corresponding application data based on the application data received from the server (120), and display the online page on the display of the delivery person terminal (110). Additionally, in S630, the normal mode delivery terminal (110) can store the delivery list data of the delivery person received from the server (120) in response to a call of API 1 (511) in the local database of the delivery terminal (110).

[0096] For example, when the operation mode of the delivery person terminal (110) is a failure mode, the delivery person terminal (110) in the failure mode can perform the following operations for API 1 (511) requesting the delivery list data. In S640, in response to the delivery person's request for the delivery person's delivery list, the delivery person terminal (110) in the failure mode can load the delivery person's delivery list data that was most recently stored in the local database of the delivery person terminal (110) as a result of the call to API 1 (511) instead of requesting the delivery person's delivery list data from the server (120) by calling API 1 (511). The delivery person terminal (110) in the failure mode can generate temporary application data based on the delivery person's delivery list data loaded from the local database. Subsequently, the delivery person terminal (110) in the failure mode can generate an offline page including the delivery person's delivery list indicated by the delivery list data in the temporary application data based on the temporary application data, and display the offline page on the display of the delivery person terminal (110).

[0097] FIG. 7 is a diagram illustrating the operation of a delivery terminal (110) for an API mapped to an API path according to one embodiment of the present disclosure. Hereinafter, the type of API path 2 (552) mapped to API 2 (512) is assumed to be a "dummy" and will be described.

[0098] According to one embodiment, for API 2 (512) mapped to API path 2 (552), the operations to be performed by the delivery terminal (110) in normal mode and the operations to be performed by the delivery terminal (110) in fault mode may be different.

[0099] For example, when the operation mode of the delivery terminal (110) is the normal mode, the delivery terminal (110) in the normal mode can perform the following operations for API 2 (512). At S710, the delivery terminal (110) in the normal mode can call API 2 (512). For example, the delivery terminal (110) in the normal mode can request data related to API 2 (512) from the server (120) by calling API 2 (512). At S720, the delivery terminal (110) in the normal mode can receive a response to the call of API 2 (512) from the server (120). For example, the delivery terminal (110) in the normal mode can receive data related to API 2 (512) from the server (120) as a response to the call of API 2 (512).

[0100] For example, when the operation mode of the delivery terminal (110) is a failure mode, the delivery terminal (110) in the failure mode can perform the following operations for API 2 (512). At S730, the delivery terminal (110) in the failure mode can load predetermined replacement data to replace the call result of API 2 (512) within the local database of the delivery terminal (110) instead of calling API 2 (512) to request data related to API 2 (512) from the server (120). Alternatively, at S730, the delivery terminal (110) in the failure mode can generate replacement data to replace the call result of API 2 (512) instead of calling API 2 (512) to request data related to API 2 (512) from the server (120). Here, the replacement data that replaces the call result of API 2 (512) may include one or more data values ​​that constitute an image or text, etc. displayed as a user interface of the delivery management application within a portion of the offline page for the delivery management application. Accordingly, an image or text, etc. according to the replacement data may be displayed within a portion of the offline page displayed on the display of the delivery terminal (110) in failure mode.

[0101] FIG. 8 is a diagram illustrating the operation of a delivery terminal (110) for an API mapped to an API path according to one embodiment of the present disclosure. Hereinafter, the type of API path 3 (553) mapped to API 3 (513) is assumed to be "ignore."

[0102] According to one embodiment, for API 3 (513) mapped to API path 3 (553), the operation to be performed by the delivery terminal (110) in normal mode and the operation to be performed by the delivery terminal (110) in fault mode may be different.

[0103] For example, when the operation mode of the delivery terminal (110) is normal mode, the delivery terminal (110) in normal mode can perform the following operations for API 3 (513). At S810, the delivery terminal (110) in normal mode can call API 3 (513). For example, the delivery terminal (110) in normal mode can request data related to API 3 (513) from the server (120) by calling API 3 (513). At S820, the delivery terminal (110) in normal mode can receive a response to the call to API 3 (513) from the server (120). For example, the delivery terminal (110) in normal mode can receive data related to API 3 (513) from the server (120) as a response to the call to API 3 (513).

[0104] For example, if the operation mode of the delivery terminal (110) is a failure mode, the delivery terminal (110) in the failure mode for API 3 (513) may skip the operation related to API 3 (513). That is, the delivery terminal (110) in the failure mode for API 3 (513) may not perform any operation. For example, data related to API 3 (513) may not be essential data for the execution of the delivery management application.

[0105] FIG. 9 is a diagram illustrating the operation of a delivery terminal (110) for an API mapped to an API path according to one embodiment of the present disclosure. Hereinafter, the type of API path 4 (554) mapped to API 4 (514) is assumed to be "recovery."

[0106] According to one embodiment, for API 4 (514) mapped to API path 4 (554), the operations to be performed by the delivery terminal (110) in normal mode and the operations to be performed by the delivery terminal (110) in fault mode may be different.

[0107] For example, when the operation mode of the delivery terminal (110) is the normal mode, the delivery terminal (110) in the normal mode can perform the following operations for API 4 (514). At S910, the delivery terminal (110) in the normal mode can call API 4 (514). For example, by calling API 4 (514), the delivery terminal (110) in the normal mode can transmit data related to API 4 (514) to the server (120). At S920, the delivery terminal (110) in the normal mode can receive a response to the call of API 4 (514) from the server (120). For example, the delivery terminal (110) in the normal mode can receive a response (e.g., ACK) indicating that the server (120) has received data related to API 4 (514) as a response to the call of API 4 (514).

[0108] For example, when the operation mode of the delivery terminal (110) is a failure mode, the delivery terminal (110) in the failure mode can perform the following operations for API 4 (514). In S930, the delivery terminal (110) in the failure mode can call API 4 (514). For example, the delivery terminal (110) in the failure mode can transmit data related to API 4 (514) to the server (120) by calling API 4 (514). Meanwhile, the delivery terminal (110) in the failure mode may call API 4 (514) but may not actually transmit data related to API 4 (514) to the server (120). The delivery terminal (110) in the failure mode may not receive a response to the call of API 4 (514) from the server (120) because the server (120) is in a failure state. Next, in S940, the delivery terminal (110) in the failure mode may determine that the call to API 4 (514) has failed based on not receiving a response to the call to API 4 (514), and may store a failure history for the call to API 4 (514). Here, the failure history for the call to API 4 (514) may include the call time of API 4 (514), data related to API 4 (514), etc. For example, the delivery terminal (110) in the failure mode may store the failure history for the call to API 4 (514) in a local database of the delivery terminal (110). Alternatively, since it is unlikely that the server (120) will normally receive data related to API 4 (514) when there is a failure in the server (120), the delivery terminal (110) in failure mode may store data related to API 4 (514) directly without calling API 4 (514) in S930. For example, the delivery terminal (110) in failure mode may store data related to API 4 (514) directly in the local database of the delivery terminal (110) without calling API 4 (514).

[0109] For example, when the operation mode of the delivery terminal (110) switches from a failure mode to a normal mode, the delivery terminal (110) in the normal mode can perform the following operations for API 4 (514). The delivery terminal (110) that switches from the failure mode to the normal mode can determine whether a failure history for calling API 4 (514) is stored in the local database of the delivery terminal (110). In response to determining that a failure history for calling API 4 (514) is stored in the local database of the delivery terminal (110), the delivery terminal (110) in the normal mode can re-call API 4 (514) at S950. For example, the delivery terminal (110) in the normal mode can transmit data related to API 4 (514) to the server (120) by re-calling API 4 (514). Next, at S960, the normal mode delivery terminal (110) can receive a response to the re-call of API 4 (514) from the server (120). For example, the normal mode delivery terminal (110) can receive a response (e.g., ACK) indicating that the server (120) has received data related to API 4 (514) as a response to the re-call of API 4 (514).

[0110] According to one embodiment, API 4 (514) may be an API that transmits delivery completion data indicating the completion of delivery of an item to be delivered in the delivery list of the delivery person terminal (110). For example, the delivery completion data may include the delivery completion time of the item to be delivered and an image indicating the delivery completion status of the item to be delivered at the delivery completion time. Here, the delivery completion status may indicate the location of the item to be delivered (e.g., in front of the door), surrounding objects that serve as a reference for identifying the location of the item to be delivered, etc. For example, after the delivery person completes delivery of an item to be delivered in the delivery list, the delivery person may take a picture of the delivery completion status of the item to be delivered using the camera of the delivery person terminal (110). Subsequently, the delivery person may request the completion of delivery of the item to be delivered by selecting a user interface for the delivery completion processing of the item to be delivered in the delivery list of the delivery management application displayed on the display of the delivery person terminal (110).

[0111] For example, when the operation mode of the delivery terminal (110) is the normal mode, the delivery terminal (110) in the normal mode can perform the following operations with respect to API 4 (514) that transmits delivery completion data. At S910, in response to the delivery terminal's request for delivery completion processing of the delivery target item, the delivery terminal (110) in the normal mode can call API 4 (514) to transmit the delivery completion data of the delivery target item to the server (120). Subsequently, at S920, the delivery terminal (110) in the normal mode can receive a response (e.g., ACK) from the server (120) indicating that the server (120) has received the delivery completion data of the delivery target item as a response to the call of API 4 (514). Accordingly, the server (120) can transmit an image indicating the delivery completion status of the delivery target item included in the delivery completion data of the delivery target item to the terminal held by the recipient of the delivery target item.

[0112] For example, when the operation mode of the delivery terminal (110) is a failure mode, the delivery terminal (110) in the failure mode may perform the following operations with respect to API 4 (514) that transmits delivery completion data. In S930, in response to the delivery terminal's request for delivery completion processing of the delivery target item, the delivery terminal (110) in the failure mode may call API 4 (514) to transmit the delivery completion data of the delivery target item to the server (120). Meanwhile, the delivery terminal (110) in the failure mode may call API 4 (514) in response to the delivery terminal's request for delivery completion processing of the delivery target item, but may not actually transmit the delivery completion data of the delivery target item to the server (120). The delivery terminal (110) in the failure mode may not receive a response (e.g., ACK) indicating that the server (120) has received the delivery completion data of the delivery target item from the server (120) because the server (120) is in a failure state. Next, at S940, the delivery terminal (110) in the failure mode may determine that the call to API 4 (514) has failed based on the fact that the server (120) has not received a response (e.g., ACK) indicating that the delivery completion data of the item to be delivered has been received, and may store a failure history for the call to API 4 (514). Here, the failure history for the call to API 4 (514) may include the call time of API 4 (514), delivery completion data of the item to be delivered, etc. For example, the delivery terminal (110) in the failure mode may store the failure history for the call to API 4 (514) in the local database of the delivery terminal (110). Alternatively, the delivery terminal (110) in the failure mode may store the delivery completion data immediately without calling API 4 (514) that transmits the delivery completion data at S930.For example, a delivery terminal (110) in a failure mode can store delivery completion data in a local database of the delivery terminal (110) directly without calling API 4 (514) that transmits delivery completion data.

[0113] For example, when the operation mode of the delivery terminal (110) switches from failure mode to normal mode, the delivery terminal (110) in normal mode can perform the following operations for API 4 (514) that transmits delivery completion data. The delivery terminal (110) that switches from failure mode to normal mode can determine whether a failure history for a call to API 4 (514) is stored in the local database of the delivery terminal (110). That is, the delivery terminal (110) in normal mode can identify a failure history for a call to API 4 (514) in the local database of the delivery terminal (110). In response to determining that a failure history for calling API 4 (514) is stored in the local database of the delivery person terminal (110), at S950, the normal mode delivery person terminal (110) may re-call API 4 (514) to transmit delivery completion data of the item to be delivered to the server (120) based on the failure history for calling API 4 (514). Subsequently, at S960, the normal mode delivery person terminal (110) may receive, as a response to the re-call of API 4 (514), a response (e.g., ACK) from the server (120) indicating that the server (120) has received the delivery completion data of the item to be delivered. This allows the delivery person to automatically re-transmit the delivery completion data that was not normally transmitted due to a failure in the server (120) after the server (120) is restored, thereby eliminating the need for the delivery person to separately request delivery completion processing and preventing delivery completion processing from being omitted.

[0114] FIG. 10 is a diagram illustrating an online page (1000) for a delivery management application according to one embodiment of the present disclosure.

[0115] According to one embodiment, a normal mode delivery terminal (110) may receive application data for a delivery management application from a server (120). Based on the received application data, the normal mode delivery terminal (110) may generate an online page (1000) for the delivery management application. Subsequently, the normal mode delivery terminal (110) may display the online page (1000) on the display of the delivery terminal (110).

[0116] According to one embodiment, the online page (1000) may include a delivery list for one or more delivery items assigned to a delivery person of the delivery person terminal (110). The online page (1000) may include the recipient name, delivery type, expected delivery completion time, tracking number, box number, delivery address, delivery request, delivery notes, etc. for each delivery item in the delivery person's delivery list. Here, the delivery type may be any one of same-day delivery, next-day early morning delivery, next-day delivery, and two-day delivery. The delivery request may instruct the delivery person to perform essential actions when delivering the delivery item. For example, the delivery request may instruct the delivery person to place the item at a delivery location (e.g., in front of the door, indoors) set by the recipient within the space corresponding to the delivery address. The delivery note may instruct the delivery person to prohibit ringing the bell when delivering the delivery item, whether a pet is allowed within the space corresponding to the delivery address, etc.

[0117] FIG. 11 is a diagram illustrating an offline page (1100) for a delivery management application according to one embodiment of the present disclosure.

[0118] According to one embodiment, the delivery terminal (110) in failure mode can load the delivery data of the delivery person pre-stored in the local database of the delivery terminal (110) and generate temporary application data for the delivery management application based on the loaded delivery data. The delivery terminal (110) in failure mode can generate an offline page (1100) for the delivery management application based on the generated temporary application data. Subsequently, the delivery terminal (110) in failure mode can display the offline page (1100) on the display of the delivery terminal (110).

[0119] According to one embodiment, the offline page (1100) may include a delivery list for one or more delivery items assigned to a delivery person of the delivery person terminal (110). The offline page (1100) may include the recipient name, delivery type, expected delivery completion time, waybill number, box number, delivery address, delivery request, delivery notes, etc. for each delivery person item in the delivery person's delivery list. Additionally, the offline page (1100) may include a warning notification (1110) regarding deletion (e.g., reinstallation) or initialization (e.g., cache deletion) of the delivery management application. Delivery-related data and processing history processed by the delivery person terminal (110) in failure mode may be stored in a local database of the terminal. After the delivery person terminal (110) switches to normal mode, the delivery-related data processed during the failure mode and its processing history may be transmitted to the server (120), thereby synchronizing the actual delivery status with the delivery status in the delivery management system managed by the server (120). However, if the local database of the delivery agent terminal (110) is deleted or initialized, this synchronization may become impossible. Therefore, a warning notification (1110) regarding the deletion or initialization of the delivery management application can be included in the offline page (1100) to prevent the delivery agent from deleting or initializing the application.

[0120] FIG. 12 is a diagram illustrating the operation of a delivery terminal (110) for delivery completion data of an item to be delivered according to one embodiment of the present disclosure.

[0121] According to one embodiment, after a delivery person completes delivery of an item in a delivery list, the delivery person may use the camera of the delivery person terminal (110) to capture the delivery completion status of the item. The camera of the delivery person terminal (110) may generate an image indicating the delivery completion status of the item. The delivery person terminal (110) may generate delivery completion data including the delivery completion time of the item and the image indicating the delivery completion status of the item. Subsequently, the delivery person may request delivery completion processing of the item by selecting a user interface for delivery completion processing of the item in the delivery list of the delivery management application displayed on the display of the delivery person terminal (110). The delivery person terminal (110) in failure mode may call an API that transmits delivery completion data of the item in response to the delivery person's request for delivery completion processing of the item. Here, the API that transmits delivery completion data may refer to the description of API 4 (514) mapped to API path 4 (554) of FIG. 9. However, due to a failure of the server (120), the delivery terminal (110) in failure mode may fail to call the API for transmitting the delivery completion data of the item to be delivered. In response to the failure of the call to the API for transmitting the delivery completion data of the item to be delivered, the delivery terminal (110) in failure mode may store the delivery completion data of the item to be delivered in the queue (1200). Alternatively, the delivery terminal (110) in failure mode may store the delivery completion data of the item to be delivered directly in the queue (1200) without calling the API for transmitting the delivery completion data of the item to be delivered. Here, the queue (1200) may be a space allocated for temporarily storing the delivery completion data.For example, the queue (1200) may be a storage space allocated to temporarily store delivery completion data in the local database of the delivery person terminal (110). Alternatively, the queue (1200) may be a storage space separate from the local database of the delivery person terminal (110). When the failure of the server (120) is recovered and the delivery person terminal (110) returns to normal mode, the delivery person terminal (110) may (re)call the API that transmits the delivery completion data stored in the queue (1200), thereby transmitting the delivery completion data stored in the queue (1200) to the server (120) while the delivery person terminal (110) is operating in failure mode.

[0122] Hereinafter, the operation of the delivery terminal (110) for delivery completion data (1201, 1202, 1203, 1204, 1205) of items to be delivered will be described with reference to the example of FIG. 12 . While FIG. 12 illustrates five different delivery completion data (1201, 1202, 1203, 1204, 1205), the present disclosure is not limited thereto. The number of delivery completion data may vary as much as desired within the applicable scope of the embodiments of the present disclosure.

[0123] According to one embodiment, after a delivery person completes delivery of item 1 in a delivery list, the delivery person may use a camera of the delivery person terminal (110) to capture a delivery completion status of item 1 in a delivery list. The camera of the delivery person terminal (110) may generate an image representing the delivery completion status of item 1 in a delivery list. The delivery person terminal (110) may generate delivery completion data 1 (1201) including the delivery completion time of item 1 in a delivery list and an image representing the delivery completion status of item 1 in a delivery management application displayed on the display of the delivery person terminal (110), thereby requesting delivery completion processing of item 1 in a delivery list. The delivery person terminal (110) in a failure mode may, in response to the delivery person's request for delivery completion processing of item 1 in a delivery list, call an API that transmits delivery completion data 1 (1201). Next, the delivery terminal (110) in the failure mode may store the delivery completion data 1 (1201) in the queue (1200) in response to a failure in calling the API for transmitting the delivery completion data 1 (1201). Alternatively, the delivery terminal (110) in the failure mode may store the delivery completion data 1 (1201) in the queue (1200) directly without calling the API for transmitting the delivery completion data 1 (1201).

[0124] According to one embodiment, after the delivery person completes delivery of the delivery target item 2 in the delivery list, the delivery person may use the camera of the delivery person terminal (110) to take a picture of the delivery completion status of the delivery target item 2. The camera of the delivery person terminal (110) may generate an image indicating the delivery completion status of the delivery target item 2. The delivery person terminal (110) may generate delivery completion data 2 (1202) including the delivery completion time of the delivery target item 2 and the image indicating the delivery completion status of the delivery target item 2. Subsequently, the delivery person may request delivery completion processing of the delivery target item 2 by selecting a user interface for delivery completion processing of the delivery target item 2 in the delivery list of the delivery management application displayed on the display of the delivery person terminal (110). The delivery person terminal (110) in failure mode may call an API that transmits delivery completion data 2 (1202) in response to the delivery person's request for delivery completion processing of the delivery target item 2. Next, the delivery terminal (110) in the failure mode may store the delivery completion data 2 (1202) in the queue (1200) in response to a failure in calling the API for transmitting the delivery completion data 2 (1202). Alternatively, the delivery terminal (110) in the failure mode may store the delivery completion data 2 (1202) in the queue (1200) directly without calling the API for transmitting the delivery completion data 2 (1202). For example, the delivery completion data 2 (1202) may be stored in the queue (1200) in the following order: delivery completion data 1 (1201).

[0125] According to one embodiment, after a delivery person completes delivery of item 3 in the delivery list, the delivery person may use the camera of the delivery person terminal (110) to capture the delivery completion status of item 3. The camera of the delivery person terminal (110) may generate an image representing the delivery completion status of item 3. The delivery person terminal (110) may generate delivery completion data 3 (1203) including the delivery completion time of item 3 and the image representing the delivery completion status of item 3. Subsequently, the delivery person may request delivery completion processing of item 3 by selecting a user interface for delivery completion processing of item 3 in the delivery list of the delivery management application displayed on the display of the delivery person terminal (110). The delivery person terminal (110) in failure mode may, in response to the delivery person's request for delivery completion processing of item 3 in the delivery list, call an API that transmits delivery completion data 3 (1203). Next, the delivery terminal (110) in the failure mode may store the delivery completion data 3 (1203) in the queue (1200) in response to a failure in calling the API for transmitting the delivery completion data 3 (1203). Alternatively, the delivery terminal (110) in the failure mode may store the delivery completion data 3 (1203) in the queue (1200) directly without calling the API for transmitting the delivery completion data 3 (1203). For example, the delivery completion data 3 (1203) may be stored in the queue (1200) in the following order: delivery completion data 2 (1202).

[0126] According to one embodiment, after a delivery person completes delivery of an item 4 to be delivered in the delivery list, the delivery person may use the camera of the delivery person terminal (110) to capture a delivery completion status of the item 4 to be delivered. The camera of the delivery person terminal (110) may generate an image representing the delivery completion status of the item 4 to be delivered. The delivery person terminal (110) may generate delivery completion data 4 (1204) including the delivery completion time of the item 4 to be delivered and the image representing the delivery completion status of the item 4 to be delivered. Subsequently, the delivery person may request delivery completion processing of the item 4 to be delivered by selecting a user interface for delivery completion processing of the item 4 to be delivered in the delivery list of the delivery management application displayed on the display of the delivery person terminal (110). The delivery person terminal (110) in a failure mode may call an API that transmits delivery completion data 4 (1204) in response to the delivery person's request for delivery completion processing of the item 4 to be delivered. Next, the delivery terminal (110) in the failure mode may store the delivery completion data 4 (1204) in the queue (1200) in response to a failure in calling the API for transmitting the delivery completion data 4 (1204). Alternatively, the delivery terminal (110) in the failure mode may store the delivery completion data 4 (1204) in the queue (1200) directly without calling the API for transmitting the delivery completion data 4 (1204). For example, the delivery completion data 4 (1204) may be stored in the queue (1200) in the following order: delivery completion data 3 (1203).

[0127] According to one embodiment, after a delivery person completes delivery of an item 5 to be delivered in a delivery list, the delivery person may use a camera of the delivery person terminal (110) to capture a delivery completion status of the item 5 to be delivered. The camera of the delivery person terminal (110) may generate an image representing the delivery completion status of the item 5 to be delivered. The delivery person terminal (110) may generate delivery completion data 5 (1205) including the delivery completion time of the item 5 to be delivered and the image representing the delivery completion status of the item 5 to be delivered. Subsequently, the delivery person may request delivery completion processing of the item 5 to be delivered by selecting a user interface for delivery completion processing of the item 5 to be delivered in a delivery list of a delivery management application displayed on the display of the delivery person terminal (110). The delivery person terminal (110) in a failure mode may, in response to the delivery person's request for delivery completion processing of the item 5 to be delivered, call an API that transmits delivery completion data 5 (1205). Next, the delivery terminal (110) in the failure mode may store the delivery completion data 5 (1205) in the queue (1200) in response to a failure in calling the API for transmitting the delivery completion data 5 (1205). Alternatively, the delivery terminal (110) in the failure mode may store the delivery completion data 5 (1205) in the queue (1200) directly without calling the API for transmitting the delivery completion data 5 (1205). For example, the delivery completion data 5 (1205) may be stored in the queue (1200) in the following order: delivery completion data 4 (1204).

[0128] In one embodiment, a delivery terminal (110) in a failure mode may switch to a normal mode. For example, a delivery terminal (110) in a failure mode may switch to a normal mode in response to a failure flag acquired from a database (130) indicating that there is no failure in the server (120). Alternatively, a delivery terminal (110) in a failure mode may switch to a normal mode in response to receiving a normalization notification from the server (120). A delivery terminal (110) in a normal mode may perform the following operations to transmit delivery completion data (1201, 1202, 1203, 1204, 1205) stored in a queue (1200) to the server (120).

[0129] For example, a delivery terminal (110) in normal mode can call an API that sequentially transmits delivery completion data (1201, 1202, 1203, 1204, 1205) in the order in which they were first stored in the queue (1200). That is, a delivery terminal (110) in normal mode can sequentially call an API that transmits delivery completion data 1 (1201), an API that transmits delivery completion data 2 (1202), an API that transmits delivery completion data 3 (1203), an API that transmits delivery completion data 4 (1204), and an API that transmits delivery completion data 5 (1205) in the order in which they were stored in the queue (1200).

[0130] Alternatively, for example, the delivery terminal (110) in normal mode may preferentially call an API for transmitting delivery completion data having a smaller data size among the delivery completion data (1201, 1202, 1203, 1204, 1205) stored in the queue (1200). Here, the data size may be the length of the bits constituting the image included in the delivery completion data. For example, if the data size of delivery completion data 4 (1204) stored in the queue (1200) is smaller than the data size of delivery completion data 1 (1201), the delivery terminal (110) in normal mode may call the API for transmitting delivery completion data 4 (1204) before the API for transmitting delivery completion data 1 (1201). When the server (120) recovers from a failure, many delivery terminals (110) may transmit data to the server (120), which may cause data to be concentrated in the server (120). At this time, by transmitting data with a smaller data size to the server (120) first, it is possible to prevent the server (120) from being overloaded.

[0131] For example, the delivery terminal (110) in normal mode can preferentially call an API that transmits delivery completion data including an image indicating the delivery completion status of an item belonging to a specific product category among the delivery completion data (1201, 1202, 1203, 1204, 1205) stored in the queue (1200). For example, if the delivery completion data including an image indicating the delivery completion status of an item belonging to a specific product category among the delivery completion data (1201, 1202, 1203, 1204, 1205) stored in the queue (1200) is delivery completion data 3 (1203), the delivery terminal (110) in normal mode can first call an API that transmits delivery completion data 3 (1203).

[0132] For example, the delivery terminal (110) in normal mode can preferentially call an API that transmits delivery completion data including an image indicating the delivery completion status of a fresh product among the delivery completion data (1201, 1202, 1203, 1204, 1205) stored in the queue (1200). For example, if the delivery completion data including an image indicating the delivery completion status of a fresh product among the delivery completion data (1201, 1202, 1203, 1204, 1205) stored in the queue (1200) is delivery completion data 5 (1205), the delivery terminal (110) in normal mode can first call an API that transmits delivery completion data 5 (1205). Due to the nature of fresh products that are easily damaged, it is necessary for the recipient to quickly collect the delivered fresh products. To this end, delivery completion data including an image indicating the delivery completion status of a fresh product may be transmitted to the server (120) with priority, and the server (120) may be enabled to quickly provide the delivery completion status of a fresh product to the recipient's terminal.

[0133] For example, the delivery terminal (110) in normal mode may preferentially call an API that transmits delivery completion data including an image indicating the delivery completion status of an item delivered according to a specific delivery type among the delivery completion data (1201, 1202, 1203, 1204, 1205) stored in the queue (1200). Here, the specific delivery type may be next-day early morning delivery. For example, if the delivery completion data including an image indicating the delivery completion status of an item delivered according to a specific delivery type among the delivery completion data (1201, 1202, 1203, 1204, 1205) stored in the queue (1200) is delivery completion data 2 (1202), the delivery terminal (110) in normal mode may first call an API that transmits delivery completion data 2 (1202).

[0134] Meanwhile, in the above-described example, the normal mode delivery terminal (110) individually transmits the delivery completion data (1201, 1202, 1203, 1204, 1205) stored in the queue (1200) to the server (120), but the present disclosure is not necessarily limited thereto. For example, the normal mode delivery terminal (110) may include all the delivery completion data (1201, 1202, 1203, 1204, 1205) stored in the queue (1200) in a predetermined data container and transmit this data container to the server (120), thereby simultaneously transmitting all the delivery completion data (1201, 1202, 1203, 1204, 1205) stored in the queue (1200).

[0135] FIG. 13 is a diagram illustrating a process in which a delivery terminal (110) in a failure mode according to one embodiment of the present disclosure scans identification data (1320) for an item (1310) to update a delivery list (1300).

[0136] According to one embodiment, an item (1310) that is not included in the delivery list of the delivery person terminal (110) may have identification data (1320). For example, the identification data (1320) may be attached (printed) to a portion of the item (1310) as a QR code or a two-dimensional barcode to identify the item (1310). Alternatively, the identification data (1320) may be attached (printed) to a portion of the packaging material (box) of the item (1310) as a QR code or a two-dimensional barcode. For example, the identification data (1320) may include temporary delivery data (1325) for the item (1310). For example, the temporary delivery data (1325) may include the recipient's name, the expected delivery completion time, the tracking number, the box number, the delivery address, etc. For example, the temporary delivery data (1325) may be data encoded by the identification data (1320). That is, although the identification data (1320) is visually displayed as a QR code or a two-dimensional barcode on a part of the item (1310) or a part of the packaging material (box) of the item (1310), the temporary delivery data (1325) included in the identification data (1320) is not visually displayed, and the temporary delivery data (1325) can be encoded by the identification data (1320) so that the temporary delivery data (1325) can be obtained only by scanning the identification data (1320).

[0137] According to one embodiment, a delivery person can scan identification data (1320) of an item (1310) that is not included in the delivery person's delivery list using a camera of a delivery person terminal (110) in a failure mode. The delivery person terminal (110) in a failure mode can obtain the identification data (1320) scanned through the camera and obtain temporary delivery data (1325) for the item (1310) based on the identification data (1320). That is, the delivery person terminal (110) in a failure mode can decode the identification data (1320) to obtain temporary delivery data (1325) for the item (1310) included in the identification data (1320). Subsequently, the delivery person terminal (110) in a failure mode can update the delivery list data so that the item (1310) is included in the delivery person's delivery list (1300) based on the temporary delivery data (1325) for the item (1310). Through this, you can add new items to the delivery person's delivery list (1300) even offline.

[0138] FIG. 14 is a diagram illustrating a process in which a delivery terminal (110) in a failure mode according to one embodiment of the present disclosure scans identification data (1420) for an item (1410) to update a delivery list (1400).

[0139] In one embodiment, the item (1410) may have identification data (1420). For example, the identification data (1420) may be attached (printed) to a portion of the item (1410) as a QR code or a two-dimensional barcode to identify the item (1410). Alternatively, the identification data (1420) may be attached (printed) to a portion of the packaging material (box) of the item (1410) as a QR code or a two-dimensional barcode. For example, the identification data (1420) may include temporary delivery data (1425) for the item (1410). For example, the temporary delivery data (1425) may include the recipient's name, the expected delivery completion time, the tracking number, the box number, the delivery address, etc. That is, although the identification data (1420) is visually displayed as a QR code or a two-dimensional barcode on a part of the item (1410) or a part of the packaging material (box) of the item (1410), the temporary delivery data (1425) included in the identification data (1420) is not visually displayed, and the temporary delivery data (1425) can be encoded by the identification data (1420) so that the temporary delivery data (1425) can be obtained only by scanning the identification data (1420).

[0140] According to one embodiment, a delivery person may scan identification data (1420) of an item (1410) using a camera of a delivery person terminal (110) in a failure mode. The delivery person terminal (110) in a failure mode may obtain the identification data (1420) scanned through the camera and obtain temporary delivery data (1425) for the item (1410) based on the identification data (1420). That is, the delivery person terminal (110) in a failure mode may decode the identification data (1420) to obtain temporary delivery data (1425) for the item (1410) included in the identification data (1420). Subsequently, the delivery person terminal (110) in a failure mode may determine, based on the temporary delivery data (1425) for the item (1410), whether the item (1410) is already included in the delivery list (1400) and is one of the items in the scan target list. Here, the scan target list may include one or more items among the plurality of items in the delivery list (1400) that need to be scanned by the delivery person before being loaded onto the delivery person's transportation means (e.g., vehicle). For example, in response to determining that an item (1410) is already included in the delivery list (1400) and is one of the items in the scan target list, the delivery person terminal (110) in the failure mode may update the delivery list data so that the item (1410) in the delivery list (1400) is marked as scanned. For example, in response to determining that an item (1410) is not included in the delivery list (1400), the delivery person terminal (110) in the failure mode may update the delivery list data so that the item (1410) is included in the delivery person's delivery list (1400) based on the temporary delivery data (1425) for the item (1410). In this case, items (1410) added to the delivery list (1400) may be automatically displayed as scanned.For example, if the item (1410) is already included in the delivery list (1400) and is not one of the items in the scan target list (if the scan has already been completed), the delivery terminal (110) in the failure mode may not perform a separate action for the item (1410).

[0141] FIG. 15 is a diagram illustrating an offline page (1500) including a delivery list (1510) updated by a delivery terminal in a failure mode according to one embodiment of the present disclosure.

[0142] According to one embodiment, the delivery agent terminal (110) in failure mode can scan the identification data of an item not included in the delivery list, obtain temporary delivery data for the item, and update the delivery list data for the delivery list based on the temporary delivery data. The delivery agent terminal (110) in failure mode can update temporary application data for the delivery management application based on the updated delivery list data. The delivery agent terminal (110) in failure mode can generate an offline page (1500) for the delivery management application based on the updated temporary application data. Subsequently, the delivery agent terminal (110) in failure mode can display the offline page (1500) on the display of the delivery agent terminal (110).

[0143] In one embodiment, the offline page (1500) may include an updated delivery list (1510). The offline page (1500) may include a recipient name (1511), an expected delivery time (1512), a delivery address (1513), a tracking number (1514), a box number (1515), etc. for items added to the delivery list (1510). Here, the recipient name (1511), the expected delivery time (1512), the delivery address (1513), the tracking number (1514), the box number (1515), etc. in the offline page (1500) may be the same as those included in the temporary delivery data for the items added to the delivery list (1510).

[0144] FIG. 16 is a diagram illustrating a method (1600) for processing delivery-related data for an offline delivery management application according to one embodiment of the present disclosure.

[0145] According to one embodiment, the method (1600) may be performed by an electronic device having one or more computing devices (200) capable of implementing a delivery agent terminal (110). Hereinafter, operations described as being performed by the electronic device may also be expressed as being performed by a process (210) of the delivery agent terminal (110) or a computing device (200) capable of implementing the delivery agent terminal (110).

[0146] In step S1610, the electronic device can acquire a failure flag indicating whether there is a failure in the server (120) of the delivery management application in normal mode. As a detailed step of step S1610, the electronic device can perform the following operations.

[0147] In one embodiment, the electronic device may transmit a request to the database (130) for a fault flag indicating whether the server (120) is faulty in normal mode. Subsequently, the electronic device may receive the fault flag from the database (130).

[0148] At S1620, the electronic device may transition from normal mode to fault mode in response to the fault flag indicating that there is a fault in the server (120).

[0149] In step S1630, the electronic device can load pre-stored delivery list data within its local database in a failure mode. Here, the delivery list data may indicate a delivery list containing one or more delivery items assigned to a delivery person. As a detailed step of step S1630, the electronic device can perform the following actions.

[0150] In one embodiment, the electronic device can identify a specific API among multiple APIs for requesting shipment list data for a shipment management application in a failure mode. Subsequently, the electronic device can load the most recently saved shipment list data from a local database as a result of the call to the specific API.

[0151] In step S1640, the electronic device may generate temporary application data for the delivery management application based on the delivery list data in the failure mode. Subsequently, the electronic device may generate an offline page for the delivery management application based on the temporary application data in the failure mode. The offline page may include a delivery list indicated by the delivery list data and a warning notification regarding the initialization of the delivery management application. The electronic device may display the offline page on its display in the failure mode.

[0152] The methods according to the present disclosure may be implemented using a device having a computer or processor. While the steps of the methods are illustrated and described in a predetermined order in this disclosure, the steps may be performed in any order that can be arbitrarily combined according to the present disclosure, in addition to being performed sequentially. In one embodiment, at least some of the steps may be performed in parallel, iteratively, or heuristically. The present disclosure does not exclude variations or modifications to the methods. In one embodiment, at least some of the steps may be omitted, or other steps may be added.

[0153] Various embodiments of the present disclosure may be implemented as software recorded on a machine-readable recording medium. The software may be software for implementing the various embodiments of the present disclosure described above. The software may be inferred from various embodiments of the present disclosure by programmers skilled in the art to which the present disclosure pertains. For example, the software may be machine-readable instructions (e.g., code or code segments) or programs. The device may be a device capable of operating according to instructions called from a recording medium, such as a computer. In one embodiment, the device may be a computing device (200) according to embodiments of the present disclosure. In one embodiment, the processor of the device may execute the called instructions, causing components of the device to perform functions corresponding to the instructions. In one embodiment, the processor may be a processor (210) according to embodiments of the present disclosure. The recording medium may refer to a recording medium on which data is stored and readable by the device. The recording medium may include, for example, ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc. In one embodiment, the recording medium may be memory (220). In one embodiment, the recording medium may be implemented in a distributed form in a computer system connected to a network, etc. The software may be distributed, stored, and executed in a computer system, etc. The recording medium may be a non-transitory recording medium. A non-transitory recording medium means a tangible medium that exists regardless of whether data is stored semi-permanently or temporarily, and does not include a signal that is transmitted transitorily.

[0154] Although the technical concept of the present disclosure has been described through various embodiments, the technical concept of the present disclosure encompasses various substitutions, modifications, and alterations that can be made within the scope understandable to those of ordinary skill in the art to which the present disclosure pertains. Furthermore, it should be understood that such substitutions, modifications, and alterations are included within the scope of the appended claims. Embodiments according to the present disclosure can be combined with each other. Each embodiment can be combined in various ways depending on the number of cases, and embodiments created by combining them also fall within the scope of the present disclosure.

Claims

1. In a method performed by an electronic device, In normal mode, a step of obtaining a fault flag indicating whether there is an incident on the server of the delivery management application; In response to the failure flag indicating that the server has a failure, switching from the normal mode to the failure mode; In the above failure mode, a step of loading delivery list data pre-stored in a local database of the electronic device, wherein the delivery list data indicates a delivery list including one or more delivery target items assigned to a delivery person; and A method comprising, in the above failure mode, generating temporary application data for the delivery management application based on the delivery list data.

2. In paragraph 1, In the above normal mode, the step of obtaining the failure flag indicating whether there is a failure in the server of the delivery management application is, A step of transmitting a request for the failure flag to a database linked with the delivery management application; and A method comprising the step of receiving the failure flag from the database.

3. In paragraph 1, In the above failure mode, the step of loading the delivery list data previously stored in the local database of the electronic device is as follows: A step of identifying a specific API for requesting the delivery list data among a plurality of APIs (application programming interfaces) for the delivery management application; and A method comprising the step of loading the most recently stored shipping list data within the local database as a result of a call to the specific API.

4. In paragraph 1, In the above failure mode, a step of generating an offline page for the delivery management application based on the temporary application data, wherein the offline page includes a delivery list and a warning notification for initialization of the delivery management application; and A method further comprising, in the above failure mode, a step of displaying the offline page on a display of the electronic device.

5. In paragraph 1, In the above failure mode, a step of receiving a normalization notification of the server from the server; and A method further comprising, in response to receiving the normalization notification, a step of switching from the fault mode to the normal mode.

6. In paragraph 5, In the above normal mode, a step of requesting application data for the delivery management application from the server; In the above normal mode, a step of receiving the application data from the server, wherein the application data includes a delivery list for one or more delivery target items assigned to the delivery person; In the above normal mode, a step of generating an online page for the delivery management application based on the application data; and A method further comprising, in the normal mode, displaying the online page on a display of the electronic device.

7. In paragraph 1, In the above failure mode, a step of obtaining delivery completion data indicating the completion of delivery of an item to be delivered in the delivery list, wherein the delivery completion data includes a delivery completion time of the item to be delivered and an image indicating the delivery completion status of the item to be delivered at the delivery completion time; and A method further comprising, in the above failure mode, a step of storing the delivery completion data in the local database.

8. In paragraph 7, A method further comprising, in response to switching from the fault mode to the normal mode, a step of transmitting, in the normal mode, delivery completion data stored in the local database to the server.

9. In paragraph 7, In the above failure mode, the step of storing the delivery completion data in the local database is: A step of identifying a specific API among multiple APIs for the delivery management application for transmitting the delivery completion data to the server; and A method comprising the step of storing a failure history for a call to the specific API in the local database.

10. In paragraph 9, In response to switching from the failure mode to the normal mode, a step of identifying, in the normal mode, a failure history for a call to the specific API stored in the local database; and A method further comprising, in response to identifying a failure history for a call to the specific API, a step of calling the specific API in the normal mode to transmit the delivery completion data stored in the local database to the server.

11. In paragraph 1, In the above failure mode, a step of obtaining identification data for items not included in the delivery list; A step of obtaining temporary delivery data for the item based on the identification data, wherein the temporary delivery data includes at least one of a recipient name, an expected delivery completion time, a tracking number, a box number, or a delivery address; and A method further comprising the step of updating the delivery list data so that the item is included in the delivery list based on the temporary delivery data.

12. In paragraph 11, The above identification data is one of a QR code or a two-dimensional barcode for identifying the item.

13. In paragraph 11, In the above failure mode, a step of updating the temporary application data based on the updated delivery list data; In the above failure mode, a step of generating an offline page for the delivery management application based on the updated temporary application data, wherein the offline page includes a delivery list updated to include the item and a warning notification for initialization of the delivery management application; and A method further comprising, in the above failure mode, a step of displaying the offline page on a display of the electronic device.

14. In electronic devices, One or more processors, comprising one or more memories storing instructions executed by the one or more processors; An electronic device, wherein when the instructions are executed by the one or more processors, the one or more processors are configured to execute a method according to any one of claims 1 to 13.

15. In a non-transitory computer-readable recording medium, instructions are recorded that cause one or more processors to perform an operation when executed by one or more processors. A non-transitory computer-readable recording medium, wherein the instructions are configured to cause the one or more processors to execute a method according to any one of claims 1 to 13.

Images