TWI894110B - Operating method for electronic apparatus for processing information and electronic apparatus supporting thereof - Google Patents

Abstract

According to the present invention, an information processing method is disclosed, which processes request information by an electronic device, comprising the following steps: setting a request information processing model related to the processing of request information obtained by a service; and processing the request information obtained by the above service based on at least one processing model included in the above request information processing model.

Description

Operation method of electronic device for processing information and electronic device supporting the same

The present invention relates to a method and device for processing information, and more particularly, to a method and electronic device for processing request information obtained through a service.

With the development of electronic technology, e-commerce has become a major area of shopping. Customers can purchase items online without having to go to a shopping mall or market. Items purchased online will be delivered to the customer's requested delivery location.

In the e-commerce sector, since the processing of detailed and accurate product information has a significant impact on service satisfaction, various solutions for more detailed and accurate information processing are being discussed.

For related content, please refer to previous literature such as KR101756594B1 or KR101500849B1.

[Problem to be Solved by the Invention] According to the method of the present invention, an electronic device can process request information obtained through a service by setting a request information processing model.

The technical issues to be achieved by this invention are not limited to the above-mentioned technical issues. Those skilled in the art to which this invention relates will clearly understand other technical issues not mentioned based on the following description. [Technical Means for Solving the Problem]

Various embodiments may provide an operating method of an electronic device for information processing and an electronic device supporting the same.

An information processing method of various embodiments is a method for processing request information by an electronic device, comprising: setting a request information processing model related to processing of request information obtained by a service; and processing the request information obtained by the service based on at least one processing model included in the request information processing model, wherein the request information processing model may include the following models: a first processing model, which limits the number of request information to be processed per unit time to less than a first critical number in each server included in one or more servers associated with the service; a second processing model, which corresponds to a plurality of APIs (Application Programming Interfaces) corresponding to the service. A specific API group among a plurality of first API groups classified by application programming interfaces (APIs) based on importance limits the number of request information to be processed per unit time in each of the above servers to below a second critical number; and a third processing model, which corresponds to each API group included in a plurality of second API groups classified by the above plurality of APIs based on resource usage, limits the number of each request information to be processed to below each critical number set for the above each API group.

In an exemplary embodiment, the request information processing model may include the following models: a fourth processing model, which corresponds to the user of the service and limits the number of request information to be processed per unit time to below the third critical number.

In an exemplary embodiment, the number of request information obtained from the user per unit time can be confirmed by an external cache corresponding to the one or more servers.

In an exemplary embodiment, the number of request information obtained from the user per unit time can be confirmed based on the user's identification information and information about the API the user is using.

In an exemplary embodiment, the information processing method may further include the following step: confirming the information of the API using an API identifier.

In an exemplary embodiment, the request information processing model may include the following models: a fifth processing model, which interrupts the processing of all request information obtained through the service.

In an exemplary embodiment, processing of request information that exceeds a critical number of requests limited by each processing model included in the above-mentioned request information processing model may be refused.

In an exemplary embodiment, the information processing method may further include the following steps: setting each processing model state identification information corresponding to each processing model included in the request information processing model; and based on the each processing model state identification information, confirming the number of request information that is rejected for processing according to each processing model.

In an exemplary embodiment, the at least one processing model may be selected based on a first input from an administrator corresponding to the electronic device.

In an exemplary embodiment, the first critical number, the second critical number, and the critical numbers for each of the API groups may be set based on a second input from an administrator corresponding to the electronic device.

In an exemplary embodiment, the first threshold number, the second threshold number, and the threshold numbers for each of the API groups may be set based on environmental parameter information related to the service.

In an exemplary embodiment, the environmental parameter information may include at least one of information about the number of the one or more servers, information about the total resource capacity used for the service, and information about whether promotions are being conducted on the service for which request information is expected to increase or decrease.

In an exemplary embodiment, the information processing method further includes the following steps: setting a layer structure corresponding to the request information processing model; and based on the layer structure, the request information processing model can be applied to the algorithm used for the operation of the electronic device.

A non-transitory computer-readable recording medium according to various embodiments records a program for executing an information processing method in a computer, wherein the information processing method comprises the following steps: setting a request information processing model related to processing of request information obtained through a service; and processing the request information obtained through the service based on at least one processing model included in the request information processing model; and the request information processing model may include the following models: a first processing model that limits the number of request information to be processed per unit time in each of one or more servers associated with the service to less than a first critical number; a second processing model that corresponds to a plurality of APIs (Application Programming Interfaces) corresponding to the service. A specific API group among a plurality of first API groups classified by application programming interfaces (APIs) according to importance limits the number of request information to be processed per unit time in each of the above servers to below a second critical number; and a third processing model corresponds to each API group included in a plurality of second API groups classified by the above plurality of APIs according to resource usage, limiting the number of each request information to be processed to below each critical number set for the above each API group.

An electronic device of various embodiments processes request information, comprising: a processor; and one or more memories storing one or more instructions; when the one or more instructions are executed, the processor is controlled to perform the following steps: setting a request information processing model related to processing of request information obtained through a service; and processing the request information based on the request information. At least one processing model included in the processing model processes the request information obtained by the above service; the above request information processing model may include the following models: a first processing model, which limits the number of request information to be processed per unit time to less than a first critical number in each server included in one or more servers associated with the above service; a second processing model, which corresponds to the plurality of APIs (Application Programming Interfaces) corresponding to the above service. Programming Interfaces) by classifying a specific API group in a first plurality of API groups according to importance, limiting the number of request information to be processed per unit time in each of the above servers to below a second critical number; and a third processing model, which corresponds to each API group included in a second plurality of API groups according to resource usage classification of the above plurality of APIs, limiting the number of request information to be processed to below each critical number set for the above each API group.

The various embodiments of the present invention described above are merely some of the preferred embodiments of the present invention. Those skilled in the art can derive and understand various embodiments reflecting the technical features of the various embodiments of the present invention based on the detailed description below. [Effects of the Invention]

The present invention proposes a method for an electronic device to process request information obtained through a service by setting a request information processing model, which has the technical effect of efficiently implementing the processing of request information.

