Method, device, and recording medium for integrating plurality of applications

Abstract

The present disclosure relates to a method by which a backend system manages an interaction between a client terminal and the backend system. The method may comprise the steps of: receiving a login resource identifier request from the client terminal; determining whether the received request is a login resource identifier request for a first role or a second role; in response to determining that the request is a login resource identifier request for a first role, transmitting a first login resource identifier corresponding to the first role to the client terminal so that the client terminal accesses a first login interface corresponding to the first login resource identifier; in response to determining that the request is a login resource identifier request for a second role, transmitting, to the client terminal, a second login resource identifier which is different from the first login resource identifier and corresponds to the second role so that the client terminal accesses a second login interface which is different from the first login interface and corresponds to the second login resource identifier; and performing authentication for the first role or the second role on the basis of first login data inputted through the first login interface or second login data inputted through the second login interface, and transmitting authentication result information to the client terminal.

Description

Method, device, and recording medium for integrating multiple applications

[0001] The present invention relates to a technology for integrating multiple applications, and more particularly, to a method, device, and recording medium for dynamically integrating functions and configurations of multiple applications according to a user role.

[0002] Modern logistics management and delivery systems may require multiple similar applications to perform diverse roles and functions. These applications are typically designed for specific users and perform specific functions for each user. For example, there may be separate applications for each target user group, while additional applications may exist to handle inquiries that arise during delivery. These applications each require different installation methods and access methods, resulting in duplicated resources and time-consuming maintenance.

[0003] Furthermore, as technological advancements and digital transformation accelerate, applications operating in a global environment increasingly need to meet the unique requirements of each country, region, and center. This is because each region may have different legal regulations, user preferences, and other regional characteristics. Effectively reflecting these diverse requirements is particularly crucial in user interface (UI) design. Certain elements may vary by country or region, and these differences must be considered to optimize the user experience. Therefore, technologies that can more efficiently address the needs of each country, region, and center through automated systems and adaptive UI design are needed.

[0004] For this reason, a technology is required that can integrate various applications with similar functions into a single application and dynamically adjust the application's UI.

[0005] The technical problem to be solved by one embodiment of the present invention is to increase the efficiency of development and maintenance and save resources by integrating existing similar independent applications.

[0006] Another technical challenge to be solved by one embodiment of the present invention is to provide a customized user experience and improve work efficiency by dynamically controlling the functions and configuration of an application according to the user's role.

[0007] Another technical challenge to be solved by one embodiment of the present invention is to simplify data integration and processing and improve application performance by unifying inconsistent API response formats and integrating unnecessary access points to make API responses lighter.

[0008] Another technical challenge to be addressed by one embodiment of the present invention is to manage access rights according to various user roles and to enhance data security through a tokenization function to protect personally identifiable information.

[0009] Another technical challenge to be addressed by one embodiment of the present invention is to provide the ability to dynamically adjust the UI based on user roles and regional regulations.

[0010] Another technical challenge to be addressed by one embodiment of the present invention is to provide global expansion capabilities through multilingual support and regionally customized UI.

[0011] The technical problems of the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned can be clearly understood by those skilled in the art from the description below.

[0012] According to one embodiment of the present disclosure, a method for managing interaction between a client terminal and the backend system, performed by a backend system, comprises the steps of: receiving a login resource identifier request from the client terminal; determining whether the received login resource identifier request is a login resource identifier request for a first role or a login resource identifier request for a second role; in response to a determination that the login resource identifier request is a login resource identifier request for the first role, transmitting a first login resource identifier corresponding to the first role to the client terminal, thereby allowing the client terminal to access a first login interface corresponding to the first login resource identifier; in response to a determination that the login resource identifier request is a login resource identifier request for the second role, transmitting a second login resource identifier corresponding to the second role, which is different from the first login resource identifier, to the client terminal, thereby allowing the client terminal to access a second login interface corresponding to the second login resource identifier, which is different from the first login interface; And, based on the first login data input through the first login interface or the second login data input through the second login interface, it may include a step of performing authentication for the first role or the second role, and transmitting authentication result information of the authentication to the client terminal.

[0013] In one embodiment, the login resource identifier request includes distinguishing data indicating whether the login resource identifier request is a login resource identifier request for the first role or a login resource identifier request for the second role, and the step of determining whether the received login resource identifier request is a login resource identifier request for the first role or a login resource identifier request for the second role may include the step of determining, based on the distinguishing data included in the login resource identifier request, whether the received login resource identifier request is a login resource identifier request for the first role or a login resource identifier request for the second role.

[0014] In one embodiment, performing authentication for the first role based on the first login data may include a more stringent authentication procedure than performing authentication for the second role based on the second login data.

[0015] In one embodiment, the authentication result information may include a session token.

[0016] In one embodiment, the client terminal includes an application, the application includes one or more application configuration items, and the method may further include the steps of: receiving a user configuration data request from the client terminal; determining user configuration data to be transmitted to the client terminal, wherein first user configuration data corresponding to the first role and second user configuration data corresponding to the second role differently activate the one or more application configuration items; and transmitting the user configuration data to the client terminal, thereby causing the client terminal to activate the one or more application configuration items based on the user configuration data.

[0017] In one embodiment, the step of determining user configuration data to be transmitted to the client terminal may include: determining whether the client terminal is authenticated for the first role or the second role; in response to a determination that the client terminal is authenticated for the first role, requesting a server linked with the backend system to transmit first user configuration data corresponding to the first role as user configuration data to be transmitted to the client terminal; and in response to a determination that the client terminal is authenticated for the second role, requesting a server linked with the backend system to transmit second user configuration data corresponding to the second role as user configuration data to be transmitted to the client terminal.

[0018] In one embodiment, the user configuration data may include configuration data for controlling at least one of whether an application configuration item of the application is activated, how an application screen is displayed, or whether movement to a specific page on the application is permitted.

[0019] In one embodiment, the user configuration data includes user role information, and the user role information may include an internal delivery person, an external delivery person, or a developer.

[0020] In one embodiment, the step of determining the user configuration data to be transmitted to the client terminal includes the step of determining the user configuration data based on current user information of a logged-in user, wherein the current user information may include data regarding at least one of a user ID, a login ID, work location information, and whether or not the logged-in user has a license.

[0021] In one embodiment, the method may further include: receiving an API request for retrieving data from the client terminal; determining, based on the user configuration data, whether the client terminal has an authority corresponding to the API request; in response to determining that the authority exists, transmitting one or more requests for retrieving data corresponding to the API request to one or more backend services, respectively, wherein the one or more backend services are connected to the backend system via a gateway; in response to receiving data corresponding to the one or more requests from the one or more backend services, integrating each of the received data according to a predetermined format; and transmitting the integrated data to the client terminal as a response to the API request.

[0022] In one embodiment, the method may further include the step of determining whether each of the data received from the one or more backend services includes personally identifiable information; and, in response to determining that each of the received data includes personally identifiable information, the step of tokenizing the personally identifiable information before transmitting the integrated data to the client terminal.

[0023] In one embodiment, the user configuration data may include one or more feature groups, each feature group including one or more features, and each feature including one or more key-value pairs associated with the one or more application configuration items.

[0024] In one embodiment, each of the above features is generated by combining a feature ID and an enable key based on either the user's region or role, and each of the generated features can enable the client terminal to dynamically configure the user interface.

[0025] In one embodiment, each key-value pair included in the feature may include information for determining whether to activate or control a function of one or more application configuration items.

[0026] An electronic device according to one embodiment of the present disclosure includes one or more processors, one or more memories storing instructions 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 any one of the embodiments.

[0027] In one embodiment of the present disclosure, a non-transitory computer-readable recording medium having recorded thereon instructions that, when executed by one or more processors, cause the one or more processors to perform an operation, the instructions may be configured to cause the one or more processors to perform a method according to any one of the embodiments.

[0028] According to the present disclosure, by integrating a number of similar applications, the efficiency of development and maintenance can be increased and resources can be saved.

[0029] According to the present disclosure, the functions and configuration of an application can be dynamically controlled according to a user's role, thereby providing a customized user experience and improving work efficiency.

[0030] According to the present disclosure, data integration and processing can be simplified and application performance can be improved by unifying inconsistent API responses through a single API access point and consolidating unnecessary access points.

[0031] According to the present disclosure, access rights can be effectively managed based on user roles, and data security can be enhanced through a tokenization function to protect personally identifiable information.

[0032] According to the present disclosure, the UI can be dynamically adjusted based on the user's location and region, and multilingual support can be provided, providing an optimized user experience and global expansion capabilities in various regions and countries.

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

[0034] FIG. 1 illustrates an environment in which a terminal and a server according to one embodiment of the present disclosure can be applied.

[0035] FIG. 2 is a block diagram of a terminal according to one embodiment of the present disclosure.

[0036] Figure 3 is a flowchart illustrating a method according to one embodiment of the present disclosure.

