WO2026005121A1 - 오프라인으로 배송 관리 애플리케이션을 위한 배송 관련 데이터를 처리하는 방법, 장치 및 명령을 기록한 기록 매체 - Google Patents

오프라인으로 배송 관리 애플리케이션을 위한 배송 관련 데이터를 처리하는 방법, 장치 및 명령을 기록한 기록 매체

Info

Publication number
WO2026005121A1
WO2026005121A1 PCT/KR2024/013500 KR2024013500W WO2026005121A1 WO 2026005121 A1 WO2026005121 A1 WO 2026005121A1 KR 2024013500 W KR2024013500 W KR 2024013500W WO 2026005121 A1 WO2026005121 A1 WO 2026005121A1
Authority
WO
WIPO (PCT)
Prior art keywords
delivery
data
terminal
api
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/KR2024/013500
Other languages
English (en)
French (fr)
Inventor
장주란
홍성경
피정호
홍순호
이다민
조지연
임영수
조준형
조연정
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Coupang Corp
Original Assignee
Coupang Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Coupang Corp filed Critical Coupang Corp
Publication of WO2026005121A1 publication Critical patent/WO2026005121A1/ko
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G06Q10/0838—Historical data
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0772—Means for error signaling, e.g. using interrupts, exception flags, dedicated error registers
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1658—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
    • G06F11/324—Display of status information
    • G06F11/327—Alarm or error message display
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06311—Scheduling, planning or task assignment for a person or group
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services