The effects that can be obtained by the present invention are not limited to the effects described above. Those skilled in the art can clearly understand other technical effects not mentioned based on the following description.

The following embodiments combine the components and features of the various embodiments in specific configurations. Unless otherwise expressly stated, each component or feature is considered optional. Each component or feature can be implemented without being combined with other components or features. Furthermore, various embodiments can be constructed by combining some components and features. The order of actions described in the various embodiments may be varied. Some components or features of one embodiment may be included in other embodiments, or may replace corresponding components or features of other embodiments.

In the description of the drawings, procedures or steps that may obscure the gist of the various embodiments are not described, nor are procedures or steps that can be understood at the level of a person having ordinary skill in the art described.

Throughout this specification, when it is stated that a certain part "comprising or including" a certain component, unless otherwise stated, it means that other components may be further included, and other components are not excluded. In addition, terms such as "...part", "...device", and "module" described in the specification refer to a unit that processes at least one function or action, which can be implemented by hardware, software, or a combination of hardware and software. In addition, in the text describing various embodiments (especially in the scope of the invention application below), unless otherwise indicated in this specification or not explicitly contradicted in the text, "a (or an)", "one (one)", "the (the)" and similar related words can be used to include both the singular and the plural meaning.

Hereinafter, with reference to the accompanying drawings, preferred embodiments of the present invention will be described in detail. The detailed description disclosed below together with the accompanying drawings is intended to illustrate exemplary embodiments of the present invention and is not intended to represent the only embodiment.

Furthermore, specific terms used in various embodiments are provided to facilitate understanding of the various embodiments, and the use of such specific terms may be changed into other forms without departing from the technical concepts of the various embodiments.

FIG1 is a diagram of an information processing system for illustrating the operation method of an electronic device for information processing that can implement various embodiments.

Referring to Figure 1 , the information processing systems of various embodiments can be implemented in various types of devices. For example, the information processing system can be implemented in a service-related electronic device 100, a user device 200 capable of utilizing the service, and a server device 300 used for providing the service. In other words, the service-related electronic device 100, the user device 200, and the server device 300 can perform the operations of the various embodiments of the present invention based on the information processing systems implemented in each device. Furthermore, the information processing systems of various embodiments are not limited to those shown in Figure 1 above and can be implemented in a wider variety of devices.

The electronic device 100 of various embodiments may correspond to a device that implements the information processing method proposed in the present invention related to services and manages the processing of information sent and received between the user device 200, the server device 300, and the service. In the present invention, the electronic device 100 may be configured to include the functions of the user device 200 or the server device 300.

The user device 200 of various embodiments can be a device that can be used by a personal user, such as a desktop computer, a tablet computer, a mobile terminal, etc. In addition, other devices that perform similar functions can also be used as the user device 200.

The server device 300 of various embodiments may be a device that performs wireless and wired communication with a plurality of user devices 200 and includes a storage device with a large unit of storage capacity. For example, the server device 300 may include a cloud device connected to a plurality of user devices 200.

The information processing systems of various embodiments may include various modules for performing operations. The modules included in the information processing system may be computer code or one or more instructions that enable a physical device (e.g., electronic device 100, user device 200, and server device 300) that implements the information processing system (or that is included in the physical device) to perform a specific operation. In other words, the physical device that implements the information processing system stores multiple modules in memory in the form of computer code, and when the multiple modules stored in the memory are executed, the multiple modules can be caused to perform the specific operations corresponding to the multiple modules by the physical device.

FIG2 is a diagram showing the configuration of a device node according to various embodiments.

The device node of FIG. 2 may include the electronic device 100 , the user device 200 , and the server device 300 constituting the information processing system of FIG. 1 , and the device node of FIG. 2 may include an input/output unit 210 , a communication unit 220 , a memory 230 , and a processor 240 .

The input/output unit 210 can be any interface or port for receiving user input or outputting information to the user. The input/output unit 210 can include an input module and an output module. The input module receives user input. User input can be implemented in various forms, such as key input, touch input, and voice input. Examples of input modules that can receive such user input include traditional keypads or keyboards, and mice. In addition, they also include touch sensors that sense user touch, microphones that receive sound signals, cameras that recognize gestures through image recognition, proximity sensors that include at least one of an illumination sensor or an infrared sensor that senses user approach, motion sensors that recognize user movements through an accelerometer or a gyroscope sensor, and various types of input mechanisms that sense or receive other forms of user input. The input module of the embodiments of the present invention may include at least one of the devices listed above. Here, the touch sensor can be implemented as a piezoelectric or electrostatic touch sensor that senses touch via a touch panel or touch film attached to the display panel, or an optical touch sensor that senses touch optically. Furthermore, the input module can also be implemented as an input interface (such as a USB (Universal Serial Bus) port or PS/2 (Personal System 2) port) that connects to an external input device that receives user input, replacing a device that senses user input. Furthermore, the output module can output various types of information. The output module may include at least one of a display for outputting images, a speaker for outputting sounds, a tactile device for generating vibrations, and other various types of output mechanisms. Furthermore, the output module may also be implemented in the form of a port-type output interface that connects to the above-mentioned output mechanisms.

For example, an output module in the form of a display can display text, static images, and video. Displays may include at least one of various types of devices capable of image output, such as liquid crystal displays (LCDs), light emitting diode (LED) displays, organic light emitting diode (OLED) displays, flat panel displays (FPDs), transparent displays, curved displays, flexible displays, 3D displays, holographic displays, and projectors. Such displays may also be touch displays integrated with the touch sensor of the input module.

The communication unit 220 can communicate with other devices. Therefore, device nodes associated with the service can send and receive information with other devices via the communication unit. For example, device nodes can use the communication unit to communicate with each other or with other devices.

Here, communication, i.e., the transmission and reception of data, can be achieved either wired or wirelessly. For this purpose, the communication unit can be configured as: a wired communication module connected to the Internet via a LAN (Local Area Network), a mobile communication module connected to a mobile communication network via a mobile communication base station to transmit and receive data, a short-range communication module utilizing a WLAN (Wireless Local Area Network) communication method such as Wi-Fi or a WPAN (Wireless Personal Area Network) communication method such as Bluetooth or Zigbee, a satellite communication module utilizing a GNSS (Global Navigation Satellite System) such as GPS (Global Positioning System), or a combination thereof.