[0037] FIG. 4 is a diagram illustrating a login procedure according to a user role according to one embodiment of the present disclosure.

[0038] FIG. 5 is a flowchart for a request for user configuration data after login is completed according to one embodiment of the present disclosure.

[0039] FIG. 6 illustrates a feature group and features included in the feature group according to one embodiment of the present disclosure.

[0040] FIG. 7 is a diagram illustrating a user configuration information model and runtime evaluation of an invention according to one embodiment of the present disclosure.

[0041] FIG. 8 illustrates an example of a result in which a UI on a client terminal side is dynamically configured according to one embodiment of the present disclosure.

[0042] Figure 9 is a flowchart illustrating a method according to one embodiment of the present disclosure.

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

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

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

[0046] The singular expressions used in this disclosure may include the plural meaning unless the context clearly indicates otherwise, and the same applies to the singular expressions set forth in the claims.

[0047] The expressions "first," "second," or "first", "second", etc. used in this document, unless the context indicates otherwise, are used to distinguish one object from another when referring to multiple similar objects, and do not limit the order or importance among the objects.

[0048] As used herein, the expressions "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", etc., may refer to each of the listed items or to all possible combinations of the listed items. For example, "at least one of A or B" may refer to (1) at least one A, (2) at least one B, (3) at least one A and at least one B.

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

[0050] As used herein, the expression that a component (e.g., a first component) is “connected” or “connected” to another component (e.g., a second component) may mean that the component is directly connected or connected to the other component, as well as connected or connected via a new other component (e.g., a third component).

[0051] The expression "configured to" used in the present disclosure may have the meanings of "set to", "having the ability to", "modified to", "made to", "capable of", etc., depending on the context. This 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 general purpose processor that can perform the specific operation by executing software, or a special purpose computer that is structured through programming to perform the specific operation.

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

[0053] Figure 1 illustrates an environment in which terminals (110a, 110b), a network (120), and servers (130a, 130b, 130c) according to one embodiment of the present disclosure can be applied. Figure 1 illustrates the main components of the system according to one embodiment of the present invention and the interactions between them. This environment can be used not only in the logistics field, such as logistics, inventory management, and product tracking, but also in various application fields that require similar applications on the terminals (110a, 110b).

[0054] One or more terminals (110a, 110b) may be a single terminal (110) or may be a plurality of terminals (110). It will be understood that the plurality of terminals (110) may include additional terminals in addition to the illustrated terminals. Hereinafter, the terminals (110a, 110b) are referred to as terminals (110). One or more servers (130a, 130b, 130c) may be a single server (130) or may be a plurality of servers (130). It will be understood that the plurality of servers (130) may include additional servers in addition to the illustrated servers. Hereinafter, the servers (130a, 130b, 130c) are referred to as servers (130). The network (120) that connects the terminal (110) and the server (130) and / or connects the plurality of servers (130) is referred to as a network (120) hereinafter, regardless of the connection location.

[0055] In FIG. 1, for example, a user can use an application installed on a terminal (110) by using a terminal (110a, 110b), and the terminal (110a, 110b) can dynamically control the function and screen configuration of the application and process necessary data by transmitting the user's request to the server (130) via the network (120) according to the user's role. The terminal (110) may also be referred to as a client terminal, and the server (130) may serve as a backend server that processes user requests and provides data to the terminal (110), and thus may also be referred to as a backend server (130).

[0056] As illustrated in FIG. 1, a terminal (110) and a server (130) may be connected via a network (120) to form an e-commerce-related service or logistics management system. There may be one or more terminals (110) connected to the server (130). For example, one or more terminals (110a, 110b) may be connected to the server (130) via the network (120), and each terminal (110) may be capable of storing and processing data, including a database.

[0057] The terminal (110) may be a mobile device, tablet, or computer that allows a user to execute an application and transmit requests to the backend server (130) according to the user's role. The user can run the application through the terminal (110), and the application can communicate with the backend server (130) to perform specific functions. At this time, the type or data of the request may vary depending on the user's role. For example, a general user and an administrator user may have different permissions within the application, and thus the content of the request transmitted to the backend server (130) may differ. For example, an internal user and an external user may also have different permissions within the application, and thus the content of the request transmitted to the backend server (130) may differ. The user can perform various tasks through the application, and the results of these tasks may be processed through the backend server (130).

[0058] Specifically, the terminal (110) may take various forms and may include a smartphone, tablet, laptop, desktop computer, etc. In addition, the terminal (110) may include a plurality of computer systems or computer software, and may provide various information by configuring them as applications. For example, the terminal (110) may refer to computer software that performs a task and provides the result of the task. In addition, the terminal (110) may be understood as a broad concept that includes a series of application programs that can operate on a network and various databases built within it. For example, the terminal (110) may be implemented using a network program that is provided in various ways depending on the operating system such as DOS, Windows, Linux, UNIX, or MacOS.

[0059] In one embodiment, the system of the present invention comprises multiple terminals connected via a central network, each terminal (110) operating with an independent database to store, receive, and transmit data at the user's request. Each terminal (110) within the network has its own processing capabilities and can share and process data with other terminals (110) as needed.

[0060] The terminal (110) may have the ability to transmit user requests and receive responses. The terminal (110) may receive a specific request from a user and transmit it to a server (130) or another device, and may include a structure that receives a response to the request and displays it to the user.

[0061] For example, the terminal (110) may receive a login request from a user through an application. The terminal (110) may transmit this login request to the server (130). The terminal (110) may additionally perform the role of processing, handling, and storing the received data.

[0062] The terminal (110) can receive login requests via various user input methods, typically including a keyboard, touchscreen, or voice recognition system. The entered login information may be processed within the application in a specific format, which may vary depending on the authentication procedure required by the server (130). For example, the user ID and password may be encrypted and transmitted to the server (130).

[0063] Thereafter, the terminal (110) can transmit a login request to the server (130) via the network (120). This transmission process can use various communication protocols of the network (120) and may include a secure communication method such as HTTPS.

[0064] The terminal (110) may include software capable of executing a client application that transmits a login resource identifier request to a backend server (130) via a network (120). The software may provide an interface through which a user can enter login information, and the entered information may be transmitted via the network.

[0065] In one embodiment, the terminal (110) can access a login interface. Specifically, the terminal (110) may include functionality that allows the user to access the login interface to complete an authentication process. This login interface may prompt the user to enter a user ID and password. The entered information may be transmitted to the server (130) to initiate the authentication process. After successful authentication, the user may access the system provided by the application.

[0066] In one embodiment, the terminal (110) can receive an API request from a user through an application, transmit the request, and receive a response. Specifically, the terminal (110) can convert a command or request entered by the user during the execution of the application into an API call format and transmit it to a server (130) via a network (120). During this process, the terminal (110) can format the required data based on the user input and transmit the data to a designated API endpoint. Thereafter, if a response is received from the server (130), the terminal (110) can convert the response into an appropriate format and use it within the application.

[0067] In one embodiment, the terminal (110) may include an application, and the application may include one or more application configuration items. The application included in the terminal (110) may interact with the user through a user interface and perform various functions. For example, the application may include functions for processing data, providing information, or communicating with other software. In addition, the application configuration items may specify the functions of the application and support the user in performing desired tasks. The application configuration items may take various forms, such as buttons, menus, text fields, and images, and these items may vary depending on the services or functions provided by the application.

[0068] In one embodiment, the terminal (110) can activate one or more application configuration items based on user configuration data. Specifically, the terminal (110) may include an algorithm or logic that can selectively activate specific application configuration items based on user configuration data. It will be appreciated that this allows for customized settings based on user configuration data, thereby enhancing the usability of the application.

[0069] In additional embodiments, user configuration data may include user settings, preferences, or past usage history, which may enable the terminal (110) to automatically activate or deactivate certain features or options of the application. For example, implementations may be possible that automatically activate frequently used features or deactivate features not needed in certain environments.

[0070] In addition, it should be noted that even if an operation is not mentioned in the present disclosure regarding an operation that the terminal (110) can perform, if it is a general operation that the terminal (110) providing a known application can perform, applying the technical idea of ​​the present disclosure with reference to that operation is not excluded from the scope of the present disclosure.

[0071] The network (120) may connect one or more terminals (110) and may play a role in connecting them to a network-level server (130). In addition, the network (120) may connect communication between servers (130). For example, the network (120) may provide a connection path so that the terminals (110) may be connected to a network-level server (130) or between servers (130) to transmit and receive packet data. For example, the network (120) may be the Internet or an internal network. The network (120) may use various communication protocols and may include a secure communication method such as HTTPS. The network (120) may be implemented as any type of wired or wireless network (120), such as a Local Area Network (LAN), a Wide Area Network (WAN), a Mobile Radio Communication Network, or Wibro (Wireless Broadband Internet).