Definitions

  • the present disclosure relates to a technique for processing delivery-related data for an offline delivery management application.
  • Advances in communications and data processing technology allow delivery workers to efficiently perform delivery tasks by running delivery management applications on their terminals.
  • delivery workers can check their assigned delivery tasks and utilize real-time delivery maps to deliver items.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • APIs application programming interfaces
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the identification data may be one of a QR code or a two-dimensional barcode for identifying the item.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 1 is a diagram illustrating a system according to one embodiment of the present disclosure.
  • FIG. 2 is a block diagram illustrating a computing device according to one embodiment of the present disclosure.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 10 is a diagram illustrating an online page for a delivery management application according to one embodiment of the present disclosure.
  • FIG. 11 is a diagram illustrating an offline page for a delivery management application according to one embodiment of the present disclosure.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a target feature e.g., a function, operation, or component
  • 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.
  • “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.
  • 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.
  • determining B based on A means taking A into consideration in determining B, and does not exclude that information other than A is additionally considered.
  • a component e.g., a first component
  • another component e.g., a second component
  • the expression that a component is “connected” or “connected” to another 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).
  • “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.
  • FIG. 1 is a drawing showing a system (100) according to one embodiment of the present disclosure.
  • the system (100) may include at least one of a delivery terminal (110), a server (120), or a database (130).
  • FIG. 1 merely illustrates an example of the system (100), and the present disclosure is not limited thereto.
  • other components not illustrated in FIG. 1 may also be included in the system (100).
  • the delivery terminal (110) may be a device possessed by the delivery person.
  • the delivery terminal (110) may be implemented as a portable terminal device such as a smartphone.
  • 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.
  • 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).
  • 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.
  • the user interface of the delivery management application may be displayed on the display of the delivery worker terminal (110).
  • 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).
  • 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.
  • 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.
  • 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).
  • 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).
  • the delivery list of the delivery person may be displayed on the display of the delivery terminal (110) as a part of the user interface of the delivery management application.
  • the delivery terminal (110) can execute an application according to one or more operating modes.
  • the operating mode of the delivery terminal (110) can be a normal mode, a failure mode, etc.
  • the normal mode can be an online mode for the server (120).
  • the failure mode can be an offline mode for the server (120).
  • 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.
  • the server (120) may be a device that manages data related to a delivery management application.
  • the server (120) may transmit application data for the delivery management application to the delivery agent terminal (110).
  • 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.
  • 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).
  • 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).
  • the database (130) may be a database linked to a delivery management application.
  • the database (130) may store data necessary for executing the delivery management application.
  • 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.
  • the failure flag may indicate the cause of the failure of the server (120) in addition to indicating that the server (120) is faulty.
  • 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).
  • the database (130) may return a failure flag to the delivery person terminal (110) in response to the query.
  • 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).
  • the notification data may include the changed data.
  • the database (130) may transmit notification data regarding the change in the failure flag to the delivery person terminal (110) or the server (120).
  • the notification data may include a failure flag.
  • the delivery terminal (110), the server (120), or the database (130) may be independent entities.
  • the delivery terminal (110), the server (120), or the database (130) may exchange data via a network (140) between devices.
  • the present disclosure is not limited thereto.
  • at least two of the delivery terminal (110), the server (120), or the database (130) may be implemented as one or more entities.
  • 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).
  • 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.
  • 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).
  • 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).
  • 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.
  • the delivery terminal (110) may be implemented as a system including one or more computing devices for performing the same function.
  • the server (120) may be implemented as a system including one or more computing devices for performing the same function.
  • 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.
  • 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.
  • FIG. 2 is a block diagram showing a computing device (200) according to one embodiment of the present disclosure.
  • the delivery terminal (110), server (120), and database (130) may each be implemented as one or more computing devices (200).
  • computing devices 200
  • the following description will focus on one computing device (200).
  • 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). Additionally or alternatively, some components may be implemented in an integrated manner, or implemented as a single or multiple entities.
  • 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.
  • one or more memories (220) may be referred to as a memory (220).
  • memory (220) may mean a set of one or more memories, unless the context clearly indicates otherwise.
  • communication interface (230) may mean a set of one or more communication circuits, unless the context clearly indicates otherwise.
  • 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.
  • a command e.g., an instruction, a code, or a code segment
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • the communication interface (230) may include at least one port for connecting to another device via a wired cable in order to communicate with the other device via a wired connection. In this case, the communication interface (230) may communicate with another device via a wired connection through the at least one port.
  • 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.
  • 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).
  • 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).
  • NFC Near Field Communication
  • RFID Radio Frequency Identification
  • MST Magnetic Secure Transmission
  • 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.
  • 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.
  • a web browser or a dedicated application may be installed on the computing device (200).
  • 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).
  • TSP touch sensor panel
  • 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).
  • the computing device (200) may include a camera.
  • the camera can capture an object and generate an image of the object.
  • 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.
  • 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.
  • GPIO General Purpose Input/Output
  • SPI Serial Peripheral Interface
  • MIPI Mobile Industry Processor Interface
  • a delivery agent terminal (110) in normal mode may request application data for a delivery management application from a server (120).
  • 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.
  • 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.
  • 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).
  • the delivery terminal (110) can request 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).
  • the delivery terminal (110) in normal mode can determine whether to switch to failure mode based on the failure flag.
  • the delivery terminal (110) in normal mode 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the temporary application data may be data that causes the delivery person's offline page including the delivery list, delivery map, etc.
  • 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 delivery terminal (110) may check a failure flag while operating in failure mode.
  • the delivery terminal (110) in failure mode may maintain failure mode and generate temporary application data to execute the delivery management application offline.
  • 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.
  • 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.
  • the delivery terminal (110) in the failure mode can receive a normalization notification of the server (120) from the server (120).
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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 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 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 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.
  • API 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.
  • each API path may be assigned a type.
  • 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.
  • 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.
  • 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).
  • 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).
  • 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.
  • the type of API path 1 (551) mapped to API 1 (511) is assumed to be "response storage.”
  • 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.
  • the delivery terminal (110) in normal mode can perform the following operations for API 1 (511).
  • the delivery terminal (110) in normal mode can call API 1 (511).
  • the delivery terminal (110) in normal mode can request data related to API 1 (511) from the server (120) by calling API 1 (511).
  • the delivery terminal (110) in normal mode can receive a response (call result) to the call of API 1 (511) from the server (120).
  • 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).
  • the delivery terminal (110) in normal mode can store a response to a call of API 1 (511).
  • 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).
  • 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.
  • the delivery terminal (110) in the failure mode can perform the following operations for API 1 (511).
  • 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).
  • 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.
  • 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).
  • 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).
  • 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.
  • 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).
  • 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).
  • the delivery person terminal (110) in the failure mode can perform the following operations for API 1 (511) requesting the delivery list data.
  • the delivery person terminal (110) in the failure mode in response to the delivery person's request for the delivery person's delivery list, 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.
  • 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).
  • 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.
  • the type of API path 2 (552) mapped to API 2 (512) is assumed to be a "dummy" and will be described.
  • 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.
  • the delivery terminal (110) in the normal mode can perform the following operations for API 2 (512).
  • the delivery terminal (110) in the normal mode can call API 2 (512).
  • 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).
  • the delivery terminal (110) in the normal mode can receive a response to the call of API 2 (512) from the server (120).
  • 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).
  • the delivery terminal (110) in the failure mode can perform the following operations for API 2 (512).
  • 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).
  • 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).
  • 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.
  • 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.
  • the type of API path 3 (553) mapped to API 3 (513) is assumed to be "ignore.”
  • 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.
  • the delivery terminal (110) in normal mode can perform the following operations for API 3 (513).
  • the delivery terminal (110) in normal mode can call API 3 (513).
  • the delivery terminal (110) in normal mode can request data related to API 3 (513) from the server (120) by calling API 3 (513).
  • the delivery terminal (110) in normal mode can receive a response to the call to API 3 (513) from the server (120).
  • 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).
  • 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.
  • data related to API 3 (513) may not be essential data for the execution of the delivery management application.
  • 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.
  • the type of API path 4 (554) mapped to API 4 (514) is assumed to be "recovery.”
  • 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.
  • the delivery terminal (110) in the normal mode can perform the following operations for API 4 (514).
  • the delivery terminal (110) in the normal mode can call API 4 (514).
  • the delivery terminal (110) in the normal mode can transmit data related to API 4 (514) to the server (120).
  • the delivery terminal (110) in the normal mode can receive a response to the call of API 4 (514) from the server (120).
  • 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).
  • the delivery terminal (110) in the failure mode can perform the following operations for API 4 (514).
  • the delivery terminal (110) in the failure mode can call API 4 (514).
  • 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).
  • 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.
  • 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).
  • 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.
  • 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).
  • the delivery terminal (110) in failure mode may store data related to API 4 (514) directly without calling API 4 (514) in S930.
  • 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).
  • 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).
  • the delivery terminal (110) in the normal mode can re-call API 4 (514) at S950.
  • 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).
  • the normal mode delivery terminal (110) can receive a response to the re-call of API 4 (514) from the server (120).
  • 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).
  • 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).
  • 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.
  • 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.
  • 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).
  • the delivery terminal (110) in the normal mode can perform the following operations with respect to API 4 (514) that transmits delivery completion data.
  • the delivery terminal (110) in the normal mode in response to the delivery terminal's request for delivery completion processing of the delivery target item, can call API 4 (514) to transmit the delivery completion data of the delivery target item to the server (120).
  • 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).
  • 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.
  • the delivery terminal (110) in the failure mode may perform the following operations with respect to API 4 (514) that transmits delivery completion data.
  • 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).
  • 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.
  • 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).
  • 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.
  • 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).
  • 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.
  • 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.
  • 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).
  • 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.
  • a response e.g., ACK
  • FIG. 10 is a diagram illustrating an online page (1000) for a delivery management application according to one embodiment of the present disclosure.
  • 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).
  • 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.
  • 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.
  • 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.
  • FIG. 11 is a diagram illustrating an offline page (1100) for a delivery management application according to one embodiment of the present disclosure.
  • 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).
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the delivery terminal (110) in failure mode may store the delivery completion data of the item to be delivered in the queue (1200).
  • 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.
  • the queue (1200) may be a space allocated for temporarily storing the delivery completion data.
  • the queue (1200) may be a storage space allocated for temporarily storing the delivery completion data in the local database of the delivery terminal (110).
  • the queue (1200) may be a storage space separate from the local database of the delivery terminal (110).
  • 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.
  • 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).
  • 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).
  • 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).
  • 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.
  • 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 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.
  • 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).
  • 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).
  • 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).
  • the delivery completion data 3 (1203) may be stored in the queue (1200) in the following order: delivery completion data 2 (1202).
  • 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.
  • 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.
  • 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).
  • 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).
  • the delivery completion data 4 (1204) may be stored in the queue (1200) in the following order: delivery completion data 3 (1203).
  • 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.
  • 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).
  • 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).
  • 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).
  • the delivery completion data 5 (1205) may be stored in the queue (1200) in the following order: delivery completion data 4 (1204).
  • 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).
  • 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).
  • the data size may be the length of the bits constituting the image included in the delivery completion data.
  • 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).
  • 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.
  • 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).
  • 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).
  • 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).
  • 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.
  • 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.
  • 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).
  • the specific delivery type may be next-day early morning delivery.
  • the delivery terminal (110) in normal mode may first call an API that transmits delivery completion data 2 (1202).
  • 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.
  • 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).
  • 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).
  • an item (1310) that is not included in the delivery list of the delivery person terminal (110) may have identification data (1320).
  • 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).
  • 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.
  • the identification data (1320) may include temporary delivery data (1325) for the item (1310).
  • 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.
  • 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).
  • 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).
  • 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.
  • 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).
  • the item (1410) may have identification data (1420).
  • 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).
  • 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.
  • the identification data (1420) may include temporary delivery data (1425) for the item (1410).
  • 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.
  • 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).
  • 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).
  • 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.
  • 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).
  • 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.
  • 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).
  • the item (1410) added to the delivery list (1400) may be automatically marked 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 it is already in the scanned state), the delivery terminal (110) in the failure mode may not perform a separate operation on the item (1410).
  • 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.
  • 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).
  • 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).
  • 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).
  • 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.
  • 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).
  • 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).
  • 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.
  • the electronic device can perform the following operations.
  • 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).
  • 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).
  • step S1630 the electronic device can load pre-stored delivery list data within its local database in a failure mode.
  • the delivery list data may indicate a delivery list containing one or more delivery items assigned to a delivery person.
  • the electronic device can perform the following actions.
  • 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.
  • 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.
  • the methods according to the present disclosure may be implemented using a computer or a device having a 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, 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.
  • 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.
  • 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.
  • the device may be a computing device (200) according to embodiments of the present disclosure.
  • the processor of the device may execute the called instructions, causing components of the device to perform functions corresponding to the instructions.
  • 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.
  • the recording medium may be memory (220).
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Quality & Reliability (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • General Engineering & Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Databases & Information Systems (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Retry When Errors Occur (AREA)
  • Computer And Data Communications (AREA)
  • Debugging And Monitoring (AREA)

Abstract

본 개시의 일 실시예에 따른 전자 장치에 의해 수행되는 방법은, 정상 모드에서, 배송 관리 애플리케이션의 서버에 대한 장애 유무를 지시하는 장애 플래그를 획득하는 단계, 상기 장애 플래그가 상기 서버에 장애가 있음을 지시하는 것에 응답하여, 상기 정상 모드에서 장애 모드로 전환하는 단계; 상기 장애 모드에서, 상기 전자 장치의 로컬 데이터베이스 내에 미리 저장된 배송 목록 데이터를 로드하는 단계 및 상기 장애 모드에서, 상기 배송 목록 데이터에 기초하여, 상기 배송 관리 애플리케이션에 대한 임시 애플리케이션 데이터를 생성하는 단계를 포함할 수 있다.

Description

오프라인으로 배송 관리 애플리케이션을 위한 배송 관련 데이터를 처리하는 방법, 장치 및 명령을 기록한 기록 매체
본 개시는 오프라인으로 배송 관리 애플리케이션을 위한 배송 관련 데이터를 처리하는 기술에 관한 것이다.
통신 및 데이터 처리 기술의 발전으로 인해 배송원은 보유하는 단말기에서 배송 관리 애플리케이션을 실행하여 배송 업무를 효율적으로 수행할 수 있다. 배송 관리 애플리케이션을 통해 배송원은 자신에게 할당된 배송 업무 내용을 확인하고, 실시간으로 제공되는 배송 지도를 활용하여 아이템을 배송할 수 있다.
그러나, 배송 관리 애플리케이션이 정상적으로 작동하려면 관련 데이터를 제공하는 서버의 안정성이 필수적이다. 서버에 장애가 발생할 경우, 서버가 복구될 때까지 배송원은 애플리케이션을 제대로 이용할 수 없게 된다. 이로 인해 배송원은 정확한 배송 경로를 선택하지 못하게 되어 오배송이 발생하거나 정해진 배송 일정을 준수하지 못하는 상황이 발생할 수 있다. 더 나아가, 서버가 복구되기 전까지 배송원이 실제로 완료한 배송 업무를 적절히 기록할 수 없으며, 새로운 배송 업무를 할당받는 것도 불가능하게 된다.
본 개시는, 배송 관리 애플리케이션의 서버에 장애가 발생하더라도, 배송원 단말기에서 오프라인으로 배송 관리 애플리케이션의 배송 관련 데이터를 처리하는 기술을 제공한다.
본 개시의 한 관점(aspect)으로, 오프라인으로 배송 관리 애플리케이션을 위한 배송 관련 데이터를 처리하는 방법이 제안될 수 있다. 본 개시에 따른 방법은, 전자 장치에 의해 수행되는 방법일 수 있다. 본 개시에 따른 방법은, 정상 모드에서, 배송 관리 애플리케이션의 서버에 대한 장애(incident) 유무를 지시하는 장애 플래그(flag)를 획득하는 단계; 상기 장애 플래그가 상기 서버에 장애가 있음을 지시하는 것에 응답하여, 상기 정상 모드에서 장애 모드로 전환하는 단계; 상기 장애 모드에서, 상기 전자 장치의 로컬 데이터베이스 내에 미리 저장된 배송 목록 데이터를 로드하는 단계(상기 배송 목록 데이터는 배송원에게 할당된 하나 이상의 배송 대상 아이템을 포함하는 배송 목록을 지시할 수 있다.); 및 상기 장애 모드에서, 상기 배송 목록 데이터에 기초하여, 상기 배송 관리 애플리케이션에 대한 임시 애플리케이션 데이터를 생성하는 단계를 포함할 수 있다.
일 실시예에 따르면, 상기 정상 모드에서, 상기 배송 관리 애플리케이션의 상기 서버에 대한 장애 유무를 지시하는 상기 장애 플래그를 획득하는 단계는, 상기 배송 관리 애플리케이션과 연동된 데이터베이스에 상기 장애 플래그에 대한 요청을 전송하는 단계; 및 상기 데이터베이스로부터, 상기 장애 플래그를 수신하는 단계를 포함할 수 있다.
일 실시예에 따르면, 상기 장애 모드에서, 상기 전자 장치의 상기 로컬 데이터베이스 내에 미리 저장된 상기 배송 목록 데이터를 로드하는 단계는, 상기 배송 관리 애플리케이션에 대한 복수의 API(application programming interface) 중에서 상기 배송 목록 데이터를 요청하기 위한 특정 API를 식별하는 단계; 및 상기 특정 API에 대한 호출 결과로서 상기 로컬 데이터베이스 내에서 가장 마지막으로 저장된 배송 목록 데이터를 로드하는 단계를 포함할 수 있다.
본 개시에 따른 방법은, 상기 장애 모드에서, 상기 임시 애플리케이션 데이터에 기초하여, 상기 배송 관리 애플리케이션에 대한 오프라인 페이지를 생성하는 단계(상기 오프라인 페이지는 상기 배송 목록 및 상기 배송 관리 애플리케이션의 초기화에 대한 경고 알림을 포함할 수 있다.); 및 상기 장애 모드에서, 상기 전자 장치의 디스플레이에 상기 오프라인 페이지를 표출하는 단계를 더 포함할 수 있다.
본 개시에 따른 방법은, 상기 장애 모드에서, 상기 서버로부터, 상기 서버의 정상화 알림을 수신하는 단계; 및 상기 정상화 알림을 수신한 것에 응답하여, 상기 장애 모드에서 상기 정상 모드로 전환하는 단계를 더 포함할 수 있다.
본 개시에 따른 방법은, 상기 정상 모드에서, 상기 서버에 상기 배송 관리 애플리케이션에 대한 애플리케이션 데이터를 요청하는 단계; 상기 정상 모드에서, 상기 서버로부터, 상기 애플리케이션 데이터를 수신하는 단계(상기 애플리케이션 데이터는 상기 배송원에게 할당된 하나 이상의 배송 대상 아이템에 대한 배송 목록을 포함할 수 있다); 상기 정상 모드에서, 상기 애플리케이션 데이터에 기초하여, 상기 배송 관리 애플리케이션에 대한 온라인 페이지를 생성하는 단계; 및 상기 정상 모드에서, 상기 전자 장치의 디스플레이에 상기 온라인 페이지를 표출하는 단계를 더 포함할 수 있다.
본 개시에 따른 방법은, 상기 장애 모드에서, 상기 배송 목록 내 배송 대상 아이템의 배송 완료를 지시하는 배송 완료 데이터를 획득하는 단계(상기 배송 완료 데이터는 상기 배송 대상 아이템의 배송 완료 시간 및 상기 배송 완료 시간에서 상기 배송 대상 아이템의 배송 완료 상태를 나타내는 이미지를 포함할 수 있다.); 및 상기 장애 모드에서, 상기 배송 완료 데이터를 상기 로컬 데이터베이스에 저장하는 단계를 더 포함할 수 있다.
본 개시에 따른 방법은, 상기 장애 모드에서 상기 정상 모드로 전환하는 것에 응답하여, 상기 정상 모드에서, 상기 로컬 데이터베이스에 저장된 배송 완료 데이터를 상기 서버에 전송하는 단계를 더 포함할 수 있다.
일 실시예에 따르면, 상기 장애 모드에서, 상기 배송 완료 데이터를 상기 로컬 데이터베이스에 저장하는 단계는, 상기 배송 관리 애플리케이션에 대한 복수의 API 중에서 상기 배송 완료 데이터를 상기 서버에 전송하기 위한 특정 API를 식별하는 단계; 및 상기 특정 API의 호출에 대한 실패 이력을 상기 로컬 데이터베이스에 저장하는 단계를 포함할 수 있다.
본 개시에 따른 방법은, 상기 장애 모드에서 상기 정상 모드로 전환하는 것에 응답하여, 상기 정상 모드에서, 상기 로컬 데이터베이스에 저장된 상기 특정 API의 호출에 대한 실패 이력을 식별하는 단계; 및 상기 특정 API의 호출에 대한 실패 이력을 식별한 것에 응답하여, 상기 정상 모드에서, 상기 특정 API를 호출하여 상기 로컬 데이터베이스에 저장된 상기 배송 완료 데이터를 상기 서버에 전송하는 단계를 더 포함할 수 있다.
본 개시에 따른 방법은, 상기 장애 모드에서, 상기 배송 목록에 포함되지 않은 아이템에 대한 식별 데이터를 획득하는 단계; 상기 식별 데이터에 기초하여, 상기 아이템에 대한 임시 배송 데이터를 획득하는 단계 - 상기 임시 배송 데이터는 수취인 이름, 배송 완료 예상 시간, 운송장 번호, 박스 번호, 또는 배송지 주소 중 적어도 하나를 포함함 -; 및 상기 임시 배송 데이터에 기초하여, 상기 아이템이 상기 배송 목록에 포함되도록 상기 배송 목록 데이터를 업데이트하는 단계를 더 포함할 수 있다.
일 실시예에 따르면, 상기 식별 데이터는 상기 아이템을 식별하기 위한 QR 코드 또는 2차원 바코드 중 하나일 수 있다.
본 개시에 따른 방법은, 상기 장애 모드에서, 상기 업데이트된 배송 목록 데이터에 기초하여, 상기 임시 애플리케이션 데이터를 업데이트하는 단계; 상기 장애 모드에서, 상기 업데이트된 임시 애플리케이션 데이터에 기초하여, 상기 배송 관리 애플리케이션에 대한 오프라인 페이지를 생성하는 단계(상기 오프라인 페이지는 상기 아이템을 포함하도록 업데이트된 배송 목록 및 상기 배송 관리 애플리케이션의 초기화에 대한 경고 알림을 포함할 수 있다.); 및 상기 장애 모드에서, 상기 전자 장치의 디스플레이에 상기 오프라인 페이지를 표출하는 단계를 더 포함할 수 있다.
본 개시의 한 관점으로, 오프라인으로 배송 관리 애플리케이션을 위한 배송 관련 데이터를 처리하는 전자 장치가 제안될 수 있다. 본 개시에 따른 전자 장치는, 하나 이상의 프로세서, 상기 하나 이상의 프로세서에 의해 실행되는 명령어들이 저장된 하나 이상의 메모리를 포함하고, 상기 하나 이상의 프로세서에 의해 상기 명령어들이 실행될 시, 상기 하나 이상의 프로세서는, 본 개시에 따른 방법을 실행하도록 구성될 수 있다.
본 개시의 한 관점으로, 오프라인으로 배송 관리 애플리케이션을 위한 배송 관련 데이터를 처리하는 명령어들을 기록한 비일시적 컴퓨터 판독 가능 기록 매체가 제안될 수 있다. 본 개시에 따른 비일시적 컴푸터 판독 가능 기록 매체에 기록된 명령어들은, 하나 이상의 프로세서로 하여금, 본 개시에 따른 방법을 실행하게 하도록 구성될 수 있다.
본 개시의 일 실시예에 따르면, 배송 관리 애플리케이션의 서버에 장애가 발생하더라도, 배송원 단말기에서 오프라인으로 배송 관리 애플리케이션을 위한 배송 관련 데이터를 처리할 수 있도록 함으로써, 서버가 복구되기 전에도 배송원이 오프라인 모드의 배송 관리 애플리케이션을 통해 배송 업무를 수행할 수 있게 된다.
본 개시의 기술적 사상에 따른 효과들은 이상에서 언급한 효과들로 제한되지 않으며, 언급되지 않은 또 다른 효과들은 명세서의 기재로부터 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 개시의 일 실시예에 따른 시스템을 나타낸 도면이다.
도 2는 본 개시의 일 실시예에 따른 컴퓨팅 장치의 블록도를 나타낸 도면이다.
도 3은 본 개시의 일 실시예에 따른 배송원 단말기가 배송 관리 애플리케이션을 실행하는 과정을 도시한 도면이다.
도 4는 본 개시의 일 실시예에 따른 장애 모드의 배송원 단말기가 정상 모드로 전환하는 과정을 나타낸 도면이다.
도 5는 본 개시의 일 실시예에 따른 API 및 API 경로 간의 매핑 관계를 지시하는 매핑 데이터를 나타낸 도면이다.
도 6은 본 개시의 일 실시예에 따른 API 경로에 매핑된 API에 대한 배송원 단말기의 동작을 나타낸 도면이다.
도 7은 본 개시의 일 실시예에 따른 API 경로에 매핑된 API에 대한 배송원 단말기의 동작을 나타낸 도면이다.
도 8은 본 개시의 일 실시예에 따른 API 경로에 매핑된 API에 대한 배송원 단말기의 동작을 나타낸 도면이다.
도 9는 본 개시의 일 실시예에 따른 API 경로에 매핑된 API에 대한 배송원 단말기의 동작을 나타낸 도면이다.
도 10은 본 개시의 일 실시예에 따른 배송 관리 애플리케이션에 대한 온라인 페이지를 나타낸 도면이다.
도 11은 본 개시의 일 실시예에 따른 배송 관리 애플리케이션에 대한 오프라인 페이지를 나타낸 도면이다.
도 12는 본 개시의 일 실시예에 따른 배송 대상 아이템의 배송 완료 데이터에 대한 배송원 단말기의 동작을 나타낸 도면이다.
도 13은 본 개시의 일 실시예에 따른 장애 모드의 배송원 단말기가 아이템에 대한 식별 데이터를 스캔하여 배송 목록을 업데이트하는 과정을 나타낸 도면이다.
도 14는 본 개시의 일 실시예에 따른 장애 모드의 배송원 단말기가 아이템에 대한 식별 데이터를 스캔하여 배송 목록을 업데이트하는 과정을 나타낸 도면이다.
도 15는 본 개시의 일 실시예에 따른 장애 모드의 배송원 단말기에 의해 업데이트된 배송 목록을 포함하는 오프라인 페이지를 나타낸 도면이다.
도 16은 본 개시의 일 실시예에 따른 오프라인으로 배송 관리 애플리케이션을 위한 배송 관련 데이터를 처리하는 방법을 나타낸 도면이다.
본 개시에 기재된 다양한 실시예들은, 본 개시의 기술적 사상을 명확히 설명하기 위한 목적으로 예시된 것이며, 이를 특정한 실시 형태로 한정하려는 것이 아니다. 본 개시의 기술적 사상은, 본 개시에 기재된 각 실시예의 다양한 변경(modifications), 균등물(equivalents), 대체물(alternatives) 및 각 실시예의 전부 또는 일부로부터 선택적으로 조합된 실시예를 포함한다. 또한 본 개시의 기술적 사상의 권리 범위는 이하에 제시되는 다양한 실시예들이나 이에 대한 구체적 설명으로 한정되지 않는다.
기술적이거나 과학적인 용어를 포함해서, 본 개시에서 사용되는 용어들은, 달리 정의되지 않는 한, 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자에게 일반적으로 이해되는 의미를 가질 수 있다.
본 개시에서, "포함한다", "포함할 수 있다", "구비한다", "구비할 수 있다", "가진다", "가질 수 있다" 등과 같은 표현들은, 대상이 되는 특징(예: 기능, 동작 또는 구성요소 등)이 존재함을 의미하며, 다른 추가적인 특징의 존재를 배제하지 않는다. 즉, 이와 같은 표현들은 다른 실시예를 포함할 가능성을 내포하는 개방형 용어(open-ended terms)로 이해되어야 한다.
본 개시에서, 단수형의 표현은 문맥상 다르게 뜻하지 않는 한 복수형의 의미를 포함할 수 있으며, 이는 청구항에 기재된 단수형의 표현에도 마찬가지로 적용된다.
본 개시에서, "제1", "제2", 또는 "첫째", "둘째" 등의 표현은, 문맥상 다르게 뜻하지 않는 한, 복수의 동종 대상들을 지칭함에 있어 한 대상을 다른 대상과 구분하기 위해 사용되며, 해당 대상들 간의 순서 또는 중요도를 한정하는 것은 아니다.
본 개시에서, "A, B, 및 C," "A, B, 또는 C," "A, B, 및/또는 C" 또는 "A, B, 및 C 중 적어도 하나," "A, B, 또는 C 중 적어도 하나," "A, B, 및/또는 C 중 적어도 하나," "A, B, 및 C 중에서 선택된 적어도 하나," "A, B, 또는 C 중에서 선택된 적어도 하나," "A, B, 및/또는 C 중에서 선택된 적어도 하나" 등의 표현은, 각각의 나열된 항목 또는 나열된 항목들의 가능한 모든 조합들을 의미할 수 있다. 예를 들어, "A 및 B 중에서 선택된 적어도 하나"는, (1) A, (2) A 중 적어도 하나, (3) B, (4) B 중 적어도 하나, (5) A 중 적어도 하나 및 B 중 적어도 하나, (6) A 중 적어도 하나 및 B, (7) B 중 적어도 하나 및 A, (8) A 및 B를 모두 지칭할 수 있다.
본 개시에서, "~에 기초하여(based on 또는 according to)"라는 표현은, 해당 표현이 포함되는 어구 또는 문장에서 기술되는, 결정, 판단의 행위 또는 동작에 영향을 주는 하나 이상의 인자를 기술하는데 사용되고, 이 표현은 해당 결정, 판단의 행위 또는 동작에 영향을 주는 추가적인 인자를 배제하지 않는다.
본 개시에서, A에 기초하여 B를 결정한다는 것은, B를 결정하는 데에 A를 고려한다는 것이며, A 외 다른 정보가 추가로 고려된다는 것을 배제하지 아니한다.
본 개시에서, 어떤 구성요소(예: 제1 구성요소)가 다른 구성요소(예: 제2 구성요소)에 "연결되어" 있다거나 "접속되어" 있다는 표현은, 상기 어떤 구성요소가 상기 다른 구성요소에 직접적으로 연결 또는 접속되는 것뿐 아니라, 새로운 다른 구성요소(예: 제3 구성요소)를 매개로 하여 연결 또는 접속되는 것을 의미할 수 있다.
본 개시에서, "~하도록 구성된(configured to)"은 문맥에 따라, "~하도록 설정된", "~하는 능력을 가지는", "~하도록 변경된", "~하도록 만들어진", "~를 할 수 있는" 등의 의미를 가질 수 있다. 해당 표현은, "하드웨어적으로 특별히 설계된"의 의미로 제한되지 않으며, 예를 들어 특정 동작을 수행하도록 구성된 프로세서란, 해당 특정 동작을 수행하도록, 프로그래밍을 통해 구조화된 특수 목적 컴퓨터(special purpose computer)를 의미할 수 있다.
이하, 첨부된 도면들을 참조하여, 본 개시의 다양한 실시예들을 설명한다. 첨부된 도면 및 도면에 대한 설명에서, 동일하거나 실질적으로 동등한(substantially equivalent) 구성요소에는 동일한 참조부호가 부여될 수 있다. 또한, 이하 다양한 실시예들의 설명에 있어서, 동일하거나 대응하는 구성요소를 중복하여 기술하는 것이 생략될 수 있으나, 이는 해당 구성요소가 그 실시예에 포함되지 않는 것을 의미하지는 않는다.
도 1은 본 개시의 일 실시예에 따른 시스템(100)을 나타낸 도면이다.
일 실시예에 따르면, 시스템(100)은 배송원 단말기(110), 서버(120), 또는 데이터베이스(130) 중 적어도 하나를 포함할 수 있다. 한편, 도 1은 시스템(100)의 예시를 도시한 것일 뿐, 본 개시가 이에 제한되는 것은 아니다. 예를 들어, 도 1에 도시되지 않은 다른 구성도 시스템(100)에 포함될 수 있다.
일 실시예에 따르면, 배송원 단말기(110)는 배송원이 보유하는 장치일 수 있다. 예를 들어, 배송원 단말기(110)는 스마트폰 등 휴대용 단말 장치로 구현될 수 있다. 한편, 본 개시가 이에 제한되지 않으며, 배송원 단말기(110)는 다양한 형태를 가질 수 있다. 배송원 단말기(110)는 클라이언트(client), 클라이언트 단말기, 사용자 단말기, 전자 장치 등 이와 동일 내지 유사한 의미를 갖는 용어로 표현될 수도 있다.
예를 들어, 배송원 단말기(110)에는 배송 관리 애플리케이션이 설치되고, 배송 관리 애플리케이션 실행 시 배송 관리 애플리케이션의 사용자 인터페이스(user interface)가 배송원 단말기(110) 상에 표시될 수 있다. 한편, 배송 관리 애플리케이션은 배송원에게 할당된 하나 이상의 배송 대상 아이템을 포함하는 배송 목록, 배송 지도 등 배송 관리를 위한 다양한 사용자 인터페이스를 제공할 수 있는 애플리케이션일 수 있다. 예를 들어, 배송원 단말기(110)의 디스플레이에 배송 관리 애플리케이션의 사용자 인터페이스가 표시될 수 있다. 여기서, 사용자 인터페이스는 배송원과 배송원 단말기(110) 간의 상호작용을 위한 물리적 또는 가상적 매개체로서, 배송원은 배송원 단말기(110) 상에 표시된 배송 관리 애플리케이션의 사용자 인터페이스를 통해 배송 관리 애플리케이션을 조작할 수 있다. 예를 들어, 사용자 인터페이스는 이미지(image) 또는 텍스트(text) 등 특정 정보를 표시하기 위한 기본 요소와, 이러한 기본 요소를 활용하여 구성할 수 있는 버튼(button) 등 사용자의 입력을 수신하기 위한 요소를 포함할 수 있다. 예를 들어, 배송원 단말기(110)의 디스플레이에 표시된 사용자 인터페이스가 배송원에 의해 선택(클릭)되는 것은 사용자 인터페이스에 대응하는 배송원의 입력이 수신되는 것으로 표현될 수 있다. 예를 들어, 배송원은 배송원 단말기(110)의 디스플레이 상에 표시된 배송 관리 애플리케이션의 사용자 인터페이스를 선택함으로써, 선택된 인터페이스에 해당하는 데이터를 요청할 수 있다. 예를 들어, 배송원은 배송원 단말기(110)의 디스플레이에 표시된 배송 관리 애플리케이션의 배송 목록에 대한 사용자 인터페이스를 선택함으로써, 해당 배송원에게 할당된 하나 이상의 배송 대상 아이템을 포함하는 배송 목록을 요청할 수 있다. 이 경우, 해당 배송원의 배송 목록이 배송 관리 애플리케이션의 사용자 인터페이스의 일부분으로서 배송원 단말기(110)의 디스플레이에 표시될 수 있다.
예를 들어, 배송원 단말기(110)는 하나 이상의 동작 모드에 따라 애플리케이션을 실행할 수 있다. 여기서, 배송원 단말기(110)의 동작 모드는 정상 모드, 장애 모드 등일 수 있다. 예를 들어, 정상 모드는 서버(120)에 대한 온라인 모드일 수 있다. 예를 들어, 장애 모드는 서버(120)에 대한 오프라인 모드일 수 있다. 예를 들어, 배송원 단말기(110)는 서버(120)의 장애 유무에 따라 정상 모드 또는 장애 모드로 동작할 수 있다. 서버(120)에 장애가 없는 경우, 배송원 단말기(110)는 정상 모드에서 배송 관리 애플리케이션을 실행할 수 있다. 서버(120)에 장애가 있는 경우, 배송원 단말기(110)는 장애 모드에서 배송 관리 애플리케이션을 실행할 수 있다.
일 실시예에 따르면, 서버(120)는 배송 관리 애플리케이션과 관련된 데이터를 관리하는 장치일 수 있다. 예를 들어, 서버(120)는 배송 관리 애플리케이션에 대한 애플리케이션 데이터를 배송원 단말기(110)에 전송할 수 있다. 여기서, 애플리케이션 데이터는 배송원에게 할당된 하나 이상의 배송 대상 아이템을 포함하는 배송 목록, 배송 지도 등을 배송 관리 애플리케이션의 사용자 인터페이스의 일부분으로서 표출하도록 하는 데이터일 수 있다. 예를 들어, 애플리케이션 데이터는 배송원 단말기(110)의 배송원의 배송 목록, 배송 지도 등을 포함하는 온라인 페이지를 표출하도록 하는 데이터일 수 있다. 배송원 단말기(110)는 서버(120)로부터 수신한 애플리케이션 데이터에 기초하여, 배송 관리 애플리케이션을 실행할 수 있다. 예를 들어, 배송원 단말기(110)는 서버(120)로부터 수신한 애플리케이션 데이터에 기초하여, 배송원의 배송 목록, 배송 지도 등을 포함하는 온라인 페이지를 배송원 단말기(110)의 디스플레이 상에 표출할 수 있다.
일 실시예에 따르면, 데이터베이스(130)는 배송 관리 애플리케이션과 연동된 데이터베이스일 수 있다. 예를 들어, 데이터베이스(130)는 배송 관리 애플리케이션의 실행에 필요한 데이터를 저장할 수 있다. 예를 들어, 데이터베이스(130)는 서버(120)의 장애 유무를 지시하는 장애 플래그(flag)를 저장할 수 있다. 장애 플래그는 서버(120)에 장애가 있음을 지시하는 제1 값 및 서버(120)에 장애가 없음을 지시하는 제2 값을 포함할 수 있다. 추가적으로, 장애 플래그는 서버(120)에 장애가 있음을 지시하는 것에 더해 서버(120)의 장애 원인(cause)도 지시할 수 있다. 이 경우, 장애 플래그는 서버(120)에 장애가 있음을 지시하는 제1 값 및 서버(120)의 장애 원인을 지시하는 오류 코드를 포함할 수 있다. 예를 들어, 배송원 단말기(110)가 데이터베이스(130)에 장애 플래그를 쿼리(query)하는 경우, 데이터베이스(130)는 해당 쿼리에 응답하여 배송원 단말기(110)에 장애 플래그를 반환할 수 있다. 한편, 데이터베이스(130)는 배송 관리 애플리케이션과 실시간으로 연동된 데이터베이스로서, 배송 관리 애플리케이션이 필요로 하는 데이터의 변경을 감지하면, 배송원 단말기(110) 또는 서버(120)에 데이터의 변경에 대한 알림 데이터를 전송할 수 있다. 이 경우, 알림 데이터는 변경된 데이터를 포함할 수 있다. 예를 들어, 데이터베이스(130) 내 장애 플래그가 변경되는 경우, 데이터베이스(130)는 장애 플래그의 변경에 대한 알림 데이터를 배송원 단말기(110) 또는 서버(120)에 전송할 수 있다. 이 경우, 알림 데이터는 장애 플래그를 포함할 수 있다.
일 실시예에 따르면, 배송원 단말기(110), 서버(120), 또는 데이터베이스(130)는 독립적인 개체(entity)일 수 있다. 이 경우, 배송원 단말기(110), 서버(120), 또는 데이터베이스(130)는 장치 간 네트워크(140)를 통해 데이터를 교환할 수 있다. 다만, 본 개시가 이에 제한되는 것은 아니다. 예를 들어, 배송원 단말기(110), 서버(120), 또는 데이터베이스(130) 중 적어도 둘 이상이 하나 이상의 개체로 구현될 수 있다. 예를 들어, 시스템(100)은 배송원 단말기(110)의 기능을 수행하기 위한 모듈(또는, 프로세서) 및 서버(120)의 기능을 수행하기 위한 모듈(또는, 프로세서)을 구비한 장치를 포함할 수 있다. 이 경우, 배송원 단말기(110)의 기능을 수행하기 위한 모듈(또는, 프로세서) 및 서버(120)의 기능을 수행하기 위한 모듈(또는, 프로세서)은 장치 내 네트워크를 통해 데이터를 교환할 수 있다. 예를 들어, 시스템(100)은 배송원 단말기(110)의 기능 및 서버(120)의 기능을 수행하기 위한 모듈(또는, 프로세서)를 구비한 장치를 포함할 수 있다. 예를 들어, 데이터베이스(130)가 배송원 단말기(110) 내에 로컬 데이터베이스로서 포함되거나, 데이터베이스(130)의 캐시 데이터가 배송원 단말기(110) 내에 저장될 수도 있다.
한편, 도 1에는 배송원 단말기(110), 서버(120) 및 데이터베이스(130)가 각각 하나의 장치로 구현되는 것으로 도시되었지만, 본 개시가 이에 제한되는 것은 아니다. 예를 들어, 배송원 단말기(110)는 이와 동일한 기능을 수행하기 위한 하나 이상의 컴퓨팅 장치를 포함하는 시스템으로 구현될 수 있다. 예를 들어, 서버(120)는 이와 동일한 기능을 수행하기 위한 하나 이상의 컴퓨팅 장치를 포함하는 시스템으로 구현될 수 있다. 예를 들어, 데이터베이스(130)는 이와 동일한 기능을 수행하기 위한 하나 이상의 컴퓨팅 장치를 포함하는 시스템으로 구현될 수 있다. 컴퓨팅 장치는 도 2의 설명을 참조할 수 있다.
또한, 도 1에는 배송원 단말기(110), 서버(120) 및 데이터베이스(130)가 각각 하나씩 도시되었지만, 본 개시가 이에 제한되는 것은 아니다. 배송원 단말기(110), 서버(120) 및 데이터베이스(130) 각각의 개수는 본 개시의 실시예가 적용 가능한 범위 내에서 얼마든지 달라질 수 있다.
도 2는 본 개시의 일 실시예에 따른 컴퓨팅 장치(200)의 블록도를 나타낸 도면이다.
일 실시예에 따르면, 배송원 단말기(110), 서버(120) 및 데이터베이스(130)는 각각 하나 이상의 컴퓨팅 장치(200)로 구현될 수 있다. 이하에서는, 설명의 편의를 위해 하나의 컴퓨팅 장치(200)를 중심으로 설명하기로 한다.
일 실시예에 따르면, 컴퓨팅 장치(200)는 하나 이상의 프로세서(210), 하나 이상의 메모리(220), 또는 통신 인터페이스(230)를 포함할 수 있다. 한편, 컴퓨팅 장치(200)에서 일부 구성요소가 삭제되거나 다른 구성요소(디스플레이 또는 입력 장치 등)가 컴퓨팅 장치(200)에 추가될 수 있다. 또한, 추가적으로 또는 대체적으로 일부의 구성요소들이 통합되어 구현되거나, 단수 또는 복수의 개체로 구현될 수 있다. 본 개시에서, 하나 이상의 프로세서(210)는 프로세서(210)라고 지칭될 수 있다. 이러한 프로세서(210)라는 용어는, 문맥상 명백히 다르게 표현하지 않는 이상, 하나 또는 그 이상의 프로세서의 집합을 의미할 수 있다. 또한, 본 개시에서, 하나 이상의 메모리(220)는 메모리(220)라고 지칭될 수 있다. 이러한 메모리(220)라는 용어는, 문맥상 명백히 다르게 표현하지 않는 이상, 하나 또는 그 이상의 메모리의 집합을 의미할 수 있다. 또는, 본 개시에서, 통신 인터페이스(230)라는 용어는, 문맥상 명백히 다르게 표현하지 않는 이상, 하나 또는 그 이상의 통신 회로의 집합을 의미할 수 있다.
일 실시예에 따르면, 프로세서(210)는, 컴퓨팅 장치(200)의 각 구성요소들의 제어 또는 통신에 관한 연산이나 정보 처리를 수행할 수 있다. 구체적으로, 프로세서(210)는 다른 구성요소로부터 수신된 소프트웨어(또는 컴퓨터 프로그램)를 구동하여 프로세서(210)에 연결된 컴퓨팅 장치(200)의 적어도 하나의 구성요소를 제어할 수 있다. 일례로서, 프로세서(210)는 명령(예: 인스트럭션(instruction), 코드 또는 코드 세그먼트) 또는 정보를 메모리(220)에 로드(load)하고, 메모리(220)에 저장된 명령 또는 정보를 처리하고, 그 처리에 따른 결과 정보를 메모리(220)에 저장할 수 있다. 또한, 프로세서(210)는 컴퓨팅 장치(200)의 구성요소들과 작동적으로 연결되어 본 개시와 관련된 다양한 연산, 처리, 생성 또는 가공 등의 동작을 수행할 수 있다.
일 실시예에 따르면, 메모리(220)는 다양한 정보를 저장할 수 있다. 메모리(220)에 저장되는 정보는, 컴퓨팅 장치(200)의 적어도 하나의 구성요소에 의해 획득되거나, 처리되거나, 사용되는 정보로서, 소프트웨어를 포함할 수 있다. 소프트웨어는 메모리(220)에 로드될 때 프로세서(210)로 하여금 본 개시의 다양한 실시예에 따른 동작을 수행하도록 하는 하나 이상의 명령들을 포함할 수 있다. 즉, 프로세서(210)는 전술한 하나 이상의 명령들을 실행함으로써, 본 개시의 다양한 실시예에 따른 동작들을 수행할 수 있다. 또한, 메모리(220)에는 코드 변경에 대한 검사 요청과 관련된 이력을 기록하기 위한 데이터베이스가 구현(저장)될 수 있다. 메모리(220)는, 예를 들어, 휘발성 또는 비휘발성 메모리를 포함할 수 있다.
일 실시예에 따르면, 프로그램은 메모리(220)에 저장되는 소프트웨어로서, 컴퓨팅 장치(200)의 리소스를 제어하기 위한 운영체제, 애플리케이션 또는 애플리케이션이 컴퓨팅 장치(200)의 리소스들을 활용할 수 있도록 다양한 기능을 애플리케이션에 제공하는 미들웨어 등을 포함할 수 있다.
일 실시예에 따르면, 통신 인터페이스(230)는, 다른 장치와 유선 또는 무선 통신 채널을 설립하고, 그 다른 장치와 다양한 정보를 송수신할 수 있다.
일 실시예에 따르면, 통신 인터페이스(230)는 다른 장치와 유선으로 통신하기 위해서, 다른 장치와 유선 케이블로 연결되기 위한 적어도 하나의 포트를 포함할 수 있다. 이 경우, 통신 인터페이스(230)는 적어도 하나의 포트를 통하여 유선 연결된 다른 장치와 통신을 수행할 수 있다. 일 실시예에 따르면, 통신 인터페이스(230)는 셀룰러 통신 모듈을 포함하여 셀룰러 네트워크(예: 3G, LTE, 5G, Wibro 또는 Wimax)에 연결되도록 구성될 수 있다. 일 실시예에 따르면, 통신 인터페이스(230)는 근거리 통신 모듈을 포함하여 근거리 통신(예: Wi-Fi, Bluetooth, Bluetooth Low Energy(BLE), UWB)을 이용해 다른 장치와 정보 송수신을 할 수 있다.
일 실시예에 따르면, 통신 인터페이스(230)는 비접촉식 통신을 위한 비접촉 통신 모듈을 포함할 수 있다. 비접촉식 통신은, 예를 들면, NFC(Near Field Communication) 통신, RFID(Radio Frequency Identification) 통신 또는 MST(Magnetic Secure Transmission) 통신과 같이 적어도 하나의 비접촉 방식의 근접 통신 기술을 포함할 수 있다. 전술한 다양한 예시들 외에도, 다른 장치와 통신하기 위한 공지된 다양한 방식으로 컴퓨팅 장치(200)가 구현될 수 있으며, 전술한 예시들에 의해 본 개시의 범위가 제한되지 않는다.
일 실시예에 따르면, 컴퓨팅 장치(200)는 디스플레이를 포함할 수 있다. 디스플레이는 프로세서(210)의 제어에 기반하여 다양한 화면(예: 하나 이상의 페이지)을 표시할 수 있다. 예를 들어, 컴퓨팅 장치(200)가 특정 화면을 표시하도록 하는 데이터를 수신한 경우, 프로세서(210)는 디스플레이로 하여금 특정 화면을 표시하도록 제어할 수 있다. 또한, 각종 인터페이스들이 적용된 화면을 디스플레이에 표시하기 위해서, 예를 들어, 웹 브라우저 또는 전용 애플리케이션이 컴퓨팅 장치(200)에 설치될 수 있다. 또한, 디스플레이는 사용자와 상호 작용이 가능한 구성으로서, 사용자로부터 사용자 입력을 수신할 수 있다. 이러한 디스플레이는, 다양한 외부 객체(예: 사용자의 손가락 또는 스타일러스)의 접촉 또는 근접을 인식할 수 있는 터치 센서 패널(Touch Sensor Panel, TSP)의 형태로 구현될 수 있다.
일 실시예에 따르면, 컴퓨팅 장치(200)는 입력 장치(예: 마우스 또는 키보드)를 포함할 수 있다. 입력 장치는 컴퓨팅 장치(200)의 구성요소에 사용될 정보를 컴퓨팅 장치(200)의 외부(예: 사용자)로부터 수신할 수 있다.
일 실시예에 따르면, 컴퓨팅 장치(200)는 카메라를 포함할 수 있다. 카메라는 대상체(object)를 촬영하여, 대상체에 대한 이미지를 생성할 수 있다. 또한, 카메라는 QR 코드, 2차원 바코드 등 식별 데이터를 인식하고, 식별 데이터에 인코딩된 데이터를 획득할 수 있다. 예를 들어, 아이템의 수취인 이름, 배송 완료 예상 시간, 운송장 번호, 박스 번호, 또는 배송지 주소 중 적어도 하나를 포함하는 배송 데이터가 해당 아이템의 식별 데이터에 인코딩된 경우, 카메라는 해당 아이템의 식별 데이터로부터 해당 아이템의 배송 데이터를 획득할 수 있다.
도 2에 도시된 프로세서(210), 메모리(220) 및 통신 인터페이스(230)는 버스(bus), GPIO(General Purpose Input/Output), SPI(Serial Peripheral Interface) 또는 MIPI(Mobile Industry Processor Interface) 등을 통해 서로 연결되어, 정보 또는 시그널을 주거나 받을 수 있다.
도 3은 본 개시의 일 실시예에 따른 배송원 단말기(110)가 배송 관리 애플리케이션을 실행하는 과정을 도시한 도면이다.
S310에서, 정상 모드의 배송원 단말기(110)는 데이터베이스(130)에 서버(120)의 장애 유무를 지시하는 장애 플래그를 쿼리할 수 있다. S310의 세부 단계로서, 배송원 단말기(110)는 아래의 동작을 수행할 수 있다.
일 실시예에 따르면, 정상 모드의 배송원 단말기(110)는 서버(120)에 배송 관리 애플리케이션에 대한 애플리케이션 데이터를 요청할 수 있다. 예를 들어, 애플리케이션 데이터는 배송원 단말기(110)의 배송원에게 할당된 하나 이상의 배송 대상 아이템을 포함하는 배송 목록, 배송 지도 등을 배송 관리 애플리케이션의 사용자 인터페이스의 일부분으로서 표출하도록 하는 데이터일 수 있다. 예를 들어, 애플리케이션 데이터는 배송원 단말기(110)의 배송원의 배송 목록, 배송 지도 등을 포함하는 온라인 페이지를 표출하도록 하는 데이터일 수 있다. 이어서, 배송원 단말기(110)는 서버(120)에 애플리케이션 데이터를 요청한 이후 미리 결정된 시간 동안 서버(120)의 응답을 모니터링할 수 있다. 미리 결정된 시간 동안 서버(120)의 응답을 수신하지 못한 것에 응답하여, 배송원 단말기(110)는 데이터베이스(130)에 서버(120)의 장애 유무를 지시하는 장애 플래그를 쿼리함으로써, 서버(120)에 장애가 발생하였는지 확인할 수 있다.
일 실시예에 따르면, 정상 모드의 배송원 단말기(110)가 서버(120)에 배송 관리 애플리케이션에 대한 애플리케이션 데이터를 요청할 수 있는 횟수가 미리 결정될 수 있다. 예를 들어, 배송원 단말기(110)는 서버(120)에 배송 관리 애플리케이션에 대한 애플리케이션 데이터를 요청할 수 있다. 배송원 단말기(110)는 서버(120)에 애플리케이션 데이터를 요청한 이후 미리 결정된 시간 동안 서버(120)의 응답을 모니터링할 수 있다. 미리 결정된 시간 동안 서버(120)의 응답을 수신하지 못한 것에 응답하여, 배송원 단말기(110)는 서버(120)에 애플리케이션 데이터를 재요청할 수 있다. 이어서, 배송원 단말기(1100는 서버(120)에 애플리케이션 데이터를 재요청한 이후 미리 결정된 시간 동안 서버(120)의 응답을 모니터링할 수 있다. 이와 같이, 배송원 단말기(110)는 서버(120)로부터 응답을 수신하지 못한 경우, 미리 결정된 횟수만큼 서버(120)에 애플리케이션 데이터를 요청할 수 있다. 미리 결정된 횟수만큼 서버(120)에 애플리케이션 데이터를 요청하였음에도 서버(120)로부터 응답을 수신하지 못한 것에 응답하여, 배송원 단말기(110)는 데이터베이스(130)에 서버(120)의 장애 유무를 지시하는 장애 플래그를 쿼리함으로써, 서버(120)에 장애가 발생하였는지 확인할 수 있다.
S320에서, 데이터베이스(130)는 배송원 단말기(110)에 장애 플래그를 반환할 수 있다. 즉, 배송원 단말기(110)는 데이터베이스(130)로부터 장애 플래그를 수신할 수 있다.
S330에서, 정상 모드의 배송원 단말기(110)는 장애 플래그에 기초하여, 장애 모드로의 전환 여부를 결정할 수 있다.
S340에서, 장애 플래그가 서버(120)에 장애가 없음을 지시하는 것에 응답하여, 정상 모드의 배송원 단말기(110)는 정상 모드를 유지할 수 있다. 이어서, S341에서, 정상 모드의 배송원 단말기(110)는 서버(120)에 배송 관리 애플리케이션에 대한 애플리케이션 데이터를 요청할 수 있다. S342에서, 정상 모드의 배송원 단말기(110)는 서버(120)로부터 배송 관리 애플리케이션에 대한 애플리케이션 데이터를 수신할 수 있다. 정상 모드의 배송원 단말기(110)는 서버(120)로부터 수신한 애플리케이션 데이터에 기초하여, 배송 관리 애플리케이션을 실행할 수 있다. 예를 들어, 정상 모드의 배송원 단말기(110)는 애플리케이션 데이터에 기초하여, 배송원 단말기(110)의 디스플레이 상에 배송원의 배송 목록, 배송 지도 등을 배송 관리 애플리케이션의 사용자 인터페이스의 일부분으로서 표출할 수 있다. 예를 들어, 정상 모드의 배송원 단말기(110)는 애플리케이션 데이터에 기초하여, 배송원 단말기(110)의 디스플레이 상에 배송원의 배송 목록, 배송 지도 등을 포함하는 온라인 페이지를 표출할 수 있다.
S350에서, 장애 플래그가 서버(120)에 장애가 있음을 지시하는 것에 응답하여, 정상 모드의 배송원 단말기(110)는 장애 모드로 전환할 수 있다. 이어서, S351에서, 장애 모드의 배송원 단말기(110)는 배송원 단말기(110)의 로컬 데이터베이스에 미리 저장된 배송 관련 데이터를 로드(load)하고, 로드한 배송 데이터에 기초하여 배송 관리 애플리케이션에 대한 임시(temporary) 애플리케이션 데이터를 생성할 수 있다. 여기서, 배송원 단말기(110)의 로컬 데이터베이스는 배송원 단말기(110)를 구현할 수 있는 컴퓨팅 장치(200)의 하나 이상의 메모리(220) 내 애플리케이션에 대해 할당된 공간에 구축되어 해당 애플리케이션의 실행에 필요한 데이터를 저장 및 관리하는 데이터베이스일 수 있다. 예를 들어, 배송 관련 데이터는 배송원 단말기(110)의 배송원에게 할당된 하나 이상의 배송 대상 아이템을 포함하는 배송 목록을 지시하는 배송 목록 데이터, 배송원의 배송 목록 내 배송 대상 아이템의 배송 완료를 지시하는 배송 완료 데이터, 배송원의 배송 목록 내 배송 대상 아이템의 위치, 개수, 배송 시간대 등에 대한 배송 마커가 표시된 배송 지도를 지시하는 배송 지도 데이터 등일 수 있다. 예를 들어, 임시 애플리케이션 데이터는 배송원 단말기(110)의 로컬 데이터베이스에서 로드한 배송 관련 데이터가 지시하는 배송원의 배송 목록, 배송 지도 등을 배송 관리 애플리케이션의 사용자 인터페이스의 일부분으로서 표출하도록 하는 데이터일 수 있다. 예를 들어, 임시 애플리케이션 데이터는 배송원 단말기(110)의 로컬 데이터베이스에서 로드한 배송 관련 데이터가 지시하는 배송원 단말기(110)의 배송원의 배송 목록, 배송 지도 등을 포함하는 오프라인 페이지를 표출하도록 하는 데이터일 수 있다. 장애 모드의 배송원 단말기(110)는 임시 애플리케이션 데이터에 기초하여, 배송 관리 애플리케이션을 실행할 수 있다. 예를 들어, 장애 모드의 배송원 단말기(110)는 임시 애플리케이션 데이터에 기초하여, 배송원 단말기(110)의 디스플레이 상에 배송원의 배송 목록, 배송 지도 등을 배송 관리 애플리케이션의 사용자 인터페이스의 일부분으로서 표출할 수 있다. 예를 들어, 장애 모드의 배송원 단말기(110)는 임시 애플리케이션 데이터에 기초하여, 배송원 단말기(110)의 디스플레이 상에 배송원의 배송 목록, 배송 지도 등을 포함하는 오프라인 페이지를 표출할 수 있다.
한편, 도 3은 배송원 단말기(110)가 정상 모드로 동작하는 도중 장애 플래그를 확인하여 정상 모드를 유지하거나 장애 모드로 전환하는 예시를 설명하였지만, 본 개시가 이에 제한되는 것은 아니다. 예를 들어, 배송원 단말기(110)가 장애 모드로 동작하는 도중 장애 플래그를 확인할 수 있다. 장애 플래그가 서버(120)에 장애가 있음을 지시하는 것에 응답하여, 장애 모드의 배송원 단말기(110)는 장애 모드를 유지하고, 임시 애플리케이션 데이터를 생성하여 배송 관리 애플리케이션을 오프라인으로 실행할 수 있다. 또는, 장애 플래그가 서버(120)에 장애가 없음을 지시하는 것에 응답하여, 장애 모드의 배송원 단말기(110)는 정상 모드로 전환하고, 서버(120)에 애플리케이션 데이터를 요청하고, 서버(120)로부터 애플리케이션 데이터를 수신하여 배송 관리 애플리케이션을 온라인으로 실행할 수 있다.
도 4는 본 개시의 일 실시예에 따른 장애 모드의 배송원 단말기(110)가 정상 모드로 전환하는 과정을 나타낸 도면이다.
S410에서, 장애 모드의 배송원 단말기(110)는 서버(120)로부터 서버(120)의 정상화 알림(notification)을 수신할 수 있다.
S420에서, 서버(120)의 정상화 알림을 수신한 것에 응답하여, 장애 모드의 배송원 단말기(110)는 정상 모드로 전환할 수 있다. 이어서, 정상 모드의 배송원 단말기(110)는 서버(120)에 애플리케이션 데이터를 요청하고, 서버(120)로부터 애플리케이션 데이터를 수신하여 배송 관리 애플리케이션을 온라인으로 실행할 수 있다.
도 3에서 설명한 바와 같이, 배송원 단말기(110)는 데이터베이스(130)에 저장된 장애 플래그를 기초로 서버(120)의 장애 유무를 확인할 수 있고, 또는 도 4에서 설명한 바와 같이 서버(120)로부터 직접 정상화 알림을 수신하여 서버(120)의 장애 유무를 확인할 수 있다.
도 5는 본 개시의 일 실시예에 따른 API(511, 512, 513, 514) 및 API 경로(551, 552, 553, 554) 간의 매핑 관계를 지시하는 매핑 데이터(500)를 나타낸 도면이다.
일 실시예에 따르면, 배송원 단말기(110)는 배송 관리 애플리케이션에 대한 API 세트(510) 내 적어도 일부의 API를 호출하고, API의 호출 결과를 기초로 배송 관리 애플리케이션을 실행할 수 있다. 한편, 정상 모드의 배송원 단말기(110)는 서버(120)에 데이터를 요청하는 API를 호출하여, 해당 API에 대한 호출 결과를 서버(120)로부터 정상적으로 수신할 수 있는 반면, 장애 모드의 배송원 단말기(110)는 장애가 있는 서버(120)에 데이터를 요청하는 API를 호출하더라도 해당 API에 대한 호출 결과를 서버(120)로부터 정상적으로 수신할 수 없다. 또한, 정상 모드의 배송원 단말기(110)는 서버(120)에 데이터를 전송하는 API를 호출하여, 해당 API에 대한 호출 결과로서 서버(120)가 해당 데이터를 수신하였음을 지시하는 응답(예: ACK)을 수신할 수 있는 반면, 장애 모드의 배송원 단말기(110)는 장애가 있는 서버(120)에 데이터를 전송하는 API를 호출하더라도 해당 API에 대한 호출 결과로서 서버(120)가 해당 데이터를 수신하였음을 지시하는 응답(예: ACK)을 수신할 수 없고, 이는 서버(120)를 향한 데이터의 전송이 누락되는 문제로 이어질 수 있다. 이러한 문제를 해결하기 위해서는, API에 대해, 정상 모드의 배송원 단말기(110)가 수행해야 하는 동작 및 장애 모드의 배송원 단말기(110)가 수행해야 하는 동작이 정의될 필요가 있을 수 있다.
일 실시예에 따르면, API 세트(510) 내 적어도 일부의 API는 API 경로 세트(550) 내 적어도 일부의 API 경로에 매핑될 수 있다. 이에 따라, 각 API에는 고유한 API 경로가 매핑될 수 있다. API 경로는 이와 매핑된 API에 대해 정상 모드의 배송원 단말기(110)가 수행해야 하는 동작 및 장애 모드의 배송원 단말기(110)가 수행해야 하는 동작을 지시할 수 있다. 도 5의 예시를 참조하면, API 1(511)은 API 경로 1(551), API 2(512)는 API 경로 2(552), API 3(513)은 API 경로 3(553), API 4(514)는 API 경로 4(554)에 매핑될 수 있다. API 경로 1(551)는 API 1(511)에 대해 정상 모드의 배송원 단말기(110)가 수행해야 하는 동작 및 장애 모드의 배송원 단말기(110)가 수행해야 하는 동작을 지시할 수 있다. API 경로 2(552)는 API 2(512)에 대해 정상 모드의 배송원 단말기(110)가 수행해야 하는 동작 및 장애 모드의 배송원 단말기(110)가 수행해야 하는 동작을 지시할 수 있다. API 경로 3(553)는 API 3(513)에 대해 정상 모드의 배송원 단말기(110)가 수행해야 하는 동작 및 장애 모드의 배송원 단말기(110)가 수행해야 하는 동작을 지시할 수 있다. API 경로 4(554)는 API 4(514)에 대해 정상 모드의 배송원 단말기(110)가 수행해야 하는 동작 및 장애 모드의 배송원 단말기(110)가 수행해야 하는 동작을 지시할 수 있다. 한편, 도 5에는 API 세트(510) 내 4개의 API(511, 512, 513, 514), API 경로 세트(550) 내 4개의 API 경로(551, 552, 553, 554)가 도시되었지만, 본 개시가 이에 제한되는 것은 아니다. 매핑 관계를 갖는 API 및 API 경로 각각의 개수는 본 개시의 실시예가 적용 가능한 범위 내에서 얼마든지 달라질 수 있다.
일 실시예에 따르면, 각 API 경로에는 유형(type)이 지정될 수 있다. 예를 들어, API 경로의 유형은 API의 호출 결과를 배송원 단말기(110)의 로컬 데이터베이스에 저장하는 "응답 저장(save response)", API의 호출 결과를 다른 미리 결정된 데이터로 대체하는 "더미(dummy)", API의 호출 결과를 무시하는 "무시(ignore)" 및 API의 호출 실패 시 실패 이력을 배송원 단말기(110)의 로컬 데이터베이스에 저장하고 해당 API를 재요청하는 "복구(recover)" 중 어느 하나일 수 있다.
일 실시예에 따르면, 매핑 데이터(500)는 API(511, 512, 513, 514) 및 API 경로(551,552, 553, 554) 간의 매핑 관계, API 경로의 유형 등을 지시할 수 있다. 예를 들어, 배송원 단말기(110)는 서버(120)로부터 매핑 데이터(500)를 수신하고, 매핑 데이터(500) 및 배송원 단말기(110)의 동작 모드를 기초로 API에 대한 동작을 수행할 수 있다. 대안적으로, 배송원 단말기(110)는 데이터베이스(130)에 매핑 데이터(500)를 쿼리하여, 데이터베이스(130)로부터 매핑 데이터(500)를 획득하고, 매핑 데이터(500) 및 배송원 단말기(110)의 동작 모드를 기초로 API에 대한 동작을 수행할 수 있다.
도 6은 본 개시의 일 실시예에 따른 API 경로에 매핑된 API에 대한 배송원 단말기(110)의 동작을 나타낸 도면이다. 이하, API 1(511)에 매핑된 API 경로 1(551)의 유형을 "응답 저장"으로 가정하여 설명한다.
일 실시예에 따르면, API 경로 1(551)에 매핑된 API 1(511)에 대해, 정상 모드의 배송원 단말기(110)가 수행해야 하는 동작 및 장애 모드의 배송원 단말기(110)가 수행해야 하는 동작이 다를 수 있다.
예를 들어, 배송원 단말기(110)의 동작 모드가 정상 모드인 경우, API 1(511)에 대해 정상 모드의 배송원 단말기(110)는 다음의 동작을 수행할 수 있다. S610에서, 정상 모드의 배송원 단말기(110)는 API 1(511)를 호출할 수 있다. 예를 들어, 정상 모드의 배송원 단말기(110)는 API 1(511)를 호출함으로써, 서버(120)에 API 1(511)과 관련된 데이터를 요청할 수 있다. S620에서, 정상 모드의 배송원 단말기(110)는 API 1(511)의 호출에 대한 응답(호출 결과)을 서버(120)로부터 수신할 수 있다. 예를 들어, 정상 모드의 배송원 단말기(110)는 API 1(511)의 호출에 대한 응답으로서 API 1(511)과 관련된 데이터를 서버(120)로부터 수신할 수 있다. S630에서, 정상 모드의 배송원 단말기(110)는 API 1(511)의 호출에 대한 응답을 저장할 수 있다. 예를 들어, 정상 모드의 배송원 단말기(110)는 배송원 단말기(110)의 로컬 데이터베이스에 API 1(511)의 호출에 대한 응답을 저장할 수 있다. 여기서, 배송원 단말기(110)의 로컬 데이터베이스에 API 1(511)의 과거 호출 결과가 저장되어 있는 경우, 정상 모드의 배송원 단말기(110)는 API 1(511)의 새로운 호출 결과를 과거 호출 결과에 덮어쓰거나(overwrite), 과거 호출 결과를 삭제하지 않고 유지하면서 새로운 호출 결과를 로컬 데이터베이스에 추가로 저장할 수 있다.
예를 들어, 배송원 단말기(110)의 동작 모드가 장애 모드인 경우, API 1(511)에 대해 장애 모드의 배송원 단말기(110)는 다음의 동작을 수행할 수 있다. S640에서, 장애 모드의 배송원 단말기(110)는 API 1(511)를 호출하여 API 1(511)과 관련된 데이터를 서버(120)에 요청하는 대신 배송원 단말기(110)의 로컬 데이터베이스 내에서 가장 마지막(최근)으로 저장된 API 1(511)의 호출 결과를 로드할 수 있다. 즉, "응답 저장" 유형의 API 경로 1(551)에 매핑된 API 1(511)에 대해, 정상 모드의 배송원 단말기(110)가 API 1(511)의 호출 결과를 배송원 단말기(110)의 로컬 데이터베이스에 저장해 둠으로써, 정상 모드의 배송원 단말기(110)가 장애 모드로 전환하더라도 로컬 데이터베이스에 저장되어 있는 API 1(511)의 호출 결과를 기초로 배송 관리 애플리케이션을 실행할 수 있게 된다.
일 실시예에 따르면, API 1(511)은 배송원 단말기(110)의 배송원에게 할당된 하나 이상의 배송 대상 아이템을 포함하는 배송 목록에 대한 배송 목록 데이터를 요청하는 API일 수 있다. 예를 들어, 배송원은 배송원 단말기(110)의 디스플레이에 표시된 배송 관리 애플리케이션의 배송 목록에 대한 사용자 인터페이스를 선택함으로써, 해당 배송원에게 할당된 하나 이상의 배송 대상 아이템을 포함하는 배송 목록을 요청할 수 있다.
예를 들어, 배송원 단말기(110)의 동작 모드가 정상 모드인 경우, 배송 목록 데이터를 요청하는 API 1(511)에 대해 정상 모드의 배송원 단말기(110)는 다음의 동작을 수행할 수 있다. S610에서, 배송원의 배송 목록 요청에 응답하여, 정상 모드의 배송원 단말기(110)는 API 1(511)를 호출하여 서버(120)에 배송원의 배송 목록 데이터를 요청할 수 있다. 이어서, S620에서, 정상 모드의 배송원 단말기(110)는 API 1(511)의 호출에 대한 응답으로서 서버(120)로부터 배송원의 배송 목록 데이터를 포함하는 애플리케이션 데이터를 수신할 수 있다. 정상 모드의 배송원 단말기(110)는 서버(120)로부터 수신한 애플리케이션 데이터에 기초하여, 해당 애플리케이션 데이터 내 배송 목록 데이터가 지시하는 배송원의 배송 목록을 포함하는 온라인 페이지를 생성하고, 배송원 단말기(110)의 디스플레이 상에 온라인 페이지를 표출할 수 있다. 추가적으로, S630에서, 정상 모드의 배송원 단말기(110)는 API 1(511)의 호출에 대한 응답으로서 서버(120)로부터 수신한 배송원의 배송 목록 데이터를 배송원 단말기(110)의 로컬 데이터베이스에 저장할 수 있다.
예를 들어, 배송원 단말기(110)의 동작 모드가 장애 모드인 경우, 배송 목록 데이터를 요청하는 API 1(511)에 대해 장애 모드의 배송원 단말기(110)는 다음의 동작을 수행할 수 있다. S640에서, 배송원의 배송 목록 요청에 응답하여, 장애 모드의 배송원 단말기(110)는 API 1(511)를 호출하여 배송원의 배송 목록 데이터를 서버(120)에 요청하는 대신 API 1(511)에 대한 호출 결과로서 배송원 단말기(110)의 로컬 데이터베이스 내에서 가장 마지막으로 저장된 배송원의 배송 목록 데이터를 로드할 수 있다. 장애 모드의 배송원 단말기(110)는 로컬 데이터베이스에서 로드한 배송원의 배송 목록 데이터를 기초로 임시 애플리케이션 데이터를 생성할 수 있다. 이어서, 장애 모드의 배송원 단말기(110)는 임시 애플리케이션 데이터에 기초하여, 임시 애플리케이션 데이터 내 배송 목록 데이터가 지시하는 배송원의 배송 목록을 포함하는 오프라인 페이지를 생성하고, 배송원 단말기(110)의 디스플레이 상에 오프라인 페이지를 표출할 수 있다.
도 7은 본 개시의 일 실시예에 따른 API 경로에 매핑된 API에 대한 배송원 단말기(110)의 동작을 나타낸 도면이다. 이하, API 2(512)에 매핑된 API 경로 2(552)의 유형을 "더미"로 가정하여 설명한다.
일 실시예에 따르면, API 경로 2(552)에 매핑된 API 2(512)에 대해, 정상 모드의 배송원 단말기(110)가 수행해야 하는 동작 및 장애 모드의 배송원 단말기(110)가 수행해야 하는 동작이 다를 수 있다.
예를 들어, 배송원 단말기(110)의 동작 모드가 정상 모드인 경우, API 2(512)에 대해 정상 모드의 배송원 단말기(110)는 다음의 동작을 수행할 수 있다. S710에서, 정상 모드의 배송원 단말기(110)는 API 2(512)를 호출할 수 있다. 예를 들어, 정상 모드의 배송원 단말기(110)는 API 2(512)를 호출함으로써, 서버(120)에 API 2(512)와 관련된 데이터를 요청할 수 있다. S720에서, 정상 모드의 배송원 단말기(110)는 API 2(512)의 호출에 대한 응답을 서버(120)로부터 수신할 수 있다. 예를 들어, 정상 모드의 배송원 단말기(110)는 API 2(512)의 호출에 대한 응답으로서 API 2(512)와 관련된 데이터를 서버(120)로부터 수신할 수 있다.
예를 들어, 배송원 단말기(110)의 동작 모드가 장애 모드인 경우, API 2(512)에 대해 장애 모드의 배송원 단말기(110)는 다음의 동작을 수행할 수 있다. S730에서, 장애 모드의 배송원 단말기(110)는 API 2(512)를 호출하여 API 2(512)와 관련된 데이터를 서버(120)에 요청하는 대신 배송원 단말기(110)의 로컬 데이터베이스 내에서 API 2(512)의 호출 결과를 대체하도록 미리 결정된 대체 데이터를 로드할 수 있다. 대안적으로, S730에서, 장애 모드의 배송원 단말기(110)는 API 2(512)를 호출하여 API 2(512)와 관련된 데이터를 서버(120)에 요청하는 대신 API 2(512)의 호출 결과를 대체할 대체 데이터를 생성할 수 있다. 여기서, API 2(512)의 호출 결과를 대체하는 대체 데이터는 배송 관리 애플리케이션에 대한 오프라인 페이지의 일부 영역 내에 배송 관리 애플리케이션의 사용자 인터페이스로서 표출되는 이미지 또는 텍스트 등을 구성하는 하나 이상의 데이터 값을 포함할 수 있다. 따라서, 장애 모드의 배송원 단말기(110)의 디스플레이 상에 표출된 오프라인 페이지의 일부 영역 내에 대체 데이터에 따른 이미지 또는 텍스트 등이 표출될 수 있다.
도 8은 본 개시의 일 실시예에 따른 API 경로에 매핑된 API에 대한 배송원 단말기(110)의 동작을 나타낸 도면이다. 이하, API 3(513)에 매핑된 API 경로 3(553)의 유형을 "무시"로 가정하여 설명한다.
일 실시예에 따르면, API 경로 3(553)에 매핑된 API 3(513)에 대해, 정상 모드의 배송원 단말기(110)가 수행해야 하는 동작 및 장애 모드의 배송원 단말기(110)가 수행해야 하는 동작이 다를 수 있다.
예를 들어, 배송원 단말기(110)의 동작 모드가 정상 모드인 경우, API 3(513)에 대해 정상 모드의 배송원 단말기(110)는 다음의 동작을 수행할 수 있다. S810에서, 정상 모드의 배송원 단말기(110)는 API 3(513)을 호출할 수 있다. 예를 들어, 정상 모드의 배송원 단말기(110)는 API 3(513)을 호출함으로써, 서버(120)에 API 3(513)과 관련된 데이터를 요청할 수 있다. S820에서, 정상 모드의 배송원 단말기(110)는 API 3(513)의 호출에 대한 응답을 서버(120)로부터 수신할 수 있다. 예를 들어, 정상 모드의 배송원 단말기(110)는 API 3(513)의 호출에 대한 응답으로서 API 3(513)과 관련된 데이터를 서버(120)로부터 수신할 수 있다.
예를 들어, 배송원 단말기(110)의 동작 모드가 장애 모드인 경우, API 3(513)에 대해 장애 모드의 배송원 단말기(110)는 API 3(513)과 관련된 동작을 생략(skip)할 수 있다. 즉, API 3(513)에 대해 장애 모드의 배송원 단말기(110)는 아무런 동작을 수행하지 않을 수 있다. 예를 들어, API 3(513)과 관련된 데이터는 배송 관리 애플리케이션의 실행에 필수적인 데이터가 아닐 수 있다.
도 9는 본 개시의 일 실시예에 따른 API 경로에 매핑된 API에 대한 배송원 단말기(110)의 동작을 나타낸 도면이다. 이하, API 4(514)에 매핑된 API 경로 4(554)의 유형을 "복구"로 가정하여 설명한다.
일 실시예에 따르면, API 경로 4(554)에 매핑된 API 4(514)에 대해, 정상 모드의 배송원 단말기(110)가 수행해야 하는 동작 및 장애 모드의 배송원 단말기(110)가 수행해야 하는 동작이 다를 수 있다.
예를 들어, 배송원 단말기(110)의 동작 모드가 정상 모드인 경우, API 4(514)에 대해 정상 모드의 배송원 단말기(110)는 다음의 동작을 수행할 수 있다. S910에서, 정상 모드의 배송원 단말기(110)는 API 4(514)를 호출할 수 있다. 예를 들어, 정상 모드의 배송원 단말기(110)는 API 4(514)를 호출함으로써, 서버(120)에 API 4(514)와 관련된 데이터를 전송할 수 있다. S920에서, 정상 모드의 배송원 단말기(110)는 API 4(514)의 호출에 대한 응답을 서버(120)로부터 수신할 수 있다. 예를 들어, 정상 모드의 배송원 단말기(110)는 API 4(514)의 호출에 대한 응답으로서, 서버(120)가 API 4(514)와 관련된 데이터를 수신하였음을 지시하는 응답(예: ACK)을 수신할 수 있다.
예를 들어, 배송원 단말기(110)의 동작 모드가 장애 모드인 경우, API 4(514)에 대해 장애 모드의 배송원 단말기(110)는 다음의 동작을 수행할 수 있다. S930에서, 장애 모드의 배송원 단말기(110)는 API 4(514)를 호출할 수 있다. 예를 들어, 장애 모드의 배송원 단말기(110)는 API 4(514)를 호출함으로써, 서버(120)에 API 4(514)와 관련된 데이터를 전송할 수 있다. 한편, 장애 모드의 배송원 단말기(110)는 API 4(514)를 호출하되 실제로는 서버(120)에 API 4(514)와 관련된 데이터를 전송하지 않을 수도 있다. 장애 모드의 배송원 단말기(110)는 서버(120)에 장애가 있기 때문에 API 4(514)의 호출에 대한 응답을 서버(120)로부터 수신하지 않을 수 있다. 이어서, S940에서, 장애 모드의 배송원 단말기(110)는 API 4(514)의 호출에 대한 응답을 수신하지 않은 것을 기초로 API 4(514)의 호출을 실패했다고 결정하고, API 4(514)의 호출에 대한 실패 이력을 저장할 수 있다. 여기서, API 4(514)의 호출에 대한 실패 이력은 API 4(514)의 호출 시간, API 4(514)와 관련된 데이터 등을 포함할 수 있다. 예를 들어, 장애 모드의 배송원 단말기(110)는 배송원 단말기(110)의 로컬 데이터베이스에 API 4(514)의 호출에 대한 실패 이력을 저장할 수 있다. 대안적으로, 서버(120)에 장애가 있는 경우 서버(120)가 API 4(514)와 관련된 데이터를 정상적으로 수신할 가능성이 낮으므로, 장애 모드의 배송원 단말기(110)는 S930에서 API 4(514)를 호출하지 않고, 곧바로 API 4(514)와 관련된 데이터를 저장할 수 있다. 예를 들어, 장애 모드의 배송원 단말기(110)는 API 4(514)를 호출하지 않고, 곧바로 배송원 단말기(110)의 로컬 데이터베이스에 API 4(514)와 관련된 데이터를 저장할 수 있다.
예를 들어, 배송원 단말기(110)의 동작 모드가 장애 모드에서 정상 모드로 전환하는 경우, API 4(514)에 대해 정상 모드의 배송원 단말기(110)는 다음의 동작을 수행할 수 있다. 장애 모드에서 정상 모드로 전환한 배송원 단말기(110)는 배송원 단말기(110)의 로컬 데이터베이스 내에 API 4(514)의 호출에 대한 실패 이력이 저장되어 있는지 여부를 결정할 수 있다. 배송원 단말기(110)의 로컬 데이터베이스 내에 API 4(514)의 호출에 대한 실패 이력이 저장되어 있다고 결정한 것에 응답하여, S950에서, 정상 모드의 배송원 단말기(110)는 API 4(514)를 재호출할 수 있다. 예를 들어, 정상 모드의 배송원 단말기(110)는 API 4(514)를 재호출함으로써, 서버(120)에 API 4(514)와 관련된 데이터를 전송할 수 있다. 이어서, S960에서, 정상 모드의 배송원 단말기(110)는 API 4(514)의 재호출에 대한 응답을 서버(120)로부터 수신할 수 있다. 예를 들어, 정상 모드의 배송원 단말기(110)는 API 4(514)의 재호출에 대한 응답으로서, 서버(120)가 API 4(514)와 관련된 데이터를 수신하였음을 지시하는 응답(예: ACK)을 수신할 수 있다.
일 실시예에 따르면, API 4(514)는 배송원 단말기(110)의 배송원의 배송 목록 내 배송 대상 아이템의 배송 완료를 지시하는 배송 완료 데이터를 전송하는 API일 수 있다. 예를 들어, 배송 완료 데이터는 배송 대상 아이템의 배송 완료 시간 및 해당 배송 완료 시간에서 해당 배송 대상 아이템의 배송 완료 상태를 나타내는 이미지를 포함할 수 있다. 여기서, 배송 완료 상태는 배송 완료된 배송 대상 아이템의 위치(예: 문 앞), 배송 대상 아이템의 위치를 식별하기 위한 기준이 되는 주변 물체 등을 지시할 수 있다. 예를 들어, 배송원은 배송 목록 내 배송 대상 아이템의 배송을 완료한 후, 배송원 단말기(110)의 카메라를 통해 배송 완료된 아이템의 배송 완료 상태를 촬영할 수 있다. 이어서, 배송원은 배송원 단말기(110)의 디스플레이에 표출된 배송 관리 애플리케이션의 배송 목록 내에서 배송 대상 아이템의 배송 완료 처리에 대한 사용자 인터페이스를 선택함으로써, 배송 대상 아이템의 배송 완료 처리를 요청할 수 있다.
예를 들어, 배송원 단말기(110)의 동작 모드가 정상 모드인 경우, 배송 완료 데이터를 전송하는 API 4(514)에 대해 정상 모드의 배송원 단말기(110)는 다음의 동작을 수행할 수 있다. S910에서, 배송원의 배송 대상 아이템의 배송 완료 처리 요청에 응답하여, 정상 모드의 배송원 단말기(110)는 API 4(514)를 호출하여 서버(120)에 배송 대상 아이템의 배송 완료 데이터를 전송할 수 있다. 이어서, S920에서, 정상 모드의 배송원 단말기(110)는 API 4(514)의 호출에 대한 응답으로서, 서버(120)가 배송 대상 아이템의 배송 완료 데이터를 수신하였음을 지시하는 응답(예: ACK)를 서버(120)로부터 수신할 수 있다. 이에 따라, 서버(120)는 배송 대상 아이템의 배송 완료 데이터에 포함된 배송 대상 아이템의 배송 완료 상태를 나타내는 이미지를 배송 대상 아이템의 수취인이 보유하는 단말기에 전송할 수 있다.
예를 들어, 배송원 단말기(110)의 동작 모드가 장애 모드인 경우, 배송 완료 데이터를 전송하는 API 4(514)에 대해 장애 모드의 배송원 단말기(110)는 다음의 동작을 수행할 수 있다. S930에서, 배송원의 배송 대상 아이템의 배송 완료 처리 요청에 응답하여, 장애 모드의 배송원 단말기(110)는 API 4(514)를 호출하여 서버(120)에 배송 대상 아이템의 배송 완료 데이터를 전송할 수 있다. 한편, 장애 모드의 배송원 단말기(110)는 배송원의 배송 대상 아이템의 배송 완료 처리 요청에 응답하여, API 4(514)를 호출하되 실제로는 서버(120)에 배송 대상 아이템의 배송 완료 데이터를 전송하지 않을 수도 있다. 장애 모드의 배송원 단말기(110)는 서버(120)에 장애가 있기 때문에 서버(120)가 배송 대상 아이템의 배송 완료 데이터를 수신하였음을 지시하는 응답(예: ACK)을 서버(120)로부터 수신하지 않을 수 있다. 이어서, S940에서, 장애 모드의 배송원 단말기(110)는 서버(120)가 배송 대상 아이템의 배송 완료 데이터를 수신하였음을 지시하는 응답(예: ACK)을 수신하지 않은 것을 기초로 API 4(514)의 호출을 실패했다고 결정하고, API 4(514)의 호출에 대한 실패 이력을 저장할 수 있다. 여기서, API 4(514)의 호출에 대한 실패 이력은 API 4(514)의 호출 시간, 배송 대상 아이템의 배송 완료 데이터 등을 포함할 수 있다. 예를 들어, 장애 모드의 배송원 단말기(110)는 배송원 단말기(110)의 로컬 데이터베이스에 API 4(514)의 호출에 대한 실패 이력을 저장할 수 있다. 대안적으로, 장애 모드의 배송원 단말기(110)는 S930에서 배송 완료 데이터를 전송하는 API 4(514)를 호출하지 않고, 곧바로 배송 완료 데이터를 저장할 수 있다. 예를 들어, 장애 모드의 배송원 단말기(110)는 배송 완료 데이터를 전송하는 API 4(514)를 호출하지 않고, 곧바로 배송원 단말기(110)의 로컬 데이터베이스에 배송 완료 데이터를 저장할 수 있다.
예를 들어, 배송원 단말기(110)의 동작 모드가 장애 모드에서 정상 모드로 전환하는 경우, 배송 완료 데이터를 전송하는 API 4(514)에 대해 정상 모드의 배송원 단말기(110)는 다음의 동작을 수행할 수 있다. 장애 모드에서 정상 모드로 전환한 배송원 단말기(110)는 배송원 단말기(110)의 로컬 데이터베이스 내에 API 4(514)의 호출에 대한 실패 이력이 저장되어 있는지 여부를 결정할 수 있다. 즉, 정상 모드의 배송원 단말기(110)는 배송원 단말기(110)의 로컬 데이터베이스 내에 API 4(514)의 호출에 대한 실패 이력을 식별할 수 있다. 배송원 단말기(110)의 로컬 데이터베이스 내에 API 4(514)의 호출에 대한 실패 이력이 저장되어 있다고 결정한 것에 응답하여, S950에서, 정상 모드의 배송원 단말기(110)는 API 4(514)를 재호출하여 API 4(514)의 호출에 대한 실패 이력을 기초로 배송 대상 아이템의 배송 완료 데이터를 서버(120)에 전송할 수 있다. 이어서, S960에서, 정상 모드의 배송원 단말기(110)는 API 4(514)의 재호출에 대한 응답으로서, 서버(120)가 배송 대상 아이템의 배송 완료 데이터를 수신하였음을 지시하는 응답(예: ACK)를 서버(120)로부터 수신할 수 있다. 이를 통해 서버(120)에 장애가 발생하여 정상적으로 전송되지 못한 배송 완료 데이터를 서버(120)가 복구된 후 자동으로 다시 전송하도록 하여, 배송원이 별도로 배송 완료 처리를 요청할 필요가 없게 하고, 배송 완료 처리가 누락되는 것을 방지할 수 있다.
도 10은 본 개시의 일 실시예에 따른 배송 관리 애플리케이션에 대한 온라인 페이지(1000)를 나타낸 도면이다.
일 실시예에 따르면, 정상 모드의 배송원 단말기(110)는 배송 관리 애플리케이션에 대한 애플리케이션 데이터를 서버(120)로부터 수신할 수 있다. 정상 모드의 배송원 단말기(110)는 수신한 애플리케이션 데이터를 기초로 배송 관리 애플리케이션에 대한 온라인 페이지(1000)를 생성할 수 있다. 이어서, 정상 모드의 배송원 단말기(110)는 온라인 페이지(1000)를 배송원 단말기(110)의 디스플레이 상에 표출할 수 있다.
일 실시예에 따르면, 온라인 페이지(1000)는 배송원 단말기(110)의 배송원에게 할당된 하나 이상의 배송 대상 아이템에 대한 배송 목록을 포함할 수 있다. 온라인 페이지(1000)에는, 배송원의 배송 목록 내 각 배송 대상 아이템에 대한 수취인 이름, 배송 유형, 배송 완료 예상 시간, 운송장 번호, 박스 번호, 배송지 주소, 배송 요청 사항, 배송 유의 사항 등이 포함될 수 있다. 여기서, 배송 유형은 당일 배송, 익일 새벽 배송, 익일 배송 및 2일 뒤 배송 중 어느 하나일 수 있다. 배송 요청 사항은 배송원이 배송 대상 아이템을 배송할 시 필수적으로 해야 하는 액션을 지시할 수 있다. 예를 들어, 배송 요청 사항은 배송지 주소에 대응하는 공간 내 수취인이 설정한 배송 대상 아이템의 배송 위치(예: 문 앞, 실내)에 아이템을 두는 액션을 지시할 수 있다. 배송 유의 사항은 배송원이 배송 대상 아이템을 배송할 시 벨 금지 여부, 배송지 주소에 대응하는 공간 내 반려견 유무 등을 지시할 수 있다.
도 11은 본 개시의 일 실시예에 따른 배송 관리 애플리케이션에 대한 오프라인 페이지(1100)를 나타낸 도면이다.
일 실시예에 따르면, 장애 모드의 배송원 단말기(110)는 배송원 단말기(110)의 로컬 데이터베이스에 미리 저장된 배송원의 배송 데이터를 로드하고, 로드한 배송 데이터를 기초로 배송 관리 애플리케이션에 대한 임시 애플리케이션 데이터를 생성할 수 있다. 장애 모드의 배송원 단말기(110)는 생성한 임시 애플리케이션 데이터를 기초로 배송 관리 애플리케이션에 대한 오프라인 페이지(1100)를 생성할 수 있다. 이어서, 장애 모드의 배송원 단말기(110)는 오프라인 페이지(1100)를 배송원 단말기(110)의 디스플레이 상에 표출할 수 있다.
일 실시예에 따르면, 오프라인 페이지(1100)는 배송원 단말기(110)의 배송원에게 할당된 하나 이상의 배송 대상 아이템에 대한 배송 목록을 포함할 수 있다. 오프라인 페이지(1100)에는, 배송원의 배송 목록 내 각 배송 대상 아이템에 대한 수취인 이름, 배송 유형, 배송 완료 예상 시간, 운송장 번호, 박스 번호, 배송지 주소, 배송 요청 사항, 배송 유의 사항 등이 포함될 수 있다. 추가적으로, 오프라인 페이지(1100)에는 배송 관리 애플리케이션의 삭제(예: 재설치) 또는 초기화(예: 캐시 삭제)에 대한 경고 알림(1110)을 포함할 수 있다. 장애 모드에서 배송원 단말기(110)가 처리한 배송 관련 데이터와 처리 이력은 단말기의 로컬 데이터베이스에 저장될 수 있다. 배송원 단말기(110)가 정상 모드로 전환된 후, 장애 모드 동안 처리한 배송 관련 데이터와 그 처리 이력을 서버(120)에 전송함으로써 실제 배송 현황과 서버(120)가 관리하는 배송 관리 시스템 상의 배송 현황 간 동기화가 이루어질 수 있다. 그러나, 배송원 단말기(110)의 로컬 데이터베이스가 삭제되거나 초기화될 경우, 이러한 동기화가 불가능해질 수 있다. 따라서, 오프라인 페이지(1100)에 배송 관리 애플리케이션의 삭제 또는 초기화에 대한 경고 알림(1110)을 포함시켜 배송원이 애플리케이션을 삭제하거나 초기화하지 않도록 방지할 수 있다.
도 12는 본 개시의 일 실시예에 따른 배송 대상 아이템의 배송 완료 데이터에 대한 배송원 단말기(110)의 동작을 나타낸 도면이다.
일 실시예에 따르면, 배송원은 배송 목록 내 배송 대상 아이템의 배송을 완료한 후, 배송원 단말기(110)의 카메라를 이용해 배송 대상 아이템의 배송 완료 상태를 촬영할 수 있다. 배송원 단말기(110)의 카메라는 배송 대상 아이템의 배송 완료 상태를 나타내는 이미지를 생성할 수 있다. 배송원 단말기(110)는 배송 대상 아이템의 배송 완료 시간 및 배송 대상 아이템의 배송 완료 상태를 나타내는 이미지를 포함하는 배송 완료 데이터를 생성할 수 있다. 이어서, 배송원은 배송원 단말기(110)의 디스플레이에 표출된 배송 관리 애플리케이션의 배송 목록 내에서 배송 대상 아이템의 배송 완료 처리에 대한 사용자 인터페이스를 선택함으로써, 배송 대상 아이템의 배송 완료 처리를 요청할 수 있다. 장애 모드의 배송원 단말기(110)는 배송원의 배송 대상 아이템의 배송 완료 처리 요청에 응답하여, 배송 대상 아이템의 배송 완료 데이터를 전송하는 API를 호출할 수 있다. 여기서, 배송 완료 데이터를 전송하는 API는 도 9의 API 경로 4(554)에 매핑된 API 4(514)에 대한 설명을 참조할 수 있다. 그러나, 서버(120)의 장애로 인해, 장애 모드의 배송원 단말기(110)는 배송 대상 아이템의 배송 완료 데이터를 전송하는 API의 호출을 실패할 수 있다. 장애 모드의 배송원 단말기(110)는 배송 대상 아이템의 배송 완료 데이터를 전송하는 API의 호출을 실패한 것에 응답하여, 배송 대상 아이템의 배송 완료 데이터를 큐(1200)에 저장할 수 있다. 대안적으로, 장애 모드의 배송원 단말기(110)는 배송 대상 아이템의 배송 완료 데이터를 전송하는 API를 호출하지 않고, 곧바로 배송 대상 아이템의 배송 완료 데이터를 큐(1200)에 저장할 수 있다. 여기서, 큐(1200)는 배송 완료 데이터를 임시로 저장하기 위해 할당된 공간일 수 있다. 예를 들어, 큐(1200)는 배송원 단말기(110)의 로컬 데이터베이스 내 배송 완료 데이터를 임시로 저장하기 위해 할당된 저장 공간일 수 있다. 대안적으로, 큐(1200)는 배송원 단말기(110)의 로컬 데이터베이스와는 별도의 저장 공간일 수 있다. 서버(120)의 장애가 복구되어 배송원 단말기(110)가 정상 모드로 전환한 경우, 배송원 단말기(110)는 큐(1200)에 저장된 배송 완료 데이터를 전송하는 API를 (재)호출함으로써, 배송원 단말기(110)가 장애 모드로 동작하는 동안 큐(1200)에 저장된 배송 완료 데이터를 서버(120)에 전송할 수 있다.
이하, 도 12의 예시를 참조하여 배송 대상 아이템의 배송 완료 데이터(1201, 1202, 1203, 1204, 1205)에 대한 배송원 단말기(110)의 동작을 설명한다. 한편, 도 12에는 5개의 서로 다른 배송 완료 데이터(1201, 1202, 1203, 1204, 1205)가 도시되었지만, 본 개시가 이에 제한되는 것은 아니다. 배송 완료 데이터의 개수는 본 개시의 실시예가 적용 가능한 범위 내에서 얼마든지 달라질 수 있다.
일 실시예에 따르면, 배송원은 배송 목록 내 배송 대상 아이템 1의 배송을 완료한 후, 배송원 단말기(110)의 카메라를 이용해 배송 대상 아이템 1의 배송 완료 상태를 촬영할 수 있다. 배송원 단말기(110)의 카메라는 배송 대상 아이템 1의 배송 완료 상태를 나타내는 이미지를 생성할 수 있다. 배송원 단말기(110)는 배송 대상 아이템 1의 배송 완료 시간 및 배송 대상 아이템 1의 배송 완료 상태를 나타내는 이미지를 포함하는 배송 완료 데이터 1(1201)을 생성할 수 있다. 이어서, 배송원은 배송원 단말기(110)의 디스플레이에 표출된 배송 관리 애플리케이션의 배송 목록 내에서 배송 대상 아이템 1의 배송 완료 처리에 대한 사용자 인터페이스를 선택함으로써, 배송 대상 아이템 1의 배송 완료 처리를 요청할 수 있다. 장애 모드의 배송원 단말기(110)는 배송원의 배송 대상 아이템 1의 배송 완료 처리 요청에 응답하여, 배송 완료 데이터 1(1201)을 전송하는 API를 호출할 수 있다. 이어서, 장애 모드의 배송원 단말기(110)는 배송 완료 데이터 1(1201)을 전송하는 API의 호출을 실패한 것에 응답하여, 배송 완료 데이터 1(1201)을 큐(1200)에 저장할 수 있다. 대안적으로, 장애 모드의 배송원 단말기(110)는 배송 완료 데이터 1(1201)을 전송하는 API를 호출하지 않고, 곧바로 배송 완료 데이터 1(1201)을 큐(1200)에 저장할 수 있다.
일 실시예에 따르면, 배송원은 배송 목록 내 배송 대상 아이템 2의 배송을 완료한 후, 배송원 단말기(110)의 카메라를 이용해 배송 대상 아이템 2의 배송 완료 상태를 촬영할 수 있다. 배송원 단말기(110)의 카메라는 배송 대상 아이템 2의 배송 완료 상태를 나타내는 이미지를 생성할 수 있다. 배송원 단말기(110)는 배송 대상 아이템 2의 배송 완료 시간 및 배송 대상 아이템 2의 배송 완료 상태를 나타내는 이미지를 포함하는 배송 완료 데이터 2(1202)를 생성할 수 있다. 이어서, 배송원은 배송원 단말기(110)의 디스플레이에 표출된 배송 관리 애플리케이션의 배송 목록 내에서 배송 대상 아이템 2의 배송 완료 처리에 대한 사용자 인터페이스를 선택함으로써, 배송 대상 아이템 2의 배송 완료 처리를 요청할 수 있다. 장애 모드의 배송원 단말기(110)는 배송원의 배송 대상 아이템 2의 배송 완료 처리 요청에 응답하여, 배송 완료 데이터 2(1202)를 전송하는 API를 호출할 수 있다. 이어서, 장애 모드의 배송원 단말기(110)는 배송 완료 데이터 2(1202)를 전송하는 API의 호출을 실패한 것에 응답하여, 배송 완료 데이터 2(1202)를 큐(1200)에 저장할 수 있다. 대안적으로, 장애 모드의 배송원 단말기(110)는 배송 완료 데이터 2(1202)를 전송하는 API를 호출하지 않고, 곧바로 배송 완료 데이터 2(1202)를 큐(1200)에 저장할 수 있다. 예를 들어, 큐(1200) 내에서 배송 완료 데이터 2(1202)는 배송 완료 데이터 1(1201) 다음 순서로 저장될 수 있다.
일 실시예에 따르면, 배송원은 배송 목록 내 배송 대상 아이템 3의 배송을 완료한 후, 배송원 단말기(110)의 카메라를 이용해 배송 대상 아이템 3의 배송 완료 상태를 촬영할 수 있다. 배송원 단말기(110)의 카메라는 배송 대상 아이템 3의 배송 완료 상태를 나타내는 이미지를 생성할 수 있다. 배송원 단말기(110)는 배송 대상 아이템 3의 배송 완료 시간 및 배송 대상 아이템 3의 배송 완료 상태를 나타내는 이미지를 포함하는 배송 완료 데이터 3(1203)을 생성할 수 있다. 이어서, 배송원은 배송원 단말기(110)의 디스플레이에 표출된 배송 관리 애플리케이션의 배송 목록 내에서 배송 대상 아이템 3의 배송 완료 처리에 대한 사용자 인터페이스를 선택함으로써, 배송 대상 아이템 3의 배송 완료 처리를 요청할 수 있다. 장애 모드의 배송원 단말기(110)는 배송원의 배송 대상 아이템 3의 배송 완료 처리 요청에 응답하여, 배송 완료 데이터 3(1203)를 전송하는 API를 호출할 수 있다. 이어서, 장애 모드의 배송원 단말기(110)는 배송 완료 데이터 3(1203)를 전송하는 API의 호출을 실패한 것에 응답하여, 배송 완료 데이터 3(1203)를 큐(1200)에 저장할 수 있다. 대안적으로, 장애 모드의 배송원 단말기(110)는 배송 완료 데이터 3(1203)을 전송하는 API를 호출하지 않고, 곧바로 배송 완료 데이터3(1203)을 큐(1200)에 저장할 수 있다. 예를 들어, 큐(1200) 내에서 배송 완료 데이터 3(1203)은 배송 완료 데이터 2(1202) 다음 순서로 저장될 수 있다.
일 실시예에 따르면, 배송원은 배송 목록 내 배송 대상 아이템 4의 배송을 완료한 후, 배송원 단말기(110)의 카메라를 이용해 배송 대상 아이템 4의 배송 완료 상태를 촬영할 수 있다. 배송원 단말기(110)의 카메라는 배송 대상 아이템 4의 배송 완료 상태를 나타내는 이미지를 생성할 수 있다. 배송원 단말기(110)는 배송 대상 아이템 4의 배송 완료 시간 및 배송 대상 아이템 4의 배송 완료 상태를 나타내는 이미지를 포함하는 배송 완료 데이터 4(1204)를 생성할 수 있다. 이어서, 배송원은 배송원 단말기(110)의 디스플레이에 표출된 배송 관리 애플리케이션의 배송 목록 내에서 배송 대상 아이템 4의 배송 완료 처리에 대한 사용자 인터페이스를 선택함으로써, 배송 대상 아이템 4의 배송 완료 처리를 요청할 수 있다. 장애 모드의 배송원 단말기(110)는 배송원의 배송 대상 아이템 4의 배송 완료 처리 요청에 응답하여, 배송 완료 데이터 4(1204)를 전송하는 API를 호출할 수 있다. 이어서, 장애 모드의 배송원 단말기(110)는 배송 완료 데이터 4(1204)를 전송하는 API의 호출을 실패한 것에 응답하여, 배송 완료 데이터 4(1204)를 큐(1200)에 저장할 수 있다. 대안적으로, 장애 모드의 배송원 단말기(110)는 배송 완료 데이터 4(1204)를 전송하는 API를 호출하지 않고, 곧바로 배송 완료 데이터 4(1204)를 큐(1200)에 저장할 수 있다. 예를 들어, 큐(1200) 내에서 배송 완료 데이터 4(1204)는 배송 완료 데이터 3(1203) 다음 순서로 저장될 수 있다.
일 실시예에 따르면, 배송원은 배송 목록 내 배송 대상 아이템 5의 배송을 완료한 후, 배송원 단말기(110)의 카메라를 이용해 배송 대상 아이템 5의 배송 완료 상태를 촬영할 수 있다. 배송원 단말기(110)의 카메라는 배송 대상 아이템 5의 배송 완료 상태를 나타내는 이미지를 생성할 수 있다. 배송원 단말기(110)는 배송 대상 아이템 5의 배송 완료 시간 및 배송 대상 아이템 5의 배송 완료 상태를 나타내는 이미지를 포함하는 배송 완료 데이터 5(1205)를 생성할 수 있다. 이어서, 배송원은 배송원 단말기(110)의 디스플레이에 표출된 배송 관리 애플리케이션의 배송 목록 내에서 배송 대상 아이템 5의 배송 완료 처리에 대한 사용자 인터페이스를 선택함으로써, 배송 대상 아이템 5의 배송 완료 처리를 요청할 수 있다. 장애 모드의 배송원 단말기(110)는 배송원의 배송 대상 아이템 5의 배송 완료 처리 요청에 응답하여, 배송 완료 데이터 5(1205)를 전송하는 API를 호출할 수 있다. 이어서, 장애 모드의 배송원 단말기(110)는 배송 완료 데이터 5(1205)를 전송하는 API의 호출을 실패한 것에 응답하여, 배송 완료 데이터 5(1205)를 큐(1200)에 저장할 수 있다. 대안적으로, 장애 모드의 배송원 단말기(110)는 배송 완료 데이터 5(1205)를 전송하는 API를 호출하지 않고, 곧바로 배송 완료 데이터 5(1205)를 큐(1200)에 저장할 수 있다. 예를 들어, 큐(1200) 내에서 배송 완료 데이터 5(1205)는 배송 완료 데이터 4(1204) 다음 순서로 저장될 수 있다.
일 실시예에 따르면, 장애 모드의 배송원 단말기(110)는 정상 모드로 전환할 수 있다. 예를 들어, 장애 모드의 배송원 단말기(110)는 데이터베이스(130)로부터 획득한 장애 플래그가 서버(120)에 장애가 없음을 지시하는 것에 응답하여, 정상 모드로 전환할 수 있다. 또는, 장애 모드의 배송원 단말기(110)는 서버(120)로부터 서버(120)의 정상화 알림을 수신한 것에 응답하여, 정상 모드로 전환할 수 있다. 정상 모드의 배송원 단말기(110)는 큐(1200)에 저장된 배송 완료 데이터(1201, 1202, 1203, 1204, 1205)를 서버(120)에 전송하기 위해 아래의 동작을 수행할 수 있다.
예를 들어, 정상 모드의 배송원 단말기(110)는 큐(1200)에 먼저 저장된 순서로 순차적으로 배송 완료 데이터(1201, 1202, 1203, 1204, 1205)를 전송하는 API를 호출할 수 있다. 즉, 정상 모드의 배송원 단말기(110)는 큐(1200)에 저장된 순서에 따라 배송 완료 데이터 1(1201)을 전송하는 API, 배송 완료 데이터 2(1202)를 전송하는 API, 배송 완료 데이터 3(1203)을 전송하는 API, 배송 완료 데이터 4(1204)를 전송하는 API 및 배송 완료 데이터 5(1205)를 전송하는 API를 순차적으로 호출할 수 있다.
대안적으로, 예를 들어, 정상 모드의 배송원 단말기(110)는 큐(1200)에 저장된 배송 완료 데이터(1201, 1202, 1203, 1204, 1205) 중 데이터 크기가 작은 배송 완료 데이터를 전송하는 API를 우선적으로 호출할 수 있다. 여기서, 데이터 크기는 배송 완료 데이터에 포함된 이미지를 구성하는 비트의 길이일 수 있다. 예를 들어, 큐(1200)에 저장된 배송 완료 데이터 4(1204)의 데이터 크기가 배송 완료 데이터 1(1201)의 데이터 크기보다 작은 경우, 정상 모드의 배송원 단말기(110)는 배송 완료 데이터 1(1201)을 전송하는 API 보다 배송 완료 데이터 4(1204)를 전송하는 API를 먼저 호출할 수 있다. 서버(120)가 장애에서 복구되면, 많은 배송원 단말기(110)가 서버(120)에 데이터를 전송하게 되어 서버(120)에 데이터가 집중될 수 있다. 이때, 데이터 크기가 작은 데이터부터 우선적으로 서버(120)에 전송함으로써 서버(120)에 과부하가 생기는 것을 방지할 수 있다.
예를 들어, 정상 모드의 배송원 단말기(110)는 큐(1200)에 저장된 배송 완료 데이터(1201, 1202, 1203, 1204, 1205) 중 특정 상품 카테고리에 속한 아이템의 배송 완료 상태를 나타내는 이미지를 포함하는 배송 완료 데이터를 전송하는 API를 우선적으로 호출할 수 있다. 예를 들어, 큐(1200)에 저장된 배송 완료 데이터(1201, 1202, 1203, 1204, 1205) 중 특정 상품 카테고리에 속한 아이템의 배송 완료 상태를 나타내는 이미지를 포함하는 배송 완료 데이터가 배송 완료 데이터 3(1203)인 경우, 정상 모드의 배송원 단말기(110)는 배송 완료 데이터 3(1203)을 전송하는 API를 가장 먼저 호출할 수 있다.
예를 들어, 정상 모드의 배송원 단말기(110)는 큐(1200)에 저장된 배송 완료 데이터(1201, 1202, 1203, 1204, 1205) 중 신선 상품의 배송 완료 상태를 나타내는 이미지를 포함하는 배송 완료 데이터를 전송하는 API를 우선적으로 호출할 수 있다. 예를 들어, 큐(1200)에 저장된 배송 완료 데이터(1201, 1202, 1203, 1204, 1205) 중 신선 상품의 배송 완료 상태를 나타내는 이미지를 포함하는 배송 완료 데이터가 배송 완료 데이터 5(1205)인 경우, 정상 모드의 배송원 단말기(110)는 배송 완료 데이터 5(1205)를 전송하는 API를 가장 먼저 호출할 수 있다. 상하기 쉬운 신선 상품의 특성상, 수취인이 배송 완료된 신선 상품을 신속히 수거할 필요가 있다. 이를 위해, 신선 상품의 배송 완료 상태를 나타내는 이미지를 포함하는 배송 완료 데이터를 우선적으로 서버(120)에 전송하고, 서버(120)가 수취인의 단말기에 신선 상품의 배송 완료 상태를 빠르게 제공할 수 있도록 할 수 있다.
예를 들어, 정상 모드의 배송원 단말기(110)는 큐(1200)에 저장된 배송 완료 데이터(1201, 1202, 1203, 1204, 1205) 중 특정 배송 유형에 따라 배송된 아이템의 배송 완료 상태를 나타내는 이미지를 포함하는 배송 완료 데이터를 전송하는 API를 우선적으로 호출할 수 있다. 여기서, 특정 배송 유형은 익일 새벽 배송일 수 있다. 예를 들어, 큐(1200)에 저장된 배송 완료 데이터(1201, 1202, 1203, 1204, 1205) 중 특정 배송 유형에 따라 배송된 아이템의 배송 완료 상태를 나타내는 이미지를 포함하는 배송 완료 데이터가 배송 완료 데이터 2(1202)인 경우, 정상 모드의 배송원 단말기(110)는 배송 완료 데이터 2(1202)를 전송하는 API를 가장 먼저 호출할 수 있다.
한편, 전술한 예시에서는 정상 모드의 배송원 단말기(110)가 큐(1200)에 저장된 배송 완료 데이터(1201, 1202, 1203, 1204, 1205)를 개별적으로 서버(120)에 전송하지만, 본 개시가 이에 반드시 제한되는 것은 아니다. 예를 들어, 정상 모드의 배송원 단말기(110)는 큐(1200)에 저장된 모든 배송 완료 데이터(1201, 1202, 1203, 1204, 1205)를 미리 결정된 데이터 컨테이너(container)에 포함시키고, 이 데이터 컨테이너를 서버(120)에 전송함으로써, 큐(1200)에 저장된 모든 배송 완료 데이터(1201, 1202, 1203, 1204, 1205)를 동시에 전송할 수도 있다.
도 13은 본 개시의 일 실시예에 따른 장애 모드의 배송원 단말기(110)가 아이템(1310)에 대한 식별 데이터(1320)를 스캔하여 배송 목록(1300)을 업데이트하는 과정을 나타낸 도면이다.
일 실시예에 따르면, 배송원 단말기(110)의 배송원의 배송 목록에 포함되지 않은 아이템(1310)은 식별 데이터(1320)를 가질 수 있다. 예를 들어, 아이템(1310)의 일부분에 식별 데이터(1320)가 아이템(1310)을 식별하기 위한 QR 코드 또는 2차원 바코드로서 부착(인쇄)되어 있을 수 있다. 또는, 아이템(1310)의 포장재(박스)의 일부분에 식별 데이터(1320)가 QR 코드 또는 2차원 바코드로서 부착(인쇄)되어 있을 수 있다. 예를 들어, 식별 데이터(1320)는 아이템(1310)에 대한 임시 배송 데이터(1325)를 포함할 수 있다. 예를 들어, 임시 배송 데이터(1325)는 수취인 이름, 배송 완료 예상 시간, 운송장 번호, 박스 번호, 배송지 주소 등을 포함할 수 있다. 예를 들어, 임시 배송 데이터(1325)는 식별 데이터(1320)에 의해 인코딩된 데이터일 수 있다. 즉, 아이템(1310)의 일부분 또는 아이템(1310)의 포장재(박스)의 일부분에 식별 데이터(1320)가 QR 코드 또는 2차원 바코드로서 시각적으로 표시되지만, 식별 데이터(1320)에 포함된 임시 배송 데이터(1325)는 시각적으로 표시되지 않으며, 식별 데이터(1320)를 스캔해야만 임시 배송 데이터(1325)를 획득할 수 있도록 임시 배송 데이터(1325)는 식별 데이터(1320)에 의해 인코딩될 수 있다.
일 실시예에 따르면, 배송원은 장애 모드의 배송원 단말기(110)의 카메라를 이용해 배송원의 배송 목록에 포함되지 않은 아이템(1310)의 식별 데이터(1320)를 스캔할 수 있다. 장애 모드의 배송원 단말기(110)는 카메라를 통해 스캔한 식별 데이터(1320)를 획득하고, 식별 데이터(1320)를 기초로 아이템(1310)에 대한 임시 배송 데이터(1325)를 획득할 수 있다. 즉, 장애 모드의 배송원 단말기(110)는 식별 데이터(1320)를 디코딩하여 식별 데이터(1320)에 포함된 아이템(1310)에 대한 임시 배송 데이터(1325)를 획득할 수 있다. 이어서, 장애 모드의 배송원 단말기(110)는 아이템(1310)에 대한 임시 배송 데이터(1325)에 기초하여, 아이템(1310)이 배송원의 배송 목록(1300)에 포함되도록 배송 목록 데이터를 업데이트할 수 있다. 이를 통해, 오프라인에서도 배송원의 배송 목록(1300)에 배송 대상 아이템을 새롭게 추가할 수 있다.
도 14는 본 개시의 일 실시예에 따른 장애 모드의 배송원 단말기(110)가 아이템(1410)에 대한 식별 데이터(1420)를 스캔하여 배송 목록(1400)을 업데이트하는 과정을 나타낸 도면이다.
일 실시예에 따르면, 아이템(1410)은 식별 데이터(1420)를 가질 수 있다. 예를 들어, 아이템(1410)의 일부분에 식별 데이터(1420)가 아이템(1410)을 식별하기 위한 QR 코드 또는 2차원 바코드로서 부착(인쇄)되어 있을 수 있다. 또는, 아이템(1410)의 포장재(박스)의 일부분에 식별 데이터(1420)가 QR 코드 또는 2차원 바코드로서 부착(인쇄)되어 있을 수 있다. 예를 들어, 식별 데이터(1420)는 아이템(1410)에 대한 임시 배송 데이터(1425)를 포함할 수 있다. 예를 들어, 임시 배송 데이터(1425)는 수취인 이름, 배송 완료 예상 시간, 운송장 번호, 박스 번호, 배송지 주소 등을 포함할 수 있다. 즉, 아이템(1410)의 일부분 또는 아이템(1410)의 포장재(박스)의 일부분에 식별 데이터(1420)가 QR 코드 또는 2차원 바코드로서 시각적으로 표시되지만, 식별 데이터(1420)에 포함된 임시 배송 데이터(1425)는 시각적으로 표시되지 않으며, 식별 데이터(1420)를 스캔해야만 임시 배송 데이터(1425)를 획득할 수 있도록 임시 배송 데이터(1425)는 식별 데이터(1420)에 의해 인코딩될 수 있다.
일 실시예에 따르면, 배송원은 장애 모드의 배송원 단말기(110)의 카메라를 이용해 아이템(1410)의 식별 데이터(1420)를 스캔할 수 있다. 장애 모드의 배송원 단말기(110)는 카메라를 통해 스캔한 식별 데이터(1420)를 획득하고, 식별 데이터(1420)를 기초로 아이템(1410)에 대한 임시 배송 데이터(1425)를 획득할 수 있다. 즉, 장애 모드의 배송원 단말기(110)는 식별 데이터(1420)를 디코딩하여 식별 데이터(1420)에 포함된 아이템(1410)에 대한 임시 배송 데이터(1425)를 획득할 수 있다. 이어서, 장애 모드의 배송원 단말기(110)는 아이템(1410)에 대한 임시 배송 데이터(1425)에 기초하여, 아이템(1410)이 이미 배송 목록(1400)에 포함되어 있고, 스캔 대상 목록 내 아이템 중 하나인지 결정할 수 있다. 여기서, 스캔 대상 목록은 배송 목록(1400) 내 복수의 아이템 중 배송원의 운송 수단(예: 차량)에 적재되기 전에 배송원에 의해 스캔될 필요가 있는 하나 이상의 아이템을 포함할 수 있다. 예를 들어, 아이템(1410)이 이미 배송 목록(1400)에 포함되어 있고, 스캔 대상 목록 내 아이템 중 하나라고 결정한 것에 응답하여, 장애 모드의 배송원 단말기(110)는 배송 목록(1400) 내 아이템(1410)이 스캔 완료 상태로 표시되도록 배송 목록 데이터를 업데이트할 수 있다. 예를 들어, 아이템(1410)이 배송 목록(1400)에 포함되어 있지 않다고 결정한 것에 응답하여, 장애 모드의 배송원 단말기(110)는 아이템(1410)에 대한 임시 배송 데이터(1425)에 기초하여, 아이템(1410)이 배송원의 배송 목록(1400)에 포함되도록 배송 목록 데이터를 업데이트할 수 있다. 이 경우, 배송 목록(1400)에 추가된 아이템(1410)은 자동으로 스캔 완료 상태로 표시될 수 있다. 예를 들어, 아이템(1410)이 이미 배송 목록(1400)에 포함되어 있고, 스캔 대상 목록 내 아이템 중 하나가 아닌 경우(이미 스캔 완료 상태인 경우), 장애 모드의 배송원 단말기(110)는 아이템(1410)에 대해 별도 동작을 수행하지 않을 수 있다.
도 15는 본 개시의 일 실시예에 따른 장애 모드의 배송원 단말기에 의해 업데이트된 배송 목록(1510)을 포함하는 오프라인 페이지(1500)를 나타낸 도면이다.
일 실시예에 따르면, 장애 모드의 배송원 단말기(110)는 배송 목록에 포함되지 않은 아이템의 식별 데이터를 스캔하여, 해당 아이템에 대한 임시 배송 데이터를 획득하고, 임시 배송 데이터를 기초로 배송 목록에 대한 배송 목록 데이터를 업데이트할 수 있다. 장애 모드의 배송원 단말기(110)는 업데이트된 배송 목록 데이터에 기초하여, 배송 관리 애플리케이션에 대한 임시 애플리케이션 데이터를 업데이트할 수 있다. 장애 모드의 배송원 단말기(110)는 업데이트된 임시 애플리케이션 데이터에 기초하여, 배송 관리 애플리케이션에 대한 오프라인 페이지(1500)를 생성할 수 있다. 이어서, 장애 모드의 배송원 단말기(110)는 오프라인 페이지(1500)를 배송원 단말기(110)의 디스플레이 상에 표출할 수 있다.
일 실시예에 따르면, 오프라인 페이지(1500)는 업데이트된 배송 목록(1510)을 포함할 수 있다. 오프라인 페이지(1500)에는, 배송 목록(1510)에 추가된 아이템에 대한 수취인 이름(1511), 배송 완료 예상 시간(1512), 배송지 주소(1513), 운송장 번호(1514), 박스 번호(1515) 등이 포함될 수 있다. 여기서, 오프라인 페이지(1500) 내 수취인 이름(1511), 배송 완료 예상 시간(1512), 배송지 주소(1513), 운송장 번호(1514), 박스 번호(1515) 등은 배송 목록(1510)에 추가된 아이템에 대한 임시 배송 데이터에 포함된 것과 동일할 수 있다.
도 16은 본 개시의 일 실시예에 따른 오프라인으로 배송 관리 애플리케이션을 위한 배송 관련 데이터를 처리하는 방법(1600)을 나타낸 도면이다.
일 실시예에 따르면, 방법(1600)은 배송원 단말기(110)를 구현할 수 있는 하나 이상의 컴퓨팅 장치(200)를 구비한 전자 장치에 의해 수행될 수 있다. 이하, 전자 장치에 의해 수행되는 것으로 설명되는 동작은 배송원 단말기(110) 또는 배송원 단말기(110)를 구현할 수 있는 컴퓨팅 장치(200)의 프로세스(210)에 의해 수행되는 것으로 표현될 수도 있다.
S1610에서, 전자 장치는 정상 모드에서 배송 관리 애플리케이션의 서버(120)에 대한 장애 유무를 지시하는 장애 플래그를 획득할 수 있다. S1610의 세부 단계로서, 전자 장치는 아래의 동작을 수행할 수 있다.
일 실시예에 따르면, 전자 장치는 정상 모드에서 데이터베이스(130)에 서버(120)의 장애 유무를 지시하는 장애 플래그에 대한 요청을 전송할 수 있다. 이어서, 전자 장치는 데이터베이스(130)로부터 장애 플래그를 수신할 수 있다.
S1620에서, 전자 장치는 장애 플래그가 서버(120)에 장애가 있음을 지시하는 것에 응답하여, 정상 모드에서 장애 모드로 전환할 수 있다.
S1630에서, 전자 장치는 장애 모드에서 전자 장치의 로컬 데이터베이스 내에 미리 저장된 배송 목록 데이터를 로드할 수 있다. 여기서, 배송 목록 데이터는 배송원에게 할당된 하나 이상의 배송 대상 아이템을 포함하는 배송 목록을 지시할 수 있다. S1630의 세부 단계로서, 전자 장치는 아래의 동작을 수행할 수 있다.
일 실시예에 따르면, 전자 장치는 장애 모드에서 배송 관리 애플리케이션에 대한 복수의 API 중에서 배송 목록 데이터를 요청하기 위한 특정 API를 식별할 수 있다. 이어서, 전자 장치는 특정 API에 대한 호출 결과로서 로컬 데이터베이스 내에서 가장 마지막으로 저장된 배송 목록 데이터를 로드할 수 있다.
S1640에서, 전자 장치는 장애 모드에서 배송 목록 데이터에 기초하여, 배송 관리 애플리케이션에 대한 임시 애플리케이션 데이터를 생성할 수 있다. 이어서, 전자 장치는 장애 모드에서 임시 애플리케이션 데이터에 기초하여, 배송 관리 애플리케이션에 대한 오프라인 페이지를 생성할 수 있다. 여기서, 오프라인 페이지는 배송 목록 데이터가 지시하는 배송 목록 및 배송 관리 애플리케이션의 초기화에 대한 경고 알림을 포함할 수 있다. 전자 장치는 장애 모드에서 전자 장치의 디스플레이에 오프라인 페이지를 표출할 수 있다.
본 개시에 따른 방법들은 컴퓨터 내지 프로세서를 가지는 장치로 구현된 방법들일 수 있다. 본 개시에서, 해당 방법들의 각 단계가 소정의 순서대로 도시되고 설명되었지만, 각 단계들은 순차적으로 수행되는 것 이외에, 본 개시에 따라 임의로 조합될 수 있는 순서로 수행될 수도 있다. 일 실시예에 따르면, 적어도 일부의 단계가 병렬적, 반복적 또는 휴리스틱하게 수행될 수 있다. 본 개시는 해당 방법들에 변화 또는 수정을 가하는 것을 제외하지 않는다. 일 실시예에 따르면, 적어도 일부의 단계가 생략되거나, 다른 단계가 추가될 수 있다.
본 개시의 다양한 실시예들은 기기(machine)가 읽을 수 있는 기록 매체(machine-readable recording medium)에 기록된 소프트웨어로 구현될 수 있다. 소프트웨어는 상술한 본 개시의 다양한 실시예들을 구현하기 위한 소프트웨어일 수 있다. 소프트웨어는 본 개시가 속하는 기술분야의 프로그래머들에 의해 본 개시의 다양한 실시예들로부터 추론될 수 있다. 예를 들어 소프트웨어는 기기가 읽을 수 있는 명령어(예: 코드 또는 코드 세그먼트) 또는 프로그램일 수 있다. 기기는 기록 매체로부터 호출된 명령어에 따라 동작이 가능한 장치로서, 예를 들어 컴퓨터일 수 있다. 일 실시예에 따르면, 기기는 본 개시의 실시예들에 따른 컴퓨팅 장치(200)일 수 있다. 일 실시예에 따르면, 기기의 프로세서는 호출된 명령어를 실행하여, 기기의 구성요소들이 해당 명령어에 해당하는 기능을 수행하게 할 수 있다. 일 실시예에 따르면, 프로세서는 본 개시의 실시예들에 따른 프로세서(210)일 수 있다. 기록 매체는 기기에 의해 읽혀질 수 있는, 데이터가 저장되는 기록 매체(recording medium)를 의미할 수 있다. 기록 매체는, 예를 들어 ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광 데이터 저장 장치 등을 포함할 수 있다. 일 실시예에 따르면, 기록 매체는 메모리(220)일 수 있다. 일 실시예에 따르면, 기록 매체는 네트워크로 연결된 컴퓨터 시스템 등에 분산된 형태로서 구현될 수도 있다. 소프트웨어는 컴퓨터 시스템 등에 분산되어 저장되고, 실행될 수 있다. 기록 매체는 비일시적(non-transitory) 기록 매체일 수 있다. 비일시적 기록 매체는, 데이터가 반영구적 또는 임시적으로 저장되는 것과 무관하게 실재하는 매체(tangible medium)를 의미하며, 일시적(transitory)으로 전파되는 신호(signal)를 포함하지 않는다.
이상 다양한 실시예들에 의해 본 개시의 기술적 사상이 설명되었지만, 본 개시의 기술적 사상은 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자가 이해할 수 있는 범위에서 이루어질 수 있는 다양한 치환, 변형 및 변경을 포함한다. 또한, 그러한 치환, 변형 및 변경은 첨부된 청구범위 내에 포함될 수 있는 것으로 이해되어야 한다. 본 개시에 따른 실시예들은 서로 조합될 수 있다. 각 실시예들은 경우의 수에 따라 다양하게 조합될 수 있으며, 조합되어 만들어진 실시예 역시 본 개시의 범위에 속한다.

Claims (15)

  1. 전자 장치에 의해 수행되는 방법에 있어서,
    정상 모드에서, 배송 관리 애플리케이션의 서버에 대한 장애(incident) 유무를 지시하는 장애 플래그(flag)를 획득하는 단계;
    상기 장애 플래그가 상기 서버에 장애가 있음을 지시하는 것에 응답하여, 상기 정상 모드에서 장애 모드로 전환하는 단계;
    상기 장애 모드에서, 상기 전자 장치의 로컬 데이터베이스 내에 미리 저장된 배송 목록 데이터를 로드하는 단계 - 상기 배송 목록 데이터는 배송원에게 할당된 하나 이상의 배송 대상 아이템을 포함하는 배송 목록을 지시함 -; 및
    상기 장애 모드에서, 상기 배송 목록 데이터에 기초하여, 상기 배송 관리 애플리케이션에 대한 임시 애플리케이션 데이터를 생성하는 단계를 포함하는, 방법.
  2. 제1항에 있어서,
    상기 정상 모드에서, 상기 배송 관리 애플리케이션의 상기 서버에 대한 장애 유무를 지시하는 상기 장애 플래그를 획득하는 단계는,
    상기 배송 관리 애플리케이션과 연동된 데이터베이스에 상기 장애 플래그에 대한 요청을 전송하는 단계; 및
    상기 데이터베이스로부터, 상기 장애 플래그를 수신하는 단계를 포함하는, 방법.
  3. 제1항에 있어서,
    상기 장애 모드에서, 상기 전자 장치의 상기 로컬 데이터베이스 내에 미리 저장된 상기 배송 목록 데이터를 로드하는 단계는,
    상기 배송 관리 애플리케이션에 대한 복수의 API(application programming interface) 중에서 상기 배송 목록 데이터를 요청하기 위한 특정 API를 식별하는 단계; 및
    상기 특정 API에 대한 호출 결과로서 상기 로컬 데이터베이스 내에서 가장 마지막으로 저장된 배송 목록 데이터를 로드하는 단계를 포함하는, 방법.
  4. 제1항에 있어서,
    상기 장애 모드에서, 상기 임시 애플리케이션 데이터에 기초하여, 상기 배송 관리 애플리케이션에 대한 오프라인 페이지를 생성하는 단계 - 상기 오프라인 페이지는 상기 배송 목록 및 상기 배송 관리 애플리케이션의 초기화에 대한 경고 알림을 포함함 -; 및
    상기 장애 모드에서, 상기 전자 장치의 디스플레이에 상기 오프라인 페이지를 표출하는 단계를 더 포함하는, 방법.
  5. 제1항에 있어서,
    상기 장애 모드에서, 상기 서버로부터, 상기 서버의 정상화 알림을 수신하는 단계; 및
    상기 정상화 알림을 수신한 것에 응답하여, 상기 장애 모드에서 상기 정상 모드로 전환하는 단계를 더 포함하는, 방법.
  6. 제5항에 있어서,
    상기 정상 모드에서, 상기 서버에 상기 배송 관리 애플리케이션에 대한 애플리케이션 데이터를 요청하는 단계;
    상기 정상 모드에서, 상기 서버로부터, 상기 애플리케이션 데이터를 수신하는 단계 - 상기 애플리케이션 데이터는 상기 배송원에게 할당된 하나 이상의 배송 대상 아이템에 대한 배송 목록을 포함함 -;
    상기 정상 모드에서, 상기 애플리케이션 데이터에 기초하여, 상기 배송 관리 애플리케이션에 대한 온라인 페이지를 생성하는 단계; 및
    상기 정상 모드에서, 상기 전자 장치의 디스플레이에 상기 온라인 페이지를 표출하는 단계를 더 포함하는, 방법.
  7. 제1항에 있어서,
    상기 장애 모드에서, 상기 배송 목록 내 배송 대상 아이템의 배송 완료를 지시하는 배송 완료 데이터를 획득하는 단계 - 상기 배송 완료 데이터는 상기 배송 대상 아이템의 배송 완료 시간 및 상기 배송 완료 시간에서 상기 배송 대상 아이템의 배송 완료 상태를 나타내는 이미지를 포함함 -; 및
    상기 장애 모드에서, 상기 배송 완료 데이터를 상기 로컬 데이터베이스에 저장하는 단계를 더 포함하는, 방법.
  8. 제7항에 있어서,
    상기 장애 모드에서 상기 정상 모드로 전환하는 것에 응답하여, 상기 정상 모드에서, 상기 로컬 데이터베이스에 저장된 배송 완료 데이터를 상기 서버에 전송하는 단계를 더 포함하는, 방법.
  9. 제7항에 있어서,
    상기 장애 모드에서, 상기 배송 완료 데이터를 상기 로컬 데이터베이스에 저장하는 단계는,
    상기 배송 관리 애플리케이션에 대한 복수의 API 중에서 상기 배송 완료 데이터를 상기 서버에 전송하기 위한 특정 API를 식별하는 단계; 및
    상기 특정 API의 호출에 대한 실패 이력을 상기 로컬 데이터베이스에 저장하는 단계를 포함하는, 방법.
  10. 제9항에 있어서,
    상기 장애 모드에서 상기 정상 모드로 전환하는 것에 응답하여, 상기 정상 모드에서, 상기 로컬 데이터베이스에 저장된 상기 특정 API의 호출에 대한 실패 이력을 식별하는 단계; 및
    상기 특정 API의 호출에 대한 실패 이력을 식별한 것에 응답하여, 상기 정상 모드에서, 상기 특정 API를 호출하여 상기 로컬 데이터베이스에 저장된 상기 배송 완료 데이터를 상기 서버에 전송하는 단계를 더 포함하는, 방법.
  11. 제1항에 있어서,
    상기 장애 모드에서, 상기 배송 목록에 포함되지 않은 아이템에 대한 식별 데이터를 획득하는 단계;
    상기 식별 데이터에 기초하여, 상기 아이템에 대한 임시 배송 데이터를 획득하는 단계 - 상기 임시 배송 데이터는 수취인 이름, 배송 완료 예상 시간, 운송장 번호, 박스 번호, 또는 배송지 주소 중 적어도 하나를 포함함 -; 및
    상기 임시 배송 데이터에 기초하여, 상기 아이템이 상기 배송 목록에 포함되도록 상기 배송 목록 데이터를 업데이트하는 단계를 더 포함하는, 방법.
  12. 제11항에 있어서,
    상기 식별 데이터는 상기 아이템을 식별하기 위한 QR 코드 또는 2차원 바코드 중 하나인, 방법.
  13. 제11항에 있어서,
    상기 장애 모드에서, 상기 업데이트된 배송 목록 데이터에 기초하여, 상기 임시 애플리케이션 데이터를 업데이트하는 단계;
    상기 장애 모드에서, 상기 업데이트된 임시 애플리케이션 데이터에 기초하여, 상기 배송 관리 애플리케이션에 대한 오프라인 페이지를 생성하는 단계 - 상기 오프라인 페이지는 상기 아이템을 포함하도록 업데이트된 배송 목록 및 상기 배송 관리 애플리케이션의 초기화에 대한 경고 알림을 포함함 -; 및
    상기 장애 모드에서, 상기 전자 장치의 디스플레이에 상기 오프라인 페이지를 표출하는 단계를 더 포함하는, 방법.
  14. 전자 장치에 있어서,
    하나 이상의 프로세서,
    상기 하나 이상의 프로세서에 의해 실행되는 명령어들이 저장된 하나 이상의 메모리를 포함하고,
    상기 하나 이상의 프로세서에 의해 상기 명령어들이 실행될 시, 상기 하나 이상의 프로세서는, 제1항 내지 제13항 중 어느 한 항에 따른 방법을 실행하도록 구성되는, 전자 장치.
  15. 하나 이상의 프로세서에 의한 실행 시, 상기 하나 이상의 프로세서가 동작을 수행하도록 하는 명령어들을 기록한 비일시적 컴퓨터 판독 가능 기록 매체에 있어서,
    상기 명령어들은, 상기 하나 이상의 프로세서로 하여금, 제1항 내지 제13항 중 어느 한 항에 따른 방법을 실행하게 하도록 구성되는, 비일시적 컴퓨터 판독 가능 기록 매체.
PCT/KR2024/013500 2024-06-27 2024-09-06 오프라인으로 배송 관리 애플리케이션을 위한 배송 관련 데이터를 처리하는 방법, 장치 및 명령을 기록한 기록 매체 Pending WO2026005121A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2024-0084643 2024-06-27
KR1020240084643A KR102851420B1 (ko) 2024-06-27 2024-06-27 오프라인으로 배송 관리 애플리케이션을 위한 배송 관련 데이터를 처리하는 방법, 장치 및 명령을 기록한 기록 매체

Publications (1)

Publication Number Publication Date
WO2026005121A1 true WO2026005121A1 (ko) 2026-01-02

Family

ID=96914012

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2024/013500 Pending WO2026005121A1 (ko) 2024-06-27 2024-09-06 오프라인으로 배송 관리 애플리케이션을 위한 배송 관련 데이터를 처리하는 방법, 장치 및 명령을 기록한 기록 매체

Country Status (3)

Country Link
KR (2) KR102851420B1 (ko)
TW (1) TW202601484A (ko)
WO (1) WO2026005121A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180005437A (ko) * 2016-07-06 2018-01-16 주식회사 코밴 결제 처리 방법 및 이를 수행하는 결제 처리 시스템
KR101877904B1 (ko) * 2017-11-16 2018-07-12 (주)웨일소프트 서버 장애 모니터링 장치 및 방법
KR102109536B1 (ko) * 2018-10-31 2020-05-28 주식회사 엘지씨엔에스 장애 유형 기반의 서버 장애 진단 및 대응 방법
KR20220145099A (ko) * 2021-04-21 2022-10-28 주식회사 바이엠텍 실시간 물류 배송 시스템 및 방법
KR20230121276A (ko) * 2022-02-11 2023-08-18 주식회사 클린씨 택배사 물류 통합에 따른 배송 데이터 운영방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180005437A (ko) * 2016-07-06 2018-01-16 주식회사 코밴 결제 처리 방법 및 이를 수행하는 결제 처리 시스템
KR101877904B1 (ko) * 2017-11-16 2018-07-12 (주)웨일소프트 서버 장애 모니터링 장치 및 방법
KR102109536B1 (ko) * 2018-10-31 2020-05-28 주식회사 엘지씨엔에스 장애 유형 기반의 서버 장애 진단 및 대응 방법
KR20220145099A (ko) * 2021-04-21 2022-10-28 주식회사 바이엠텍 실시간 물류 배송 시스템 및 방법
KR20230121276A (ko) * 2022-02-11 2023-08-18 주식회사 클린씨 택배사 물류 통합에 따른 배송 데이터 운영방법

Also Published As

Publication number Publication date
KR102851420B1 (ko) 2025-08-28
TW202601484A (zh) 2026-01-01
KR20260001535A (ko) 2026-01-05

Similar Documents

Publication Publication Date Title
WO2017034139A1 (en) Method and image forming apparatus for generating workflow of image forming job
WO2010062063A2 (ko) 브라우저 기반 어뷰징 방지 방법 및 시스템
WO2018016717A1 (en) Electronic device and email management method therefor
WO2017126740A1 (ko) 단말 장치, 원격 제어 시스템 및 제어 방법
WO2020233060A1 (zh) 事件通知方法、事件通知服务器、存储介质及装置
WO2020119117A1 (zh) 分布式计算方法、装置、系统、设备及可读存储介质
WO2019054779A1 (ko) 메시지를 처리하기 위한 전자 장치 및 그의 동작 방법
WO2021261651A1 (ko) 배송 상태 관리 방법 및 이를 수행하는 전자 장치
WO2019103280A1 (ko) 클라우드 서비스를 제공하는 적어도 하나의 클라우드 서버의 컴퓨팅 자원들을 관리하는 전자 장치 및 방법
US20160173606A1 (en) Information processing apparatus, communications apparatus, information processing method, and computer product
WO2016035979A1 (en) Method and system for controlling operation of image forming apparatus by using wearable device
WO2019147029A1 (ko) 상점 정보를 수신하는 방법 및 이를 사용하는 전자 장치
WO2023171973A1 (en) Apparatus and method of managing non-fungible tokens based on blockchain
WO2024150869A1 (ko) 물품의 출고를 관리하는 방법 및 그 장치
WO2019093658A1 (ko) 서버, 전자장치 및 그의 제어방법
WO2021261652A1 (ko) 배송 관리를 위한 전자 장치 및 그 제어 방법
WO2022215776A1 (ko) 클라우드 서버 및 클라우드 서버에서 로봇의 소프트웨어 이미지를 변환하는 방법
WO2021182761A1 (ko) 적어도 하나의 장치를 관리하는 방법 및 전자 장치
WO2021158068A1 (ko) 전자 장치 및 전자 장치의 클립 보드 운용 방법
WO2021201344A1 (ko) 통합 사용 로그 데이터를 생성하는 서버 및 그 동작 방법
WO2026005122A1 (ko) 배송 관리 애플리케이션에 로드되는 지도를 결정하는 방법, 장치 및 명령을 기록한 기록 매체
WO2024214911A1 (ko) 3d 물류 통합 관리 시스템
KR102851420B1 (ko) 오프라인으로 배송 관리 애플리케이션을 위한 배송 관련 데이터를 처리하는 방법, 장치 및 명령을 기록한 기록 매체
WO2019074244A1 (en) METHOD AND ELECTRONIC DEVICE FOR AUTOMATICALLY MANAGING THE ACTIVITIES OF AN APPLICATION
WO2023229089A1 (ko) 주문 관리를 위한 전자 장치 및 그 방법

Legal Events

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

Ref document number: 24944861

Country of ref document: EP

Kind code of ref document: A1