Memory 230 can store various types of information. Memory 230 can store data temporarily or semi-permanently. For example, a device node's memory 230 can store data related to the operating system (OS) that drives the device node, data used to host a website, or programs or applications used to generate Braille (e.g., website applications). Furthermore, memory 230 can store modules in the form of computer code, as described above.

Examples of the memory 230 include a hard disk drive (HDD), a solid state drive (SSD), a flash memory (Flash Memory), a read-only memory (ROM), and a random access memory (RAM). The memory 230 can be provided as a built-in or removable type.

Processor 240 controls the overall operation of the device node. To this end, processor 240 can perform various information calculations and processing, and control the operation of each component of the device node. For example, processor 240 can execute programs and applications for information processing. Processor 240 can be implemented by a computer or similar device based on hardware, software, or a combination thereof. In terms of hardware, processor 240 can be implemented in the form of a circuit that processes electrical signals and performs control functions. In terms of software, it can be implemented in the form of a program that drives the hardware processor 240. On the other hand, in the following description, unless otherwise specified, the actions of the device nodes can be interpreted as being performed under the control of the processor 240. That is, when executing the modules implemented in the above-mentioned information processing system, the modules can be interpreted as controlling the processor 240 to cause the device nodes to perform the following actions.

In short, various embodiments can be implemented by various mechanisms. For example, various embodiments can be implemented by hardware, firmware, software, or a combination thereof.

In the case of hardware implementation, the methods of various embodiments may be implemented by one or more ASICs (application specific integrated circuits), DSPs (digital signal processors), DSPDs (digital signal processing devices), PLDs (programmable logic devices), FPGAs (field programmable gate arrays), processors, controllers, microcontrollers, microprocessors, etc.

When implemented via firmware or software, the methods of various embodiments may be implemented in the form of modules, procedures, or functions that perform the functions or actions described below. For example, the software code may be stored in memory and driven by a processor. The memory may be internal or external to the processor and may exchange data with the processor via various well-known mechanisms.

The following describes various embodiments in more detail based on the above technical concepts. The above descriptions can be applied to the various embodiments described below. For example, actions, functions, and terms not defined in the various embodiments described below can be implemented and described based on the above descriptions.

In the following description, various embodiments are described based on the premise that the service-related electronic device 100 implements operations for the information processing method.

FIG3 is a structural diagram showing an electronic device for implementing the information processing method proposed by the present invention.

In Figure 3 , electronic device 100 implementing the information processing method may include a communication device 301, a control unit 303, and a memory 305. The components included in electronic device 100 in Figure 3 may correspond to the components of the device node in Figure 2 , or the electronic device 100 in Figure 3 may include the components of the device node in Figure 2 . For example, communication device 301 included in electronic device 100 in Figure 3 may correspond to communication unit 220 included in the components of the device node in Figure 2 .

The electronic device 100 in FIG. 3 may have the following functions: communicating with other devices via the communication device 301 .

The control unit 303 can control the electronic device 100 to implement the information output method of various embodiments, including those described below in Figures 4 through 14. For example, the control unit 303 can control the electronic device 100 to implement actions 401 through 403 described below in Figure 4 and control the electronic device 100 to store and transmit various information required to implement actions 401 through 403 in Figure 4.

The memory 305 may be a volatile memory or a non-volatile memory, so that the control unit 303 can store the program code required to execute the program for implementing the information output method in the memory 305.

In the present invention, the electronic device 100 for implementing the information output method is not limited to the structure shown in FIG. 3 , and in addition to the various components shown in FIG. 3 , the electronic device 100 of the present invention may also include other common components.

FIG4 is a diagram illustrating an operation method of an electronic device for information processing according to various embodiments.

4 , the electronic device 100 may process request information and execute an action to process request information. It may set a request information processing model 401 related to the processing of request information obtained through a service, and may process request information 403 obtained through a service based on at least one processing model included in the request information processing model.

As shown in FIG4 , the electronic device 100 may configure a request information processing model and process request information for a service related to the electronic device 100. The service may correspond to a service in which multiple users utilizing the service order and purchase multiple items sold within the service. The multiple items sold within the service may include various types or categories of items registered by the seller for sale, and are not limited to the type or category of the items.

According to various embodiments, in action 401, the electronic device 100 may set a request information processing model related to processing request information obtained through a service.

For example, the request information processing model configured by electronic device 100 in accordance with action 401 may include a first processing model that limits the number of request information processed per unit time by each of one or more servers associated with the service to a first critical number or less. Hereinafter, the one or more servers or each server described below may be understood as corresponding to server device 300 in FIG. 1 .

The first processing model described above is a processing model for reducing the load generated when processing request information on each of the one or more servers associated with the service, and the first processing model can be configured to be applied based on the selection input of an administrator who applies the first processing model. For example, if the number of request information to be processed per unit time by one or more servers is determined to be greater than a fixed number, and the administrator of the electronic device 100 determines that the number of request information to be processed per unit time by each server is excessive, the administrator can select and input the application of the first processing model. By applying the first processing model based on the administrator's selection input, the number of request information to be processed per unit time by each server can be limited to or below the first critical number.

Alternatively, in addition to administrator input, the electronic device 100 can be configured to apply the first processing model when certain conditions are met. For example, a condition can be set such that the number of request information to be processed per unit time by one or more servers must be at least a fixed number, and the first processing model can be used. The electronic device 100 can then manage the situation by automatically applying the first processing model when these conditions are met, limiting the number of request information to be processed per unit time by each server to below the first critical number.

Here, the first critical number set for the first processing model may be a value set by an administrator input.

FIG5 is a diagram showing an example of a first processing model included in the setting request information processing model.

In FIG5 , the electronic device 100 is managed as follows: request information obtained from a plurality of users utilizing the service is processed by one or more servers associated with the service (500). At this time, the first processing model can be applied in the same form as 501, which limits the number of request information to be processed per unit time in each server to within a specific critical number.

In Figure 5, by applying the first processing model, the number of request messages that each server must process per minute can be limited to 10,000 or less. This first processing model can also be set by administrator input or automatically applied based on the following situation: the number of request messages that one or more servers must process per minute is confirmed to be greater than 30,000.