[0072] The server (130) may be a server (130) that interacts with one or more different terminals (110) and hosts various software. For example, the server (130) may be a cloud server (130). The server (130) may include servers (130a, 130b, 130c), each of which may be a backend server that processes user requests and provides data. The servers (130a, 130b, 130c) may operate as independent systems and / or may be interconnected via a network to perform cooperative tasks. Each server (130) may be interconnected to provide data and functions. This allows for efficient data processing and resource distribution among the servers.

[0073] In one embodiment, the server (130) may perform backend logic processing. Specifically, the server (130) may process a login request, determine a user role, perform authentication, manage user configuration data, and provide single API access. In one embodiment, the server (130) may receive a login resource identifier request from the terminal (110). The server (130) may determine whether the request is for a first role (e.g., an internal user, e.g., an internal delivery worker belonging to a company operating a service) or a second role (e.g., an external user, e.g., an external delivery worker who is a regular person performing delivery work temporarily). Depending on the respective performance, the server (130) may include, for example, a backend server, a gateway server, and a backend service server.

[0074] In one embodiment, the server (130) may transmit a login resource identifier corresponding to the role to the terminal (110) based on the determination. In one embodiment, the server (130) determines whether the received login resource identifier request is a login resource identifier request for the first role or a login resource identifier request for the second role, and accordingly transmits a first or second login resource identifier corresponding to the first or second role, respectively, to the terminal (110), thereby allowing the terminal (110) to access the first or second login interface corresponding to the first or second login resource identifier, respectively. Thereafter, the server (130) processes the login request received from the terminal (110) through the first or second login interface, and may perform an authentication procedure during this process. If the user information is determined to be valid, the server (130) may return a login approval. For example, the login approval may include authentication result information, which may be, for example, a session token. For example, when a user attempts to log in, the user may provide credential information, such as his / her user ID and password. The server (130) can receive this credential information and compare it with information stored in the database. If the provided credential information matches the information stored in the database, the server (130) can determine that the user has successfully authenticated. If this authentication process is successfully completed, the server (130) can return a login approval. This login approval may include information indicating that the user has successfully completed authentication. For example, the login approval may include a session token, which may allow the user to continue accessing the server (130). The session token may be valid for a specific period of time, and upon expiration, the user may be required to go through the authentication process again.Session tokens are a critical part of security and can help prevent unauthorized access. They can also be useful for tracking and managing user activity.

[0075] In additional embodiments, the server (130) may receive additional authentication input for security authentication. For example, it may receive biometric (fingerprint, facial recognition) input or two-step authentication input via the terminal (110).

[0076] In one embodiment, the server (130) may determine a user role. In one embodiment, the server (130) may determine a user role based on identification data included in a login resource identifier request.

[0077] In one embodiment, the server (130) can perform authentication for the request. After determining the user's role, it can determine whether to apply a high or low security level based on the user's role.

[0078] In one embodiment, the server (130) can manage / transmit user configuration data. The server (130) can generate user configuration data to control specific functions and screen configurations based on the user's role. This may include appropriately mapping required functions and interfaces according to each user's role and storing the data in a database, etc. For example, user roles may be divided into various categories such as administrator, general user, and guest, and appropriate permissions and functions may be granted according to each role. Additionally, the server (130) can transmit the generated user configuration data to the terminal (110) so that the application can be appropriately configured for each user. This can be done in real time or aperiodically through data transmission between the server (130) and the terminal (110), and the transmitted data can serve to dynamically change the settings and configuration of the application within the terminal (110). For example, the screens displayed and available functions may differ depending on whether an administrator is logged in or a general user is logged in. Additionally, for example, if an internal user, such as a delivery worker affiliated with the company operating the service, logs in, they can use advanced features like delivery route optimization, and may also have access to sensitive information. Conversely, if an external user, such as a casual delivery worker, logs in, they may only have access to features related to basic delivery tasks. For example, they may primarily use functions like accepting delivery requests and providing basic route guidance. It will be appreciated that these examples are not limited to logistics. It will be appreciated that the management of user configuration data managed by the server (130) can play a crucial role in providing a dynamic application environment tailored to the user's role.

[0079] User configuration data refers to data for dynamically controlling the functions, screen configuration, page movement, etc. of an application according to a user role, and the user configuration data can be configured based on a user role, region, task type, etc. The server (130) according to the present invention can manage / transmit such user configuration data so that the terminal (110) can provide a service according to the role. For example, based on user profile information and location information, location-specific services (e.g., language, location-specific services) can be provided, and based on user role and authority information, the terminal (110) can perform customized access control. In this way, the server (130) will be able to provide an optimized UI according to a user role within the application by managing the user configuration data.

[0080] In one embodiment, the server (130) may provide a single API access point. Providing a single API access point may mean collecting and integrating native data from multiple backend services and delivering it to the terminal (110) as a single API response. This approach may simplify interactions between the terminal (110) and the backend services and reduce client-side complexity. Those skilled in the art will appreciate that a single API access point provided by the server (130) may contribute to performance optimization and reduced network usage by aggregating multiple API calls into a single API call.

[0081] In one embodiment, the server (130) may apply separate tokenization and detokenization procedures to protect personally identifiable information (PII). Tokenization refers to a method of irreversibly converting sensitive data into a form that can enhance data security during storage or transmission. Detokenization refers to the process of restoring stored tokens to their original sensitive data and may be performed only when necessary. Those skilled in the art will understand that tokenization is performed at a single point, rather than across multiple backend services, thereby eliminating unnecessary steps.

[0082] The server (130) can additionally host logistics management system software and manage logistics distribution, logistics status, etc. Accordingly, when a specific request is received from the terminal (110), the server (130) can transmit data corresponding to the request. Specifically, the server (130) can comprehensively manage logistics distribution and status through the logistics management system software. When a specific request is received from the terminal (110), the server (130) can determine whether the request is related to logistics distribution or logistics status, extract the requested data or information, and transmit it to the terminal (110).

[0083] In additional embodiments, the server (130) may search the included database and update or add new data as needed. For example, if user configuration information changes or current user information changes, the changed data may be updated.

[0084] In additional embodiments, the server (130) may acquire and update such changed data at predetermined time intervals, and provide the updated data to the terminal (110) in real time or periodically. This may mean that the server (130) can flexibly respond to various requests. Specifically, the server (130) may periodically monitor data stored in the database and search for new or changed information entered by the user. If the data is changed or updated, the server (130) may automatically update it to maintain data consistency. Furthermore, the server (130) may periodically search for data at specific time intervals and update the changed data to perform regular information updates.

[0085] The server (130) may include a database. The database may be a system that stores and manages various types of information. Specifically, the database may store data related to logistics services and user configuration information. The server (130) may perform database management. The database may be connected to the server (130) or may be included as an embedded component. Specifically, the database may be accessed by the server (130) and may provide information or be updated in real time. For example, when a request is received from a terminal (110), the server (130) may retrieve relevant data from the database and transmit the results to the terminal (110) based on the data.

[0086] Additionally, the database may include security features. Specifically, the database may include various mechanisms and protocols to prevent unauthorized access, modification, deletion, etc. of data.

[0087] In addition, it should be noted that even if an operation is not mentioned in the present disclosure regarding an operation that the server (130) can perform, if it is a general operation that a known server (130) can perform, applying the technical idea of ​​the present disclosure with reference to that operation is not excluded from the scope of the present disclosure.

[0088] The application integration system according to various embodiments may be implemented as a single physical device, or may be implemented in a manner in which multiple physical devices are organically combined. For example, some of the components included in the application integration system may be implemented by one physical device, and the remaining parts of the components included in the application integration system may be implemented by another physical device. For example, one physical device may be implemented as a part of a terminal (110a), and the other physical device may be implemented as a part of a terminal (110b), a part of a server (130), or a part of an external device (not shown). In some cases, each component included in the application integration system may be distributed and arranged on different physical devices, and the distributed components may be organically combined to perform the functions and operations of the application integration system.

[0089] FIG. 2 is a block diagram of an electronic device (200) according to one embodiment of the present disclosure. The electronic device (200) may be a terminal (110) or a server (130) according to one embodiment of the present invention.

[0090] Referring to FIG. 2, an electronic device (200) according to various embodiments may include one or more processors (210), one or more memories (220), and a communication interface (230) as components. In one embodiment, at least one of the components of the electronic device (200) may be omitted, or another component may be added to the electronic device (200). In one embodiment, additionally or alternatively, some of the components may be implemented in an integrated manner, or may be implemented as a single or multiple entities. In the present disclosure, one or more processors (210) may be expressed as a processor (210). The expression “processor (210)” may mean a set of one or more processors, unless the context clearly indicates otherwise. In the present disclosure, one or more memories (220) may be expressed as a memory (220). The expression “memory (220)” may mean a set of one or more memories, unless the context clearly indicates otherwise. In one embodiment, at least some of the components inside / outside the electronic device (200) are connected to each other via a bus, GPIO (General Purpose Input / Output), SPI (Serial Peripheral Interface), MIPI (Mobile Industry Processor Interface), etc., and can exchange information (data, signals, etc.).

[0091] The processor (210) may control at least one component of an electronic device (200) connected to the processor (210) by running software (e.g., commands, programs, applications, etc.). In addition, the processor (210) may perform various operations such as calculations, processing, data generation, and processing related to the present disclosure. In addition, the processor (210) may load data, etc. from the memory (220) or store data in the memory (220). In one embodiment, the processor (210) may control the communication interface (230) to request various information from the user terminal (120) or the server (130), and receive various information from the user terminal (120) or the server (130).

[0092] The processor (210) can control other components of the electronic device (200) in general and process a series of steps for performing a plurality of application integration methods according to various embodiments of the present disclosure.

[0093] The processor (210) may have the ability to process data received from another electronic device (200) via a network (120) together with the running software, store such data in memory, and then retransmit the data via the network (120) as needed. The real-time data processing capability of the processor (210) and the storage function of the memory enable efficient data exchange via the network (120).

[0094] According to one embodiment of the present invention, the processor (210) may perform a function of processing data received from another electronic device (200). Accordingly, the processor (210) may transmit the data to the other electronic device (200) or communicate with a database located in the other electronic device (200) to perform a necessary task. Specifically, the processor (210) analyzes the received data, converts it into an appropriate format, and then transmits it to the other electronic device (200). In addition, the processor (210) may access or update the database of the server (130) in real time, thereby supporting necessary tasks in various applications. In addition, the processor (210) displays information processed on the electronic device (200) to enable the user to check it in real time.

[0095] The processor (210) can perform communication and management tasks with the server (130) through an application running on the electronic device (200).

[0096] In one embodiment, the processor (210) can perform security processing to maintain data integrity and protect sensitive information. Security processing may include encryption, access control, and audit logging, which can ensure data consistency and reliability. Encryption converts data into an unreadable form, protecting it from unauthorized access. Access control restricts access to data to specific users or systems, ensuring the safe storage of sensitive information. Audit logging allows for tracking who accessed what data, when, and thus, identifying and responding to potential security threats.

[0097] In one embodiment, the processor (210) can additionally integrate data from multiple sources to provide a consistent response. Data integration is the process of combining data with different formats or structures, thereby providing more comprehensive and useful information to users. Data can be collected from various sources, creating a more complete data set. The integrated data can reduce redundancy and improve consistency. Furthermore, data cleaning and transformation can be performed during the data integration process to improve quality. Consequently, the integrated data can be utilized as a basis for various processing.

[0098] The processor (210) can set whether to activate an item based on predefined rules or algorithms. This means that the processor can activate or deactivate an item when certain conditions are met. These rules or algorithms can vary depending on system requirements, ensuring that the item functions appropriately in specific situations.

[0099] The memory (220) can store various information (data). The information stored in the memory (220) is information acquired, processed, or used by at least one component of the electronic device (200), and may include software (e.g., commands, programs, etc.). For example, the memory (220) may store an operating system (OS), applications, etc. for performing basic operations and resource management functions of the electronic device (200). In the present disclosure, commands or programs are software stored in the memory (220), and may include an operating system for controlling resources of the electronic device (200), applications, application programming interfaces, and / or middleware for providing various functions to applications so that the applications can utilize the resources of the electronic device (200). In one embodiment, the memory (220) may store commands that, when executed by the processor (210), cause the processor (210) to perform operations. For example, applications are programs utilized by a user to perform specific tasks, and such applications may also be stored in the memory (220). The application programming interface acts as an intermediary to enable the application and the operating system to interact, and the application programming interface can also be stored in memory (220).

[0100] The memory (220) can cooperate with the processor (210) in data storage and processing tasks to enhance the overall efficiency and stability of the system. The memory (220) can permanently or temporarily store data to enable the system to achieve management goals. Additionally, the memory (220) can store data being processed by the processor (210). Specifically, the memory (220) can temporarily store data being calculated by the processor (210) to ensure the continuity of the operation. For example, the processor (210) can continue its operation without interruption by storing intermediate calculation results or necessary temporary data in the memory.

[0101] The memory (220) may include volatile and / or non-volatile memory. The memory (220) may store at least a portion of information received from the database via the communication interface (230) and / or information transmitted to the database via the communication interface (230). In one embodiment, the memory (220) may replace the role of the database. The memory (220) may store information regarding logistics and instructions configured to be executed by the processor (210).

[0102] The communication interface (230) can perform wireless or wired communication between the electronic device (200) and a database or other external terminal (110). For example, the communication interface (230) can perform wireless communication according to a method such as eMBB (enhanced Mobile Broadband), URLLC (Ultra Reliable Low-Latency Communications), MMTC (Massive Machine Type Communications), LTE (Long-Term Evolution), LTE-A (LTE Advance), NR (New Radio), UMTS (Universal Mobile Telecommunications System), GSM (Global System for Mobile communications), CDMA (Code Division Multiple Access), WCDMA (Wideband CDMA), WiBro (Wireless Broadband), Wi-Fi (Wireless Fidelity), Bluetooth (Bluetooth), BLE (Bluetooth Low Energy), NFC (Near Field Communication), GPS (Global Positioning System), or GNSS (Global Navigation Satellite System). For example, the communication interface (230) may perform wired communication according to a method such as Universal Serial Bus (USB), High Definition Multimedia Interface (HDMI), Recommended Standard-232 (RS-232), or Plain Old Telephone Service (POTS). In one embodiment, the electronic device (200) may be implemented by being integrated with another device.In this case, the communication interface (230) can function as a connection circuit or interface connecting the electronic device (200) and the other device.

[0103] Hereinafter, the operations described as being performed by the backend system (420) or server (130) in FIGS. 3 to 8 can be understood as being performed by the processor (210) of the electronic device (200) described in FIG. 2.

[0104] Figure 3 is a flowchart illustrating a method according to one embodiment of the present disclosure. The flowchart consists of steps S310, S320, S330, S340, and S350.

[0105] The method is further described in detail with reference to FIG. 4. FIG. 4 is a diagram illustrating a login procedure according to a user role according to one embodiment of the present disclosure.

[0106] A login resource identifier request can be received from a terminal (110) by the server (130). That is, a login resource identifier request can be received from a client terminal (410) by the backend system (420) (S310).

[0107] A login resource identifier may refer to an identifier for a resource, such as a URL, used to identify and authorize a user attempting to access a service or system. A login resource identifier request may indicate that the client terminal (410) is requesting to initiate a login procedure. This may indicate that the user requires authentication to access a specific application or service.

[0108] The above step S310 may correspond to the authentication-login URL request (442) of the first login case (440) of FIG. 4. The client terminal (410) may request an authentication-login URL according to a workgroup (441) selected by the user, and the backend system (420) may receive this authentication-login URL request. Specifically, step S310 may be a step in which the client terminal (410) of FIG. 4 requests a specific authentication-login URL according to a workgroup (441) selected by the user, and the backend system (420) receives this authentication-login URL request. The client terminal (410) may request an authentication-login URL on a workgroup basis, and this may correspond to the first login case (440) of FIG. 4.

[0109] In one embodiment, the login resource identifier request (442) may include distinguishing data indicating whether the login resource identifier request is for a first role or a second role. For example, the first role may refer to an internal delivery person, and the second role may refer to an external delivery person. Specifically, the distinguishing data refers to information necessary to clarify which role the login resource identifier request (442) corresponds to. Through the distinguishing data, the backend system (420) may perform an appropriate authentication procedure according to the first role and the second role, and respond with a URL that links to the first login interface or the second login interface corresponding to the first role or the second role.

[0110] In an additional embodiment, the login resource identifier request (442) may not include any distinguishing data, and the backend system (420) may distinguish between internal and external employees (by referring to a mapping table) based on the terminal (110) identification information, etc. Specifically, when no distinguishing data is separately included in the login resource identifier request, the backend system (420) may classify the user's identity as an internal or external delivery person (for example, by referring to a mapping table) based on the terminal (110) identification information, etc. The mapping table may refer to a data structure for identifying the user's identity based on the terminal (110) identification information. For example, the mapping table may include terminal (110) identification information (Device Identifier) ​​as a field, which includes information that can uniquely identify the user's terminal (110) (for example, MAC address, device ID, etc.). Therefore, even if distinguishing data is missing during the login process, the backend system (420) may perform the employee distinguishing function by combining the terminal (110) identification information and the internal database.

[0111] The backend system (420) can determine whether the received login resource identifier request is a login resource identifier request for the first role or a login resource identifier request for the second role (S320). In FIG. 4, the above step S320 may correspond to workgroup verification and authentication-login URL determination (443) of FIG. 4. Referring to FIG. 4, after receiving the authentication-login URL request (442), the backend system (420) can process the received authentication-login URL request (443). Specifically, the backend system (420) can verify the selected workgroup and determine the authentication-login URL (443). More specifically, the backend system (420) can determine a URL corresponding to the workgroup based on the workgroup collected from the user. It will be appreciated that the backend system (420) can distinguish and determine a URL for performing an authentication procedure defined differently depending on the user role.