For example, the request information processing model set by the electronic device 100 according to action 401 may include a second processing model, which corresponds to a specific API group in a plurality of first API groups in which a plurality of APIs (Application Programming Interfaces) corresponding to the service are classified according to importance, and the number of request information to be processed per unit time in each of the above-mentioned servers is limited to below the second critical number.

The second processing model described above is equivalent to a processing model for preventing the load generated when processing request information corresponding to an API group with a specific importance in each server included in one or more servers associated with the service, and the second processing model can be set to be applied based on the selection input of the administrator who applies the second processing model.

The various APIs on a service may have different levels of importance. It is important for the electronic device 100 to manage these APIs so that it can primarily process request information received from APIs with higher importance. Therefore, the electronic device 100 divides the various APIs on a service into a group with higher importance and a group with lower importance based on their importance. The electronic device 100 can limit the processing of request information received from the group with lower importance so that it can primarily process request information received from the group with higher importance.

For example, when the number of request information to be processed per unit time by one or more servers corresponding to an API group with lower importance is confirmed to be greater than a fixed number, the administrator of the electronic device 100 determines that the number of request information processed corresponding to the API group with lower importance in each server has increased, thereby generating a load in the processing of request information corresponding to the API group with higher importance. In this case, the administrator can make a selection input to apply the second processing model. By using the administrator's selection input to apply the second processing model, the number of request information to be processed per unit time corresponding to the API group with lower importance in each server can be limited to below the second critical number. By applying this second processing model, a certain level of processing capacity per unit time for request information corresponding to a highly important API group can be secured in each server.

Alternatively, in addition to administrator input, the electronic device 100 can be configured to apply a second processing model when certain conditions are met. For example, for API groups with lower importance, a condition can be set such that the number of request information to be processed per unit time by one or more servers is set to be at least a fixed number, and the second processing model can be used. The electronic device 100 can manage the situation by automatically applying the second processing model when these conditions are met, limiting the number of request information to be processed per unit time for API groups with lower importance on each server to below the second critical number.

Here, the second critical number set for the second processing model can be a value set by an administrator. Furthermore, for the second processing model, the electronic device 100 can pre-identify and manage information regarding the importance of each API, and can also implement the following operation based on the information regarding the importance of each API, namely, dividing the various APIs on the service into API groups with higher importance and API groups with lower importance.

Regarding the second processing model, examples of more important APIs include the API used to provide the checkout page when purchasing items and the API used to add items to the shopping cart. Examples of less important APIs include the API used to confirm the user's checkout mechanism and the API used to request plastic bags when ordering items.

FIG6 is a diagram showing an example of a second processing model included in the setting request information processing model.

In FIG6 , the electronic device 100 can manage request information received from multiple users using a service by dividing it into request information corresponding to an API group with higher importance on the service and request information corresponding to an API group with lower importance, and can process the request information corresponding to each API group by one or more servers associated with the service ( 600 ). In this case, the second processing model can be applied in the same form as 601 , which limits the number of request information to be processed per unit time to within a specific critical number for each server corresponding to the API group with lower importance.

In Figure 6, by applying the second processing model, the number of request messages processed per minute for API groups with lower importance on each server can be limited to 8,000 or less. This second processing model can also be set based on administrator input or automatic application if the number of request messages processed per minute for API groups with lower importance on one or more servers is confirmed to be 24,000 or more. By applying the same second processing model as in Figure 601, each server can ensure a certain level of processing capacity per unit time for request messages corresponding to API groups with higher importance.

For example, the request information processing model set by the electronic device 100 according to action 401 may include a third processing model, which corresponds to each API group included in a plurality of second API groups that classify a plurality of APIs (Application Programming Interfaces) according to resource usage, and limits the number of request information to be processed to below the critical number set for each of the above API groups.

The third processing model described above is equivalent to a processing model for preventing the remaining resource capacity of each managed API group from reaching zero during the process of processing request information corresponding to a plurality of second API groups classified according to resource usage in each server included in one or more servers associated with the service, and the third processing model can be set to be applied based on the selection input of the administrator who applies the third processing model.

The various APIs on a service may consume different amounts of resources, and it may be important for the electronic device 100 to manage the resources used by each API in a manner that does not exceed the resource usage of each API. Therefore, the electronic device 100 can manage the various APIs on a service by classifying them into API groups with higher resource usage, API groups with medium resource usage, and API groups with lower resource usage based on their resource usage. Fixed resource capacity can be allocated to each API group, and request information received can be primarily processed within the allocated resource capacity.

For example, 1) a fixed resource capacity can be allocated to an API group with high resource usage, and the critical number l of request information that can be processed based on the allocated resource capacity can be determined; 2) a fixed resource capacity can be allocated to an API group with medium resource capacity, and the critical number n of request information that can be processed based on the allocated resource capacity can be determined; 3) a fixed resource capacity can be allocated to an API group with low resource usage, and the critical number m of request information that can be processed based on the allocated resource capacity can be determined. When the administrator of the electronic device 100 wishes to manage resources within the capacity allocated to each API group, the administrator may select input to apply the third processing model. By utilizing the administrator's selection input to apply the third processing model, the number of processed request information for each API group may be limited to within the confirmed critical number of each API group.

Here, each critical number set for the third processing model can be a value set by an administrator. Furthermore, for the third processing model, the electronic device 100 can pre-check and manage information about the resource usage of each API. Based on this information, the electronic device 100 can also categorize the various APIs on the service into a group with high resource usage, a group with medium resource usage, and a group with low resource usage.

Regarding the third processing model, examples of APIs with high resource usage include landing APIs and purchase execution APIs corresponding to purchase button input. Examples of APIs with medium resource usage include APIs for setting schedules such as delivery dates. Furthermore, examples of APIs with low resource usage include APIs for changing delivery addresses and APIs for entering personal pass codes related to overseas direct purchases.

FIG7 is a diagram showing an example of a third processing model included in the setting request information processing model.