[0112] In additional embodiments, the backend system (420) may use specific criteria or algorithms to distinguish, for example, whether a login resource identifier request is for a first role or a second role. This may be accomplished by analyzing attribute information or metadata contained in the login resource identifier request. Furthermore, the role may be determined based on predefined policies or rules within the system. In additional embodiments, the backend system (420) may make a determination based on the context of the received login resource identifier request, the time of request occurrence, etc. Additionally, the priority or access rights for a specific role may be preset, or the role may be determined based on the user profile.

[0113] In one embodiment, the step of determining whether the received login resource identifier request is a login resource identifier request for a first role or a login resource identifier request for a second role may include the step of determining whether the received login resource identifier request is a login resource identifier request for a first role or a login resource identifier request for a second role based on the identification data included in the login resource identifier request. Specifically, after the backend system (420) receives the login resource identifier request, it may analyze the identification data included in the request. The identification data may be information indicating which role the request corresponds to. For example, the identification data may be information on an internal user or an external user. For example, the identification data may exist in a metadata format including tags such as workgroup, role, and location.

[0114] If many existing applications target internal and external delivery workers separately, it's understandable that the login process would be structured around these user roles. Specifically, internal delivery workers would be granted greater access to the company's internal systems, while external delivery workers would be granted limited access. Therefore, it's understandable that different authentication procedures would be required depending on their role.

[0115] In additional embodiments, internal delivery workers may be authenticated using internal authentication procedures, such as an internal email address and password. External delivery workers, on the other hand, may follow external contractor authentication procedures, such as using a contractor ID and contract number.

[0116] In response to a determination that the login resource identifier request is a login resource identifier request for a first role, the backend system (420) transmits a first login resource identifier corresponding to the first role to the client terminal (410), thereby allowing the client terminal (410) to access a first login interface corresponding to the first login resource identifier (S330).

[0117] In response to a determination that the login resource identifier request is a login resource identifier request for a second role, the backend system (420) transmits a second login resource identifier corresponding to the second role, which is different from the first login resource identifier, to the client terminal (410), thereby allowing the client terminal (410) to access a second login interface corresponding to the second login resource identifier, which is different from the first login interface (S340).

[0118] The first login resource identifier may refer to information for accessing an interface corresponding to a first role for accessing a specific service. The second login resource identifier may refer to information for accessing an interface corresponding to a second role, and may be different from the first login resource identifier. The login resource identifier may be, for example, a Uniform Resource Locator (URL) that directs to a login page. The first and second login resource identifiers can be used to provide separate login interfaces for the integrated application, and can facilitate providing dedicated interfaces for each role in the integrated application.

[0119] Specifically, when a login resource identifier request is received from a client terminal (410), if the request is determined to be for roles 1 and 2, the system can select and transmit the first and second login resource identifiers corresponding to the first and second roles. This can enable the user to proceed with the login process through a customized login interface appropriate for the role. By providing different login interfaces for different roles, a login environment optimized for each role can be created.

[0120] The above step S330 may be the authentication-login URL response (444) step of FIG. 4. After receiving a user's login request, the backend system (420) may generate a Se / Sx (Secure Element / Secure Execution) authentication-login URL in response to the request. This may include a procedure for identifying the user based on authentication information provided by the user and generating a Se / Sx authentication-login URL as a result. In step 443 of FIG. 4, the backend system (420) may verify the user's identity and review the authentication information, and then generate an appropriate Se / Sx authentication-login URL and send it to the user as a response. This URL may be used as a link for the user to complete the authentication procedure in a later step. The user may access the system using the Se / Sx authentication-login URL provided by the backend system (420), which may contribute to safely protecting all user sessions.

[0121] In one embodiment, performing authentication for the first role based on the first login data may involve a more stringent authentication procedure than performing authentication for the second role based on the second login data. Specifically, authentication for the first role, which is authentication for internal users, may involve a more stringent authentication procedure. For example, authentication for the first role and authentication for the second role may be Se / Sx authentication. Specifically, the Secure Element (Se) is typically implemented as a smart card chip or security module and can perform security operations related to storing and processing sensitive data. It can be used when handling sensitive information such as PIN codes, biometric data, and encryption keys. The Secure Element is physically separate hardware and difficult to directly access, providing high security. Secure Execution (Sx) may refer to a secure execution environment. This creates a separate secure area within the processor to protect sensitive data and applications. This protected area typically utilizes hardware-based security technologies to secure data from external attacks. For example, technologies such as Trusted Execution Environment (TEE) may be used as part of Secure Execution.

[0122] Additionally, a more stringent authentication process may mean more authentication steps. Or, it may include an encryption algorithm that uses a longer key length (e.g., a key longer than 256 bits). Furthermore, it may mean a process using the Advanced Encryption Standard (AES) 256-bit. Specifically, increasing the authentication process may include adding various authentication methods, such as multi-factor authentication or biometrics. This has the potential to increase the strength of the authentication. For example, a user may authenticate using fingerprint recognition or a dynamic token in addition to a password. For encryption, the use of AES 256-bit allows for a longer key length, which is known as one of the strongest encryption algorithms among existing standards. In additional embodiments, authentication for the first role may include additional security mechanisms, such as multi-factor authentication (MFA), one-time passwords (OTPs), biometrics, or smart card-based authentication.

[0123] Embodiments of the present disclosure are not limited to logistics, but can be applied to fields that handle sensitive information, such as finance, medicine, and government agencies, or fields where multi-layered security procedures are common.

[0124] The backend system (420) can perform authentication for the first role or the second role based on the first login data entered through the first login interface or the second login data entered through the second login interface. In addition, the backend system (420) can transmit authentication result information of the authentication to the client terminal (410) (S350).

[0125] The first login interface may be an interface with additional security elements, unlike the second login interface. The second login interface typically refers to an interface for receiving a username and password. For example, the login interface may be similar to a web application login page, allowing the user to enter information to verify their credentials. This information is transmitted to the backend system (420) and compared with authentication information stored in the database. If the entered information matches the information stored in the database, the user can exercise the permissions granted to the corresponding first and second roles.

[0126] Additionally, the backend system (420) can transmit authentication result information to the client terminal (410). The backend system (420) can be implemented in various ways to transmit authentication result information to the client terminal (410) after completing the authentication procedure.

[0127] For example, the backend system (420) can verify the authentication information entered by the user and then transmit result information regarding authentication success or failure to the client terminal (410). Through this process, the client terminal (410) can check in real time whether the user has been authenticated normally.

[0128] There may be several ways in which the backend system (420) transmits authentication result information to the client terminal (410). The authentication result may be transmitted to the client terminal (410) via a RESTful API, the authentication status may be reflected in real time using a WebSocket, or the authentication result may be transmitted asynchronously using a message queue system.

[0129] In one embodiment, the authentication result information may include a session token. A session token generally refers to any string or encrypted data used to identify and manage a communication session between a user and the server (130). The session token may be useful for the server (130) to track client requests and store session information. The session token is used to track the user's authentication status, and the server (130) may verify the session token to confirm that the client is an authenticated user. Alternatively, the session token may allow the user to maintain the same logged-in state while verifying and authenticating additional requests by the server (130). For example, if the session token is invalid when the user attempts to perform a specific task, the server (130) may reject the request. When the application is run, the client may include the session token in the request header and transmit it to the server (130). The server (130) may verify the user's authentication status by verifying the received session token. Additionally, the session token may expire after a certain period of time. This is to enhance security and prevent session hijacking. The expiration time of a session token may vary depending on the settings of the server (130). Additionally, the session token may consist of a randomly generated string or a unique identifier. This prevents duplication with other users and allows for efficient management of each user's session. These session tokens may be transmitted encrypted and using the HTTPS protocol to prevent interception.

[0130] In an additional embodiment of the present disclosure, the backend system (420) may transmit information including not only the success or failure of authentication, but also the reason for the success or failure, and information regarding additional authentication procedures if additional authentication is required. For example, in the event of authentication failure, the cause may be conveyed in detail to the client terminal (410) to guide the user on what action to take. In an additional embodiment, the backend system (420) may also transmit information including personal information of the user who attempted authentication.

[0131] The above step S350 may correspond to the login request, authentication-token response, and cached session (445) according to user group in FIG. 4. Specifically, the client terminal (410) may make a login request based on the authentication-login URL received in the authentication-login URL response (444) step. This login request may be transmitted to the backend system (420) for authentication. After receiving the login request, the backend system (420) may perform user authentication. The backend system (420) may verify the provided credentials and, if authentication is successful, may issue and transmit an authentication token. The authentication token may be used to verify the user's identity in subsequent requests. Accordingly, the backend system (420) may create a cached session (445) according to the user group. The user may access the system through this cached session, thereby providing an efficient user experience.