In FIG7 , the electronic device 100 can manage request information received from a plurality of users utilizing a service by classifying request information received from the service corresponding to an API group with high resource usage, request information received from an API group with medium to high resource usage, and request information received from an API group with low resource usage, and processing the request information received from each API group by one or more servers associated with the service ( 700 ). At this time, the third processing model can be applied in the same manner as 701 , limiting the number of request information to be processed for each API group to within a threshold number set for each API group.

In Figure 7, by applying the third processing model, the number of request messages to be processed for API groups with high resource usage can be limited to 1,000, the number of request messages to be processed for API groups with medium resource usage can be limited to 5,000, and the number of request messages to be processed for API groups with low resource usage can be limited to 10,000. This ensures that the resource capacity for each API group cannot be reduced to zero. Furthermore, this third processing model can be set to be applied by administrator input.

For example, the request information processing model set by the electronic device 100 according to action 401 may include a fourth processing model, which limits the number of request information to be processed per unit time to below a third critical number corresponding to the user of the service.

The fourth processing model described above corresponds to a processing model for preventing a load from being generated by excessive request information received in a short period of time due to repeated input from a specific user in each of the one or more servers associated with the service, and the fourth processing model can be set to be applied based on the selection input of an administrator who applies the fourth processing model.

On services, users can perform various inputs through various APIs, generating request information corresponding to the user inputs, which is then processed by each server. However, if users repeatedly input through clicks or touches, or use macros to generate a large number of request information in a short period of time, even if the server is allowed to process all of them, it will generate unnecessary load. Therefore, it is very important to manage the electronic device 100 in a way that avoids the same problems. Therefore, the electronic device 100 can manage the following: for each user on the service, the number of request information received per unit time is confirmed, and when necessary, the number of request information to be processed per unit time for each user is limited to below the third critical number.

Here, the third critical number set for the fourth processing model can be a value set by the administrator's input.

For example, the number of request information received from users per unit time can be checked using an external cache shared by one or more servers associated with a service. Specifically, unlike other processing models where caches are set up individually for each server in a server-based system, the fourth processing model uses a single external cache shared by one or more servers, making it easy to track the number of request information received from users.

For example, the number of request information received per unit time from a user can be determined based on the user's identification information and the information about the API the user is currently using. Specifically, since a large number of request information generated by repeated user input is likely to be actions performed within a specific API, the electronic device 100 can effectively utilize the user's identification information and the information about the API the user is currently using to track request information determined by the same user action.

For example, electronic device 100 can use API identifiers to identify the API information currently being used by the same user as described above. The definitions of terms, information processing paths, and event names used in each API may vary. Therefore, electronic device 100 can set an identifier to identify each API and use the set identifier to track information about the APIs currently being used by the user.

FIG8 is a diagram showing an example of the fourth processing model included in the setting request information processing model.

In FIG. 8 , the electronic device 100 can manage in the following manner: request information obtained from a plurality of users utilizing a service can be divided into request information corresponding to each user, and the request information corresponding to each user is processed by one or more servers associated with the service ( 800 ).

In FIG8 , by applying the fourth processing model, management is performed in such a manner that the number of request information corresponding to a specific user identified by identification information does not exceed 20 per minute (801). In order to confirm the request information obtained per unit time for each user, an external cache (803) corresponding to one or more servers can be set. This fourth processing model can be set in a manner that is applied according to the administrator's selection input.

For example, the request information processing model set by the electronic device 100 according to action 401 may include a fifth processing model that interrupts the processing of all request information obtained through the service.

The fifth processing model described above is equivalent to interrupting the processing model used to process all request information when a problem occurs in processing request information by one or more servers associated with the service, and the fifth processing model can be set to be applied based on the selection input of the administrator who applies the fifth processing model.

The fifth processing model can be configured as follows: each server unit is instructed to suspend request information processing so that the request information is not processed in each server, or the front end is instructed to suspend request information processing before the request information is transmitted to each server so that the request information is not processed in each server.

FIG9 is a diagram showing an example of the fifth processing model included in the setting request information processing model.

In FIG9 , the electronic device 100 can be managed by the fifth processing model in such a manner that all request information obtained by the service is prevented from being processed by each server ( 900 ), and this fifth processing model can be set to be applied according to the administrator's selection input.

For example, you can refuse to process a request message that exceeds a critical number of restrictions based on the processing models included in the request message processing model.

For example, the electronic device 100 may determine the number of request messages that were rejected based on each processing model included in the request information processing model. Specifically, the electronic device 100 may set each processing model state identification information corresponding to each processing model included in the request information processing model, and based on each processing model state identification information, determine the number of request messages that were rejected based on each processing model.

According to various embodiments, in action 403, the electronic device 100 may process the request information obtained through the service based on at least one processing model included in the request information processing model.

For example, according to action 403, the electronic device 100 can effectively utilize at least one processing model for processing request information, selected from the first processing model to the fifth processing model by the first input of the administrator of the electronic device 100. In other words, the administrator of the electronic device 100 can select the processing model to be applied to the processing request information according to the situation.

For example, according to action 403, the electronic device 100 may set the critical number of requests to be processed in each processing model included in the request information processing model configured for processing the request information based on the second input from the administrator of the electronic device 100. In other words, the administrator of the electronic device 100 may set the critical number of requests to be processed in each processing model as appropriate.

For example, according to action 403, the electronic device 100 may set, based on service-related environmental parameter information, the threshold number of requests to be processed in each processing model included in the request information processing model configured to process the request information. In other words, the electronic device 100 can be managed in such a way that the administrator of the electronic device 100 does not set the threshold number of requests to be processed in each processing model, but rather sets the threshold number of requests to be processed in each processing model based on service-related environmental parameter information.

For example, the environmental parameter information described above may include at least one type of information about parameters that can affect the server's request information processing, such as information about the number of the one or more servers, information about the total resource capacity used for the service, and/or information about whether to conduct promotions on the service for which request information is expected to increase or decrease.

Alternatively, electronic device 100 may configure a layer structure to apply the request information processing model configured for processing request information according to FIG. 4 to a general algorithm. Specifically, electronic device 100 may configure a layer structure corresponding to the request information processing model, and based on the configured layer structure, the request information processing model may be applied to the general algorithm used for the operation of electronic device 100.