[0132] Hereinafter, additional description will be given of FIG. 4. After step 445 of FIG. 4 described above, the client terminal (410) can store the selected workgroup (drawing symbol not shown).

[0133] Step 446 of FIG. 4 will now be described. When current user information is requested via a client terminal (410), the backend system (420) may receive it. A user may require current user information to perform a specific function via an application. Accordingly, the application may request this information from the backend system (420). Upon receiving this request, the backend system (420) may transmit the same request to the server (130). The server (130) may determine the requested current user information and respond to the backend system (420). The backend system (420) may transmit the current user information received from the server (130) to the client terminal (410).

[0134] The login expiration case (450) of Fig. 4 is described.

[0135] If the session expires, the backend system (420) returns a 302 error, and the client terminal (410) can reload the authentication-login page. Specifically, if the session expires, the client terminal (410) can request an authentication-login URL along with a user context (UserContext). The backend system (420) can normally return the URL, but may return a 302 error when requesting a login due to a session expiration. The client terminal (410) can detect this error and reload the authentication-login page to allow the user to log in again. Each step is described below.

[0136] 1. Requesting an authentication-login URL with UserContext: If the session has expired, the application can request an authentication-login URL to the backend system (420) with UserContext.

[0137] 2. Authentication-Login URL Response: The backend system (420) can return a Se / Sx authentication-login URL.

[0138] 3. Login Request: Users can access the login page and enter their ID / password.

[0139] 4. 302 Error Response: The backend system (420) may return a 302 error if the session has expired.

[0140] 5. Load the authentication-login page: The application can detect the 302 error and reload the login page.

[0141] FIG. 5 is a flowchart for a request for user configuration data after login is completed according to one embodiment of the present disclosure.

[0142] The procedure (500) of Fig. 5 is replaced with the above description.

[0143] 1. 510: When the user login procedure is completed, the backend system (420) can perform a dispatch with the Feature Flag (FF) server (430) to update user role information.

[0144] 2. 520: The client terminal (410) can request user configuration information according to the user role from the backend system (420). The user configuration information is indicated as RoleConfig in the drawing. RoleConfigModel may be a model that includes configuration data for controlling functions, screens, page movement, etc. to be used on the client terminal (410) according to the user role.

[0145] In one embodiment, the user configuration data may include configuration data for controlling at least one of the following: whether application configuration items of the application are activated, how the application screen is displayed, or whether certain page navigation is permitted within the application. For example, users with an administrator role may be granted access to more functions and screen elements, while general users may be provided with only limited functionality. This configuration data may play a significant role in dynamically configuring the user interface on the client terminal (410).

[0146] In one embodiment, user configuration data may include user role information. This user role information may include internal delivery personnel, external delivery personnel, or developers. Internal delivery personnel may primarily refer to users who perform delivery tasks within a specific organization. They are responsible for logistics-related tasks within the organization and may be responsible for resolving any delivery-related issues that arise within the organization. Examples of internal delivery personnel include employees of the company's logistics team or employees responsible for in-house delivery. External delivery personnel may refer to users who perform delivery tasks outside the organization. These personnel are typically associated with third-party logistics companies or private delivery companies and may be responsible for delivering items to or from the organization. Examples of external delivery personnel may include drivers from other companies, employees of outsourced delivery companies, or individual delivery personnel. Developers may be users responsible for system maintenance and feature development. They handle all technical issues related to software and systems and may have roles that allow them to add new features to the system or improve existing features. Examples of developers may include programmers, software engineers, and system analysts. Additionally, for example, user roles may include whiteCpf_korea, yellowCpf_korea, car_flex_korea, and quick_flex_korea.

[0147] 3. 530: The backend system (420) can retrieve user role information from a Transportation Management System (TMS) server (430), then generate user configuration data (RoleConfig) based on the user role information, and respond with the user configuration data to the client terminal (410).

[0148] 4. (Drawing symbol not shown) Cached RoleConfig: The client terminal (410) caches the received RoleConfig and stores it so that it can be used in subsequent requests.

[0149] Specifically, the API call method for requesting a model of user configuration data from a client terminal (410) may be as follows:

[0150] MMethodapiHeaderdescpostapp / {v1} / confsessionTokenSessionToken received from auth-login

[0151] The HTTP method used may be POST, and the endpoint format when making a request may be 'app / {v1} / conf'. Here, '{v1}' may be used as a variable indicating the API version. The header information may include 'sessionToken'. This may be a session token value obtained as login result information. The request requested to the backend system (420) may include various attributes such as the user's unique identifier, name, login information, last password change time, activation status, work location information, role code, etc. In addition, information related to the user's role, regulations, and settings may be included. The request may be generated based on current user information. It will be understood by those skilled in the art that the request requested to the backend system (420) as described above is requested to dynamically control the application included in the client terminal (410), more specifically, one or more application configuration items constituting the application.

[0152] In one embodiment, the client terminal (410) includes an application, and the application may include one or more application configuration items. A request to the backend system (420) and the application configuration items of the client terminal (410) may be interrelated, and the functions of the application may be adjusted through the application configuration items. In one embodiment of a method that may be performed by the backend service (420), the backend service (420) may include the steps of: receiving a request for user configuration data from the client terminal (410); determining user configuration data to be transmitted to the client terminal (410); and transmitting the user configuration data to the client terminal (410), thereby causing the client terminal (410) to activate one or more application configuration items based on the user configuration data. Additionally, in one embodiment, the first user configuration data corresponding to the first role and the second user configuration data corresponding to the second role may activate one or more application configuration items differently. Specifically, user configuration data assigned to a first role may enable a specific configuration item to be activated, while user configuration data assigned to a second role may set a corresponding user to not have access to the same configuration item. FIG. 6 illustrates a feature group (610) and a feature (620) included in the feature group (610) according to one embodiment of the present disclosure. The user configuration data may include one or more feature groups (610), each feature group (610) including one or more features (620), and each feature (620) may include one or more key-value pairs (621, 622) associated with the one or more application configuration items. The feature group (610) and the feature (620) may enable the client terminal (410) to control functions provided to users of a specific role.

[0153] Specifically, the backend service (420) can determine user configuration data including one or more feature groups (610) and features (620). More specifically, the backend service (420) can generate user configuration information including one or more feature groups (610) and features (620) by combining a feature ID and an activation key of a feature (620). More specifically, the backend service (420) can determine the user configuration data by combining a feature ID and an activation key of a feature (620) based on current user information of a logged-in user.

[0154] A feature group (610) may refer to a group containing a configuration of items that require control at a specific screen level. The feature group (610) may control functions provided to users of a specific role. Referring to FIG. 6, Delivery Completion and Common are examples of feature groups (610). A feature group (610) may include multiple features (620) within the group. For example, the Delivery Completion feature group of FIG. 6 may include features such as previousCompletionPhoto, photoAttachment, completionButton, addressInfo, relationInvoice, and deliveryMethod.

[0155] A feature (620) refers to the internal detailed functions of an item configuration and may include functions that require control. By controlling the detailed functions of an item component, a feature (620) can restrict or enable functions accessible to specific users. The functions of each component can be controlled based on the activation value of a key within the feature. For example, the PhotoAttachment feature includes two keys, "enableTakePhoto" and "enablePhotoLibrary," which are set to true by default, enabling the photo taking function and the photo library access function.

[0156] For another example, the CompletionButton feature might contain two keys: enableIgnoreAttachPhoto and enableCheck. enableIgnoreAttachPhoto defaults to false, disabling the ignore photo attachment feature. enableCheck defaults to true, enabling the check feature.

[0157] The Common feature group may include the homeBottomTabBar, sideMenu, and globalMap features. For example, the functionality of a global map configuration item may be controlled through the GlobalMap feature. The GlobalMap feature may include two keys. Specifically, the GlobalMap feature may include the support and failover keys. The support key defaults to "naver," enabling support for Naver Maps. The failOver key defaults to "google," enabling fallback to Google Maps if Naver Map support fails. It will be appreciated that such features and feature groups enable the client terminal (410) to control activation according to regional regulations.

[0158] The backend system (420) can generate appropriate user configuration information based on the user role and transmit the user configuration information to the client terminal (410). Based on this user configuration information, the client terminal (410) can activate functions that the user can access or deactivate functions that the user cannot access.

[0159] To help you understand, here's an example of the entire procedure.

[0160] When a user logs in, the client terminal (410) can request user configuration information from the backend system (420) according to the user's role. The backend system (420) can generate user configuration information based on feature groups and features appropriate for the user's role and transmit the information to the client terminal in JSON format. The client terminal (410) can control the functionality of each item configuration in the application by applying the received user configuration information. For example, if the photoAttachment function is disabled on the Delivery Completion screen, the user may not be able to attach a photo.

[0161] In one embodiment, each of the above features can be generated by combining a feature ID and an enable key differently based on either the user's region or role, and each of the generated features can enable the client terminal to dynamically configure the UI. The feature ID can mean an identifier that can uniquely identify the function of a configuration item, and the enable key can refer to a key that allows the use of a specific function or sets a default value that a specific function should have. For example, the enable key can be a Boolean value, a string value, an integer value, or other various types of values. Through the combination of a Boolean enable key and a feature ID, the backend system (420) can indirectly control and expose to the client terminal only the functions required according to the characteristics of a specific user and the assigned task. The enable key that sets a default value such as a string value or an integer value can operate in a way that sets a specific value or state as a default so that the system can reference the value during the initialization and operation process. For example, if "NAVER" is set as the default value, the system may be configured to interact with the NAVER service by default. Similarly, if "GOOGLE" is set as the default value, the system may be configured to interact with the GOOGLE service by default. Through the combination of the activation key and feature ID that set the default value, the backend system (420) can indirectly control and expose to the client terminal only the functions customized according to the characteristics and assigned tasks of a specific user.

[0162] In one embodiment, each key-value pair included in a feature may include information for determining whether one or more application configuration items are enabled or for controlling functionality.

[0163] In one embodiment, the step of the backend system (420) determining the user configuration data includes determining whether the client terminal is authenticated for a first role or a second role; if the client terminal (410) is authenticated for the first role, the backend system (420) may request first user configuration data corresponding to the first role as user configuration data from the server (130) linked with the client terminal (410), and if the client terminal (410) is authenticated for the second role, the backend system (420) may request second user configuration data corresponding to the second role as user configuration data from the linked server (130). Specifically, the backend system (420) may determine whether the client terminal (410) is authenticated for, for example, the first role or the second role to use a specific service or function. Depending on the determined role of the client terminal (410), for example, if the client terminal (410) is authenticated for the first role, the backend system (420) may transmit user data tailored to the needs of an administrator, and if the client terminal (410) is authenticated for the second role, the backend system (420) may transmit data tailored to the needs of a general user. The server (430) is connected to the backend system (420) and can process requests from the backend system (420).

[0164] In one embodiment, the step of determining user configuration data may include determining user configuration data based on the current user information of the logged-in user. The current user information may include data regarding at least one of the user ID, login ID, work location information, and license possession status of the logged-in user. It will be appreciated that by providing only the data necessary for the logged-in user based on the current user information of the logged-in user, the efficiency of network and server resources can be improved. For example, the user configuration data may be determined based on the user ID, which is the current user information of the logged-in user. For example, the current user information may configure information specific to a specific region, work location, or department based on work location information, and may determine the functions or services accessible to the user based on the license possession status. A license may refer to a specific logistics-related qualification or license, and the content of the item configuration activated in the assigned task or application may vary depending on the license possession status.

[0165] FIG. 7 is a diagram illustrating how user configuration information of an invention according to one embodiment of the present disclosure is dynamically configured at runtime. FIG. 7 also describes a method for controlling application functions based on user roles.

[0166] At the top of Fig. 7, a user configuration information model is specifically illustrated. Specifically, the user configuration information model may include i) a user role group and ii) a feature group. Specifically, the user role group may include, for example, whiteCpf_korea, yellowCpf_korea, car_flex_korea, and quick_flex_korea. These groups may be divided into internal and external deliverers, and further divided into whiteCpf_korea and yellowCpf_korea based on license possession, and car_flex_korea and quick_flex_korea based on delivery method. User roles allow users to specify features, permissions, and override functions. For example, the whiteCpf_korea user role may include the user's work region ('region'), permission reference ('ref'), and override functions. That is, among the internal delivery workers, the non-licensed one is identified by the whiteCpf_korea user role, and the whiteCpf_korea user role can indicate that he is located in Korea, has permission references for DeliveryDetail, DeliveryCompletion, ReturnDetail, and FreshbagReturenDetail, and that the DeliveryCompletion and enablePhotoAttachment features are always forced to be enabled. On the other hand, the yellowCpf_korea feature can be identified by the licensed internal delivery worker, and only includes, for example, the specific region and permission reference features, and does not forcefully enable the deliverCompletion and enablePhotoAttachment features. The override feature can mean dynamically enforcing a unique value for a specific setting depending on the user role.

[0167] A feature group in a user configuration information model can contain features identical to the above-mentioned permission references, thereby indicating whether the item configurations of each feature are enabled.

[0168] The runtime of user configuration information indicates that feature values ​​of user configuration information are dynamically changed. Specifically, the runtime may indicate that feature values ​​of a feature group corresponding to a user role are modified and adjusted in real time while the user uses the application on a client terminal. During runtime execution, user configuration information may be expanded on the client terminal and feature functions may be overridden by utilizing user configuration information by feature groups, etc. For example, even though the Boolean value of "enablePhotoAttachment" in the feature value of the user configuration information of the whiteCpf_korea user role is false, it is overridden to true, demonstrating how the backend system (420) dynamically controls the UI of the client terminal (410) based on the user role.

[0169] Specifically, user configuration information can first be expanded (Expand FeatureGroup ref) by referencing the feature group that contains it. For example, this can be adjusted to allow a specific user role to use some or all of the features in the feature group. Additionally, after expanding the feature group reference, final user configuration information can be generated through feature overrides. For example, in the "DeliveryComplete" feature group, since the user role is an internal delivery person located in Korea, the default value for "enablePhotoAttachment" can be set to true to reflect regional characteristics. Through the above, a skilled person will understand how user configuration information dynamically changes at runtime based on the user role.

[0170] FIG. 8 illustrates an example of a result in which a UI on the client terminal (410) side is dynamically configured according to one embodiment of the present disclosure.

[0171] The left screen (810) may illustrate the UI of an external delivery person's client terminal (410), and the right screen (820) may illustrate the UI of an internal delivery person's client terminal (410). Since the UI can be dynamically configured based on user roles, it will be appreciated that the left screen (810) and the right screen (820) may include common item configurations, or may also include different item configurations. For example, for an internal delivery person, the order number and the abuse report information (830) corresponding to the order number may be activated. By controlling this UI dynamic configuration, item configurations appropriate for each user role may be activated or deactivated, thereby optimizing the user experience.

[0172] Figure 9 is a flowchart illustrating a method according to one embodiment of the present disclosure.

[0173] In one embodiment according to the present disclosure, the backend system (420) can receive an API request for retrieving data from a client terminal (S910).

[0174] Specifically, the backend system (420) may receive an API request from the client terminal (410) to retrieve specific data. An API request may refer to a specific request or call attempting to interact with a service or software through an Application Programming Interface (API). Such a request may generally be made through communication between the client and the server. In addition, the client terminal (410) may include various protocols and formats for requesting data. For example, the client terminal (410) may transmit an API request using an HTTP request or another form of protocol, and the backend system (420) may receive the API request.

[0175] In an additional embodiment, the API request may be received by the backend system (420) via an API single access point.

[0176] The backend system (420) can determine whether the client terminal (410) has the authority to respond to the API request based on user configuration data (S920). Specifically, the backend system (420) can analyze the user configuration data to determine whether the user has the authority to perform the requested task. The user configuration data may include user identification information, role or group information, and permission settings. When an API request is received, the backend system (420) can analyze the request and check the authority of the client terminal (410) that sent the request to determine whether the requested task can be performed.

[0177] In response to a determination that authorization exists, the backend system (420) may transmit one or more requests to one or more backend services to retrieve data corresponding to the API request (S930). Specifically, based on the authorization verification result, the backend system (420) may determine that the API request has authorization to access or manipulate specific data, and may transmit multiple requests to the backend services to retrieve data related to the API request. The backend services may be implemented by a server separate from the backend system (420). These requests may include database queries, third-party API calls, or other internal service requests, and each request may be transmitted to a backend service capable of providing or processing the data.

[0178] One or more backend services may be connected to a backend system (420) via a gateway. This may mean that data requests to multiple backend services can be centralized at a single API access point. Each backend service provides specific functionality or data, and these services may be connected to the gateway to interact with the backend system (420). The gateway may be a separate server that mediates data transfer and communication between backend services and the backend system. The gateway can appropriately route requests from the backend system to the backend service, and conversely, forward responses from the backend service to the backend system. The gateway may also perform functions such as security, authentication, and load balancing to facilitate more efficient and secure communication between the backend system and the backend service.

[0179] The backend system (420) can integrate each piece of received data corresponding to one or more requests from one or more backend services according to a predetermined format (S940).

[0180] Specifically, the backend system (420) can temporarily store each piece of received data. The backend system (420) can integrate the received data according to a predetermined format. This integration may include deduplication of received data, automation of data conversion, maintenance of data consistency, and unification of formats. The backend system (420) can perform integration according to rules such as data conversion rules, mapping rules, and data quality management. The predetermined format may be a predefined rule or format, and may be a format for data standardization, normalization, or sorting.