FIG. 10 is a diagram showing an example of a layer structure for applying the request information processing model to an algorithm for operating the electronic device 100.

In FIG. 10 , when the electronic device 100 sets the first to fifth processing models to process request information ( 1001 ), a facade layer structure ( 1003 ) that can apply the first to fifth processing models can be set in the Bucket4J core algorithm 1005 , which is an example algorithm among the algorithms used for the operation of the electronic device 100 .

As shown in Figure 10, the first processing model corresponds to the "Server Rate Limit," the second processing model corresponds to the "Reserved Rate Limit," the third processing model corresponds to the "Concurrent Rate Limit," the fourth processing model corresponds to the "API+Client Rate Limit," and the fifth processing model corresponds to the "Kill Switch."

Needless to say, according to FIG. 4 to FIG. 10 , the information set or processed by the electronic device 100 in the process of implementing the information processing method can be combined in various forms.

Figures 11 through 14 illustrate an example of processing request information based on a request information processing model including the first through fifth processing models. For example, the example of Figures 11 through 14 may involve processing request information generated in response to input from a user device 200 in a server device 300, and may implement the various embodiments described in the following figures based on the operations of the electronic device 100 described above in Figures 4 through 10.

Specifically, the embodiments described in the following figures can be implemented in the following manner: when user device 200 receives input information from a user and transmits request information related to the input information to server device 300, server device 300 can process the request information based on the actions of electronic device 100 shown in Figures 4 to 10. However, the embodiments described in the following figures are not limited to this embodiment and can be implemented in all forms that can implement the embodiments.

FIG. 11 is a diagram showing an example of processing request information based on a request information processing model according to various embodiments.

In Figure 11, it can be seen that the fifth processing model, which is equivalent to a "self-destruct switch," and the first processing model, which is equivalent to a "server rate limit," are applied based on the request information processing model. The administrator corresponding to the electronic device 100 sets the fifth processing model to off (1101), and can set it back to on when it is necessary to interrupt the processing of all request information.

Furthermore, in FIG11 , the administrator corresponding to the electronic device 100 can confirm that the processing of request information in each server will generate a load. For example, when the number of request information that needs to be processed per minute is more than 100,000 ( 1103 - 1 ), based on the first processing model, the number of request information to be processed per minute in each server can be limited to less than 10,000 ( 1103 - 2 ).

At this time, the application of each processing model described above is not limited to the order shown in Figure 11. Each processing model can be applied based on the input of the administrator corresponding to the electronic device 100 or whether each processing model meets the preset conditions.

FIG12 illustrates another example of request information processing based on the request information processing model of various embodiments. For convenience, FIG12 illustrates the fourth processing model applied in addition to the example of FIG11 . However, the application of the fourth processing model is not limited to FIG12 ; the fourth processing model can be applied alone or in combination with various other processing models.

In Figure 12, we can see that based on the request information processing model, the fifth processing model, which is equivalent to a "self-destruct switch," the first processing model, which is equivalent to a "server rate limit," and the fourth processing model, which is equivalent to a "API + client rate limit," are applied. Similar to the description in Figure 11, the administrator corresponding to electronic device 100 in Figure 12: 1) sets the fifth processing model to off (1201); 2) in response to the number of request information to be processed per minute exceeding 100,000, the first processing model is used to limit the number of request information to be processed per minute on each server to 10,000 or less (1203-1, 1203-2).

Furthermore, in FIG12 , when the number of request information received from a user by the administrator corresponding to the electronic device 100 is more than 20 per minute, or the number of request information received from the user is input more than 20 times per minute ( 1205 - 1 ), based on the fourth processing model, the number of request information to be processed per minute for the corresponding user can be limited to less than 20 ( 1205 - 2 ).

At this time, the application of each processing model described above is not limited to the order shown in Figure 12. Each processing model can be applied based on the input of the administrator corresponding to the electronic device 100 or whether each processing model meets the preset conditions.

FIG13 illustrates another example of request information processing based on the request information processing model of various embodiments. For convenience, FIG13 illustrates a second processing model applied in addition to the example of FIG12 . However, the application of the second processing model is not limited to FIG13 ; the second processing model can be applied alone or in combination with various other processing models.

In FIG13 , it can be confirmed that based on the request information processing model, the fifth processing model equivalent to the “self-destruct switch”, the first processing model equivalent to the “server rate limit”, the fourth processing model equivalent to the “API+client rate limit”, and the second processing model equivalent to the “retention rate limit” are applied. As described in FIG12 , the administrator corresponding to the electronic device 100 in FIG13 : 1) sets the fifth processing model to off ( 1301 ), 2) when the number of request information to be processed per minute is more than 100,000, the number of request information to be processed per minute in each server is limited to within 10,000 ( 1 303-1, 1303-2), 3) When the number of request information received from a user is more than 20 per minute, or the input for the request information received from the user is more than 20 times per minute, based on the fourth processing model, the number of request information to be processed per minute corresponding to the user can be limited to less than 20 (1305-1, 1305-2).

Furthermore, in FIG13 , the administrator corresponding to the electronic device 100 can manage in the following manner: when the multiple APIs (Application Programming Interfaces) corresponding to the service are classified into an API group with higher importance and an API group with lower importance according to their importance, since the number of request information processed for the API group with lower importance is more than 8,000, it is determined to be excessive ( 1307 - 1 ). Based on the second processing model, the number of request information to be processed per unit time in each server can be limited to less than 8,000 for the API group with lower importance, and 2,000 request information can be processed per unit time in each server for the API group with higher importance ( 1307 - 2 ).

At this time, the application of each processing model described above is not limited to the order shown in Figure 13. Each processing model can be applied based on the input of the administrator corresponding to the electronic device 100 or whether each processing model meets the preset conditions.

FIG14 illustrates another example of request information processing based on the request information processing model of various embodiments. For convenience, the example of FIG14 shows a third processing model applied in addition to the example of FIG13 . However, the application of the third processing model is not limited to FIG14 ; the third processing model can be applied alone or in combination with various other processing models.

In Figure 14, we can see that based on the request information processing model, the fifth processing model, equivalent to the "self-destruct switch," the first processing model, equivalent to the "server rate limit," the fourth processing model, equivalent to the "API + client rate limit," the second processing model, equivalent to the "retention rate limit," and the third processing model, equivalent to the "concurrent limit," are applied. As described in FIG13 , the administrator corresponding to the electronic device 100 in FIG14 : 1) sets the fifth processing model to off ( 1401 ); 2) when the number of request information to be processed per minute is more than 100,000, the number of request information to be processed per minute in each server can be limited to 10,000 or less based on the first processing model ( 1403-1 , 1403-2 ); 3) when the number of request information received from a user is more than 20 per minute, or the number of request information received from a user is input more than 20 times per minute, the number of request information to be processed per minute corresponding to the user can be limited to less than 20 based on the fourth processing model ( 1405-1 , 1405-2 ). In addition, the administrator corresponding to the electronic device 100 can manage in the following manner: 4) When it is confirmed that the number of request information processed corresponding to the API group with lower importance is more than 8,000, according to the second processing model, corresponding to the API group with lower importance, the number of request information to be processed per unit time in each server is limited to less than 8,000, and corresponding to the API group with higher importance, 2,000 request information can be processed per unit time in each server (1407-1, 1407-2).