[0181] The backend system (420) can transmit the integrated data to the client terminal as a response to an API request (S950).

[0182] Through this, the client terminal (410) can obtain the effect of receiving integrated data through a single API request for multiple backend services.

[0183] The backend service is implemented as a server (130) and may include a database management service. Additionally, the backend service may include logging and monitoring services. Each backend service may be connected to a centralized, single API access point via an API gateway. This configuration allows a client terminal to receive data from multiple backend services through a single API request. Furthermore, according to the present disclosure, a client can make data requests to multiple backend services through a single API request.

[0184] In one embodiment, the backend system (420) may determine whether each piece of data received from one or more backend services contains personally identifiable information. Specifically, the backend system (420) may analyze the received data to determine whether it contains personally identifiable information. Personally identifiable information may refer to information that can identify or has the potential to identify a specific individual. Personally identifiable information may include, for example, a name, social security number, phone number, email address, etc. In the present disclosure, personally identifiable information goes beyond simply identifying information such as name, address, and phone number, and may include various pieces of information that may require the privacy of the individual. Such information may potentially contain elements that may reveal the individual's private life or identity.

[0185] In response to a determination that each piece of received data contains personally identifiable information, the integrated data may further include a step of tokenizing the personally identifiable information before transmitting the integrated data to the client terminal. Tokenization may refer to the process of replacing sensitive data with a separate value or "token." In the present disclosure, tokenization may include encryption. Specifically, if each piece of received data is determined to contain personally identifiable information, the personally identifiable information may be tokenized before transmitting the integrated data to the client terminal. Tokenization protects the personally identifiable information, thereby enhancing data security. Thereafter, the backend system (420) may replace the personally identifiable information with the generated token to generate integrated data, which may then be transmitted to the client terminal (410).

[0186] A typical technician will understand that performing tokenization at a single API access point, rather than performing tokenization at each backend service, provides efficient security features.

[0187] One embodiment of the present invention comprises an electronic device comprising one or more processors and one or more memories storing instructions executed by the one or more processors. 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 any one of the embodiments described above.

[0188] One embodiment of the present invention includes a non-transitory computer-readable recording medium recording instructions that, when executed by one or more processors, cause the one or more processors to perform operations. The instructions recorded on the non-transitory computer-readable recording medium may be configured to cause one or more processors to execute a method according to any one of the embodiments described above.

[0189] In the flowcharts according to the present disclosure, each step of the method or algorithm is described in a sequential order. However, the steps may be performed in any order that can be arbitrarily combined, in addition to being performed sequentially. The description of the flowcharts or flowcharts of the present disclosure does not exclude changes or modifications to the method or algorithm, and does not imply that any step is essential or desirable. In one embodiment, at least some of the steps may be performed in parallel, iteratively, or heuristically. In another embodiment, at least some of the steps may be omitted, or other steps may be added.

[0190] Various embodiments according to the present disclosure may be implemented as software on a machine-readable storage medium. The software may be software for implementing various embodiments described in the present disclosure. The software may be inferred from various embodiments described in the present disclosure by programmers skilled in the art to which the present disclosure pertains. For example, the software may be a program including machine-readable instructions (e.g., instructions, codes, or code segments). The device may be a device capable of operating according to instructions called from a storage medium, such as a computer. In one embodiment, the device may be a computing device according to various embodiments described in the present disclosure. In one embodiment, the processor of the device may execute the called instructions, causing components of the device to perform functions corresponding to the instructions. The storage medium may refer to any type of recording medium that stores data and can be read by the device. The storage medium may include, for example, ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage, etc. In one embodiment, the storage medium may be implemented in a distributed form, such as in a computer system connected to a network (120). In this case, the software may be distributed, stored, and executed in the computer system. In another embodiment, the storage medium may be a non-transitory storage medium. A non-transitory storage medium refers to a medium that exists regardless of whether data is stored semi-permanently or temporarily (tangible medium), and does not include signals that are transmitted transitively (transitory).

[0191] While the technical concepts of the present disclosure have been described through various embodiments, the technical concepts of the present disclosure encompass various substitutions, modifications, and variations that can be made within the scope understandable to those of ordinary skill in the art to which the present disclosure pertains. Furthermore, it should be understood that such substitutions, modifications, and variations are encompassed within the scope of the appended claims.

Claims

1. A method for managing interaction between a client terminal and the backend system, performed by the backend system, A step of receiving a login resource identifier request from the client terminal; A step of determining whether the received login resource identifier request is a login resource identifier request for a first role or a login resource identifier request for a second role; In response to a determination that the above login resource identifier request is a login resource identifier request for a first role, a step of transmitting a first login resource identifier corresponding to the first role to the client terminal, thereby allowing the client terminal to access a first login interface corresponding to the first login resource identifier; In response to determining that the login resource identifier request is a login resource identifier request for a second role, transmitting a second login resource identifier corresponding to the second role, which is different from the first login resource identifier, to the client terminal, thereby allowing the client terminal to access a second login interface corresponding to the second login resource identifier, which is different from the first login interface; and A step of performing authentication for the first role or the second role based on the first login data input through the first login interface or the second login data input through the second login interface, and transmitting the authentication result information of the authentication to the client terminal. A method comprising:

2. In paragraph 1, The above login resource identifier request includes distinguishing data indicating whether the login resource identifier request is a login resource identifier request for the first role or a login resource identifier request for the second role, The step of determining whether the received login resource identifier request is a login resource identifier request for the first role or a login resource identifier request for the second role is: A step of determining whether the received login resource identifier request is a login resource identifier request for the first role or a login resource identifier request for the second role based on the distinction data included in the login resource identifier request. A method comprising:

3. In paragraph 1, A method wherein performing authentication for the first role based on the first login data includes a more stringent authentication procedure than performing authentication for the second role based on the second login data.

4. In paragraph 1, A method wherein the above authentication result information includes a session token.

5. In paragraph 1, The client terminal includes an application, and the application includes one or more application configuration items, The above method, A step of receiving a user configuration data request from the client terminal; A step of determining user configuration data to be transmitted to the client terminal, wherein the first user configuration data corresponding to the first role and the second user configuration data corresponding to the second role differently activate the one or more application configuration items; A step of transmitting the user configuration data to the client terminal, thereby causing the client terminal to activate the one or more application configuration items based on the user configuration data. A method further comprising:

6. In paragraph 5, The step of determining the user configuration data to be transmitted to the client terminal is as follows: A step of determining whether the client terminal is authenticated for the first role or for the second role; In response to a determination that the client terminal is authenticated for the first role, a step of requesting a server (130) linked with the backend system to transmit first user configuration data corresponding to the first role to the client terminal as user configuration data; and In response to a determination that the client terminal is authenticated for the second role, a step of requesting the server (130) linked with the backend system to transmit second user configuration data corresponding to the second role to the client terminal as user configuration data to be transmitted. A method comprising:

7. In paragraph 5, A method wherein the user configuration data includes configuration data for controlling at least one of whether an application configuration item of the application is activated, how an application screen is displayed, or whether movement to a specific page is permitted on the application.

8. In paragraph 5, The above user configuration data includes user role information, The above user role information includes an internal delivery person, an external delivery person, or a developer.

9. In paragraph 5, The step of determining the user configuration data to be transmitted to the client terminal is: A step of determining the user configuration data based on the current user information of the logged-in user, The above current user information is: A method comprising data regarding at least one of a user ID, login ID, work location information, and license possession of the logged-in user.

10. In paragraph 5, A step of receiving an API request for retrieving data from the client terminal; A step of determining whether the client terminal has authority to respond to the API request based on the user configuration data; In response to a determination that the above authority exists, a step of transmitting one or more requests to one or more backend services, each requesting data corresponding to the API request, wherein the one or more backend services are connected to the backend system via a gateway; In response to receiving data corresponding to the one or more requests from the one or more backend services, a step of integrating each of the received data according to a predetermined format; and A step of transmitting the integrated data to the client terminal as a response to the API request. A method further comprising:

11. In paragraph 10, A step of determining whether each of the data received from the one or more backend services contains personally identifiable information; In response to a determination that each of the received data contains personally identifiable information, a step of tokenizing the personally identifiable information before transmitting the integrated data to the client terminal. A method further comprising:

12. In paragraph 5, A method wherein the user configuration data comprises one or more feature groups, each feature group comprising one or more features, and each feature comprising one or more key-value pairs associated with the one or more application configuration items.

13. In paragraph 12, Each of the above features is created by combining a feature ID and an enable key based on either the user's region or role. A method in which each of the above-mentioned generated features causes a client terminal to dynamically configure a user interface.

14. In paragraph 12, A method wherein each key-value pair included in the above feature includes information for determining whether to activate or control a function of one or more application configuration items.

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

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

Images