In addition, in FIG14 , the manager corresponding to the electronic device 100 can manage the following manner: according to the resource usage, multiple APIs (Application Programming When APIs (application programming interfaces) are classified into an API group with high resource usage, an API group with medium resource usage, and an API group with low resource usage, the number of request messages processed corresponding to the API group with high resource usage is determined to exceed the resource capacity allocated to the API group with high resource usage (1409-1). Based on the third processing model, the resource capacity allocated to the API group with high resource usage is used to limit the request message processing of the API group so that the critical number of processable request messages is within 1,000. Therefore, the API group with high resource usage can process a maximum of 1,000 request messages (1409-2).

At this time, the application of each processing model described above is not limited to the order shown in Figure 14. Each processing model can be applied based on the input of the administrator corresponding to the electronic device 100 or whether each processing model meets the preset conditions.

The examples of Figures 11 to 14 can be implemented in association with the actions of the electronic device 100 described in Figures 4 to 10. The examples of Figures 11 to 14 are used to disclose an example of the present invention. Various embodiments of the present invention are not limited to the example forms of Figures 11 to 14, and can be implemented according to all forms of various embodiments that can implement the present invention.

The embodiments of the present invention disclosed in this specification and drawings are intended merely to illustrate the technical content of the present invention and to provide specific examples to facilitate understanding of the present invention. They are not intended to limit the scope of the present invention. In other words, those skilled in the art will readily appreciate that other variations based on the technical principles of the present invention can be implemented. Furthermore, each of the above embodiments can be combined and utilized as needed. For example, all of the embodiments of the present invention may be combined in part to implement a system.

Furthermore, the system and methods of the present invention can be implemented in the form of program commands executed by various computer mechanisms and recorded in a computer-readable medium.

As described above, in certain aspects, various embodiments of the present invention may be implemented as computer-readable code in a computer-readable recording medium. A computer-readable recording medium is any data storage device capable of storing data that can be read by a computer system. Examples of computer-readable recording media may include read-only memory (ROM), random access memory (RAM), compact disk-read-only memory (CD-ROM), magnetic tape, floppy disk, optical data storage devices, and carrier waves (for data transmission over the Internet, etc.). The computer-readable recording medium can also be distributed by computer systems connected to a network, thereby storing and executing computer-readable codes in a distributed manner. In addition, the functional programs, codes, and segments used to implement various embodiments of the present invention can be easily interpreted by programmers skilled in the art of applying the present invention.

Furthermore, it is understood that the devices and methods of various embodiments of the present invention can be implemented in the form of hardware, software, or a combination of hardware and software. Such software can be stored, for example, in a volatile or non-volatile storage device such as a ROM, or a memory such as a RAM, a memory chip, a device, or an integrated circuit, or a storage medium such as a compact disk (CD), a DVD (Digital Versatile Disc), a magnetic disk, or a magnetic tape that can be optically or magnetically recorded and read by a machine (e.g., a computer), regardless of whether the software is rewritable or erasable. It is understood that the methods of various embodiments of the present invention can be implemented by a computer including a control unit and a memory, or a vehicle including the memory or computer as described above. Such a memory is an example of a program including commands for implementing the embodiments of the present invention or a storage medium that can be read by a machine suitable for storing the program.

Therefore, the present invention includes a program as code for implementing the apparatus or method described in the invention claims of this specification, and a storage medium readable by a machine (such as a computer) storing such a program. Furthermore, such a program can be electronically transferred via any medium, such as a communication signal transmitted via a wired or wireless connection, and the present invention appropriately includes their equivalents.

Furthermore, it should be understood that the embodiments of the present invention described above are merely illustrative, and that those skilled in the art can implement various modifications and equivalent embodiments based thereon. Therefore, the true scope of technical protection for the present invention should be defined in accordance with the scope of the invention patent application below.

100: Electronic device 200: User device 210: Input/output unit 220: Communication unit 230: Storage unit 240: Processor 300: Server device 301: Communication device 303: Control unit 305: Memory 401: Action 403: Action 500: Processing of request information received from multiple users utilizing the service by one or more servers associated with the service 600: Request information received from multiple users utilizing a service is divided into request information corresponding to a higher-importance API group and request information corresponding to a lower-importance API group on the service. The request information received corresponding to each API group may be processed by one or more servers associated with the service. 700: Separating request information received from multiple users utilizing a service into request information corresponding to API groups with high resource usage, request information corresponding to API groups with medium to high resource usage, and request information corresponding to API groups with low resource usage on the service, and processing the request information corresponding to each API group using one or more servers associated with the service. 800: Separating request information received from multiple users utilizing a service into request information corresponding to each user, and processing the request information corresponding to each user using one or more servers associated with the service. 801: The number of request messages received for a specific user identified by identification information is limited to 20 per minute. 803: Configuring an external cache associated with one or more servers. 900: Preventing each server from processing all request messages received by a service. 1001: Configuring the first through fifth processing models. 1003: Configuring the facade layer structure that applies the first through fifth processing models. 1005: Bucket4J core algorithm. 1101: Disabling the fifth processing model. 1103-1: Configuring the number of request messages processed per minute exceeding 100,000. 1103-2: Limit the number of request messages processed per minute to 10,000 or less. 1201: Set the fifth processing model to off. 1203-1: Limit the number of request messages processed per minute to 10,000 or less. 1203-2: Limit the number of request messages processed per minute to 10,000 or less. 1205-1: If the number of request messages received from a user is 20 or more per minute, or if the number of requests used to process request messages received from a user is 20 or more per minute, 1205-2: Limit the number of request messages processed per minute for that user to 20 or less. 1301: Set the fifth processing model to off. 1303-1: Limit the number of request messages processed per minute to 10,000. 1303-2: Limit the number of request messages processed per minute to 10,000. 1305-1: Limit the number of request messages processed per minute for this user to 20 or fewer. 1305-2: Limit the number of request messages processed per minute for this user to 20 or fewer. 1307-1: Determined to be excessive. 1307-2: Limit the number of requests processed per unit time to 8,000 or fewer. For high-priority API groups, each server can process 2,000 requests per unit time. 1401: Set the fifth processing model to Off. 1403-1: Limit the number of requests processed per minute to 10,000 or fewer. 1403-2: Limit the number of requests processed per minute to 10,000 or fewer. 1405-1: Limit the number of requests processed per minute for this user to 20 or fewer. 1405-2: Limit the number of requests processed per minute for this user to 20 or fewer. 1407-1: Limit the number of requests processed per unit time to 8,000 or fewer. For API groups with higher importance, each server can process 2,000 requests per unit time. 1407-2: Limit the number of requests processed per unit time to 8,000 or fewer. For API groups with higher importance, each server can process 2,000 requests per unit time. 1409-1: The resource capacity allocated to API groups with high resource usage has been determined to have been exceeded. 1409-2: Based on the third processing model, resource capacity allocated to API groups with higher resource usage will be used to limit request processing for that API group to a maximum of 1,000 request messages. Therefore, API groups with higher resource usage can only process a maximum of 1,000 request messages.

Figure 1 is a diagram illustrating an information processing system capable of implementing the operating methods of an electronic device for information processing according to various embodiments. Figure 2 is a diagram illustrating the configuration of device nodes according to various embodiments. Figure 3 is a diagram illustrating the configuration of an electronic device for implementing the information processing methods proposed by the present invention. Figure 4 is a diagram illustrating the operating methods of the electronic device for information processing according to various embodiments. Figure 5 is a diagram illustrating an example of the first processing model included in the configuration request information processing model. Figure 6 is a diagram illustrating an example of the second processing model included in the configuration request information processing model. Figure 7 is a diagram illustrating an example of the third processing model included in the configuration request information processing model. Figure 8 is a diagram illustrating an example of the fourth processing model included in the configuration request information processing model. Figure 9 illustrates an example of the fifth processing model included in the configuration of the request information processing model. Figure 10 illustrates an example of a layer structure for applying the request information processing model to an algorithm for operating the electronic device 100. Figures 11 through 14 illustrate an example of processing request information based on the request information processing model including the first through fifth processing models.

401: Action 403: Action

Claims (13)

An information processing method for processing request information using an electronic device comprises the following steps: Setting a request information processing model related to processing request information obtained through a service; and Processing the request information obtained through the service based on at least one processing model included in the request information processing model; The request information processing model includes the following models: A first processing model, based on a first condition that the number of request information processed per unit time in one or more servers is equal to or greater than a first number, limits the number of request information to be processed per unit time in each of the one or more servers associated with the service to less than a first critical number; and The second processing model limits the number of request information to be processed per unit time on each of the servers to below a second threshold number, based on a second condition being satisfied: the number of request information processed per unit time for a specific API group in the plurality of first API groups categorized by importance for the plurality of APIs corresponding to the service is equal to or greater than a second threshold number. The information processing method of claim 1, wherein the request information processing model includes the following: A third processing model, corresponding to each API group included in a plurality of second API groups categorized by resource usage, limits the number of request messages to be processed to below a threshold number set for each API group. The information processing method of claim 1, wherein the request information processing model includes the following models: A fourth processing model, corresponding to users of the service, limits the number of request information to be processed per unit time to below a third critical number. The information processing method of claim 3, wherein the number of request information obtained from the user per unit time is confirmed by an external cache corresponding to the one or more servers. The information processing method of claim 3, wherein the number of request messages received from the user per unit time is determined based on the user's identification information and information about the API currently being used by the user. The information processing method of claim 5 further comprises the following steps: Identifying the API information using an API identifier. The information processing method of claim 1, wherein the request information processing model includes the following models: A fifth processing model, comprising: processing all request information obtained through the service. The information processing method of claim 1, wherein the processing of the following request information is refused: the request information exceeds a critical number limited by each processing model included in the above-mentioned request information processing model. The information processing method of claim 1 further comprises the following steps: Setting each processing model status identification information corresponding to each processing model included in the request information processing model; and Based on the each processing model status identification information, determining the number of request information that was rejected for processing according to each processing model. The information processing method of claim 1, wherein the at least one processing model is selected based on a first input from a manager corresponding to the electronic device. The information processing method of claim 1, wherein the first critical number and the second critical number are set based on a second input from an administrator corresponding to the electronic device. The information processing method of claim 1 further comprises the following steps: Setting a layer structure corresponding to the request information processing model; and Based on the layer structure, applying the request information processing model to an algorithm for operating the electronic device. An electronic device that processes request information comprises: a processor; and one or more memories storing one or more instructions; when executed, the one or more instructions control the processor to perform the following steps: setting a request information processing model related to processing request information obtained through a service; and processing the request information obtained through the service based on at least one processing model included in the request information processing model; the request information processing model includes the following models: The first processing model limits the number of request information processed per unit time in each of the one or more servers associated with the service to below a first threshold number based on a first condition being satisfied that the number of request information processed per unit time in one or more servers is equal to or greater than a first number. The second processing model limits the number of request information processed per unit time in each of the one or more servers associated with the service to below a second threshold number based on a second condition being satisfied that the number of request information processed per unit time in a specific API group is equal to or greater than a second number.