Service provision system, information processing device and service provision program

Abstract

A service providing system, an information processing device, and a service providing program are provided that can improve the fairness of services. [Solution] The service providing system determines the priority of an API request (S122) so that the higher the priority of the API request, the less API usage there is by either the client that is the source of the API request, the tenant that is the destination of the API request, or the combination of client and tenant, and processes API requests with higher priority.

Description

[Technical Field]

[0001] The present invention relates to a service providing system, an information processing device, and a service providing program that provide services that are used by user terminals used by users. [Background technology]

[0002] A conventional service providing system is known that receives requests for operations on information that it manages (see, for example, Patent Document 1). The conventional service providing system manages the reception time of the latest request for each request group that has the same information as the target of the request, and performs operations on the information according to the request with priority to the request group whose reception time of the latest request is older. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2018-025864 Summary of the Invention [Problem to be solved by the invention]

[0004] However, in a conventional service providing system, when a large number of requests from a particular client occupy resources for processing requests, delays in processing requests from other clients occur, which poses a problem in terms of service fairness.Furthermore, in a conventional service providing system, when a large number of requests from a particular tenant occupy resources for processing requests, delays in processing requests from other tenants occur, which poses a problem in terms of service fairness.

[0005] Therefore, an object of the present invention is to provide a service providing system, an information processing device, and a service providing program that can improve the fairness of services. [Means for solving the problem]

[0006] The service providing system of the present invention determines a priority such that the higher the priority of an API request, the less API usage by a specific API user; the higher the priority of the API request, the more preferentially the API request is processed; and the user is either a client that is the source of the API request, a tenant that is the destination of the API request, or a combination of the client and the tenant.

[0007] With this configuration, the service providing system of the present invention determines the priority of API requests such that the higher the priority of the API request, the less API usage by the client that is the request source of the API request, thereby reducing the possibility that processing resources for the API request will be monopolized by API requests from a specific client, thereby improving service fairness.Furthermore, when the service providing system of the present invention determines the priority of API requests such that the higher the priority of the API request, the less API usage by the tenant that is the request destination of the API request, thereby reducing the possibility that processing resources for the API request will be monopolized by API requests for a specific tenant, thereby improving service fairness.

[0008] In the service providing system of the present invention, the usage amount when determining the priority of a specific request as a specific API request may include at least one of the number of times the API request whose user is the same as the specific request has been received, the amount of data communication in processing the API request whose user is the same as the specific request, and the processing time of the API request whose user is the same as the specific request.

[0009] With this configuration, the service providing system of the present invention determines the priority of a specific request so that the higher the priority of the API request, the lower is at least one of the number of times an API request is received whose API user is the same as the specific request, the amount of data communication required to process the API request whose API user is the same as the specific request, and the processing time for the API request whose API user is the same as the specific request, thereby improving the appropriateness of the priority of API requests.

[0010] The service providing system of the present invention may determine the priority based on the usage amount for each time period.

[0011] With this configuration, the service providing system of the present invention determines the priority of API requests based on the amount of API usage by a specific API user during each time period, thereby reducing the possibility that API request processing resources will be monopolized by a user that tends to use a lot of API request processing resources during a specific time period, thereby improving the fairness of services.

[0012] The service providing system of the present invention may process one low priority request if, after previously processing a low priority request as the API request with the lowest priority, a specific number or more API requests with a higher priority than the low priority request have been processed.

[0013] With this configuration, the service providing system of the present invention processes one low-priority request if a specific number or more API requests with higher priorities than the low-priority request have been processed since the last time the low-priority request, which is the API request with the lowest priority, was processed. This reduces the possibility of excessive delays in processing low-priority requests, and as a result, improves the fairness of services.

[0014] The service providing system of the present invention may process one of the low priority requests if a specific time or more has passed since the last processing of the low priority request, which is the API request with the lowest priority.

[0015] With this configuration, the service providing system of the present invention processes one low priority request if a specific amount of time has passed since the last time a low priority request, which is the API request with the lowest priority, was processed. This reduces the possibility of excessive delays in processing low priority requests, thereby improving the fairness of services.

[0016] The service providing system of the present invention may process a low-priority request when a specific time or more has elapsed since receiving the low-priority request as the API request with the lowest priority.

[0017] With this configuration, the service providing system of the present invention processes a low-priority request as the API request with the lowest priority if a specific amount of time has passed since receiving the low-priority request, thereby reducing the possibility of excessive delays in processing the low-priority request and, as a result, improving the fairness of services.

[0018] The service provision program of the present invention is a service provision program executed by a computer, which causes the computer to determine a priority such that the higher the priority of an API request, the less API usage by a specific API user; and causes the computer to process the API request with higher priority, and the user is either a client that is the source of the API request, a tenant that is the destination of the API request, or a combination of the client and the tenant.

[0019] With this configuration, when a computer executing the service provision program of the present invention determines the priority of API requests such that the higher the priority of the API request, the less API usage by the client that is the source of the API request, it is possible to reduce the possibility that processing resources for API requests will be monopolized by API requests from a specific client, thereby improving fairness of services.Furthermore, when a computer executing the service provision program of the present invention determines the priority of API requests such that the higher the priority of the API request, the less API usage by the tenant that is the destination of the API request, it is possible to reduce the possibility that processing resources for API requests will be monopolized by API requests for a specific tenant, thereby improving fairness of services. [Effects of the Invention]

[0020] The service providing system, the information processing device, and the service providing program of the present invention can improve the fairness of services. [Brief explanation of the drawings]

[0021] [Figure 1] 1 is a block diagram of a system according to an embodiment of the present invention. [Figure 2] FIG. 2 is a block diagram of an example of the service providing system shown in FIG. 1 when configured by one computer. [Figure 3] 3 is a diagram illustrating an example of client management information illustrated in FIG. 2. FIG. [Figure 4] 3 is a diagram illustrating an example of tenant management information illustrated in FIG. 2. FIG. [Figure 5] 3 is a diagram showing an example of unfinished request management information shown in FIG. 2. FIG. [Figure 6] FIG. 3 is a diagram illustrating an example of request history information illustrated in FIG. [Figure 7] FIG. 2 is a block diagram of an example of a user terminal shown in FIG. [Figure 8]3 is a flowchart of the operation of the service providing system shown in FIG. 2 when an API request is received from a client. [Figure 9] 9 is a flowchart of the priority determination process shown in FIG. 8. [Figure 10] 10 is a flowchart of the operation of the service providing system shown in FIG. 2 when a priority is written in the outstanding request management information in a case where a first priority processing rule is indicated in the priority processing rule information. [Figure 11] 10 is a flowchart of the operation of the service providing system shown in FIG. 2 when writing the processing order of low-priority requests into the outstanding request management information when the first priority processing rule is indicated in the priority processing rule information. [Figure 12] 10 is a flowchart of the operation of the service providing system shown in FIG. 2 when it is determined to start processing an API request when a first priority processing rule is indicated in the priority processing rule information. [Figure 13] 10 is a flowchart of the operation of the service providing system shown in FIG. 2 when a priority is written in the outstanding request management information in a case where a second priority processing rule is indicated in the priority processing rule information. [Figure 14] A flowchart of the operation of the service providing system shown in Figure 2 when the API interface unit receives the results of processing an API request from the backend service server when the third priority processing rule is indicated in the priority processing rule information. [Figure 15] 10 is a flowchart of the operation of the service providing system shown in FIG. 2 when it is determined to start processing an API request when the third priority processing rule is indicated in the priority processing rule information. DETAILED DESCRIPTION OF THE INVENTION

[0022] Hereinafter, embodiments of the present invention will be described with reference to the drawings.

[0023] First, the configuration of a system according to an embodiment of the present invention will be described.

[0024] FIG. 1 is a block diagram of a system 10 according to the present embodiment.

[0025] As shown in Fig. 1, the system 10 includes a service providing system 20 that provides services to be used by a user terminal used by a user. The service providing system 20 may be configured with a single computer such as a PC (Personal Computer), or may be configured with multiple computers. The service providing system 20 may be configured on a cloud.

[0026] The system 10 includes a user terminal 30 used by a user. The system 10 may also include at least one other user terminal having a similar configuration to the user terminal 30. The user terminal may be configured, for example, by a computer such as a PC.

[0027] FIG. 2 is a block diagram of an example of a service providing system 20 configured by one computer.

[0028] As shown in Figure 2, the service providing system 20 includes an operation unit 21, which is an operation device such as a keyboard or mouse through which various operations are input; a display unit 22, which is a display device such as an LCD (Liquid Crystal Display) that displays various information; a communication unit 23, which is a communication device that communicates with external devices via a network such as a LAN (Local Area Network) or the Internet, or directly via a wired or wireless connection without using a network; a memory unit 24, which is a non-volatile memory device such as a semiconductor memory or an HDD (Hard Disk Drive) that stores various information; and a control unit 25 that controls the entire service providing system 20.

[0029] The storage unit 24 can store a service providing program 24a for providing services. The service providing program 24a may be installed in the service providing system 20 during the manufacturing stage of the service providing system 20, or may be additionally installed in the service providing system 20 from an external storage medium such as a USB (Universal Serial Bus) memory, or may be additionally installed in the service providing system 20 from a network.

[0030] The storage unit 24 can store client management information 24b that manages clients as applications that use the service providing system 20. The client management information 24b may be configured as a database.

[0031] FIG. 3 is a diagram showing an example of the client management information 24b.

[0032] As shown in Fig. 3, the client management information 24b includes an API (Application Programming Interface) key as client identification information for each client. The client management information 24b shown in Fig. 3 is illustrated with some information omitted.

[0033] The API key may be issued, for example, by the operator of the service providing system 20. The same API key may be issued to clients manufactured by the same manufacturer regardless of the type of client, or different API keys may be issued for different types of clients manufactured by the same manufacturer.

[0034] 2, the storage unit 24 can store tenant management information 24c for managing tenants of the service providing system 20. The tenant management information 24c may be configured as a database.

[0035] FIG. 4 is a diagram illustrating an example of the tenant management information 24c.

[0036] As shown in Fig. 4, the tenant management information 24c includes a tenant ID as identification information for each tenant. The tenant management information 24c shown in Fig. 4 is illustrated with some information omitted.

[0037] 2, the storage unit 24 can store unfinished request management information 24d for managing API requests whose processing has not yet been completed. The unfinished request management information 24d may be configured as a database.

[0038] FIG. 5 is a diagram showing an example of the pending request management information 24d.

[0039] 5, the unfinished request management information 24d includes, for each API request, the order in which the API requests are processed by the service providing system 20 (hereinafter referred to as the "processing order"), the date and time the API request was received by the service providing system 20, a request ID as identification information for the API request, the processing status of the API request (hereinafter referred to as the "processing status"), and the priority assigned to the API request. Some information is omitted from the unfinished request management information 24d shown in FIG.

[0040] The processing order of API requests is "1", with "1" being the earliest, and the higher the number, the later the order.

[0041] The processing status of an API request can be either "waiting for processing" indicating that the request is waiting for processing by the service providing system 20, or "in progress" indicating that the request is currently being processed by the service providing system 20.

[0042] There are two types of priorities assigned to API requests. Of the two types of priorities, the higher priority is called high priority, and the lower priority is called low priority. Hereinafter, high-priority API requests will be referred to as high-priority requests, and low-priority API requests will be referred to as low-priority requests.

[0043] 2, the storage unit 24 can store request history information 24e that indicates the history of API requests. The request history information 24e may be configured as a database.

[0044] FIG. 6 is a diagram showing an example of the request history information 24e.

[0045] 6, the request history information 24e includes, for each API request, the date and time the API request was received by the service providing system 20, the request ID of the API request, the API key assigned to the API request, the tenant ID assigned to the API request, the priority assigned to the API request, the amount of data communication in processing the API request by the backend service server 25a, the start time of processing the API request by the backend service server 25a, and the end time of processing the API request by the backend service server 25a. Some information is omitted from the request history information 24e shown in FIG.

[0046] 2, the storage unit 24 stores priority determination rule information 24f indicating priority determination rules as rules for determining the priorities of API requests. Various priority determination rules can be adopted as the priority determination rules indicated in the priority determination rule information 24f.

[0047] The storage unit 24 stores priority processing rule information 24g that indicates priority processing rules that indicate how to execute priority processing as processing of API requests according to the priority of the API requests.

[0048] Various priority processing rules can be adopted as the priority processing rule indicated in the priority processing rule information 24g. For example, as the priority processing rule indicated in the priority processing rule information 24g, a priority processing rule (hereinafter referred to as a "first priority processing rule") can be adopted, which is as follows: when a new low priority request (hereinafter referred to as a "new low priority request") is received when there are no low priority requests waiting to be processed, if a specific number or more of high priority requests have been processed since the previous low priority request was processed, the new low priority request is processed, and if a specific number or more of high priority requests have not been processed since the previous low priority request was processed, the new low priority request is processed after a specific time has elapsed since the new low priority request was received. The priority processing rule information 24g may include a priority processing rule (hereinafter referred to as a "second priority processing rule") that processes a new low-priority request when a first time or more has elapsed since the previous low-priority request was processed, when a new low-priority request is received without any low-priority requests waiting to be processed, and processes the new low-priority request when a second time or more has elapsed since the new low-priority request was received, when the first time or more has not elapsed since the previous low-priority request was processed.The priority processing rule information 24g may include a priority processing rule (hereinafter referred to as a "third priority processing rule") that processes one low-priority request every time a specific number of high-priority requests are processed, when there are no low-priority requests waiting to be processed for a specific time or more, and processes low-priority requests that have been waiting to be processed for a specific time or more before high-priority requests, when there are low-priority requests waiting to be processed for a specific time or more.

[0049] The control unit 25 includes, for example, a CPU (Central Processing Unit), a ROM (Read Only Memory) that stores programs and various data, and a RAM (Random Access Memory) that serves as a memory used as a work area for the CPU of the control unit 25. The CPU of the control unit 25 executes programs stored in the storage unit 24 or the ROM of the control unit 25.

[0050] The control unit 25 executes the service providing program 24a to implement a backend service server 25a that executes processing in response to API requests received from clients, and an API interface unit 25b, which acts as an intermediate server between the clients and the backend service server 25a. The API interface unit 25b includes a communication control unit 25c that controls API communication with clients. The communication control unit 25c includes a data transmission / reception unit 25d that receives API requests from clients and transmits API responses to the clients, a request execution unit 25e that communicates with the backend service server 25a to process the API requests received from the clients, and a priority processing unit 25f that executes priority processing between the data transmission / reception unit 25d and the request execution unit 25e as processing of API requests according to their priorities. The API interface unit 25b also implements a priority management unit 25g that manages the priority of API requests, a usage analysis unit 25h that analyzes the usage status of the service providing system 20 by API requests, and a rule setting unit 25i that sets priority determination rules and priority processing rules.

[0051] The rule setting unit 25i can change the priority determination rules indicated in the priority determination rule information 24f and the priority processing rules indicated in the priority processing rule information 24g in response to instructions via the operation unit 21 or the communication unit 23.

[0052] FIG. 7 is a block diagram of an example of the user terminal 30. As shown in FIG.

[0053] As shown in Figure 7, the user terminal 30 includes an operation unit 31, which is an operation device such as a keyboard or mouse through which various operations are input; a display unit 32, which is a display device such as an LCD that displays various information; a communication unit 33, which is a communication device that communicates with external devices via a network such as a LAN or the Internet, or directly via a wired or wireless connection without using a network; a memory unit 34, which is a non-volatile memory device such as a semiconductor memory or HDD that stores various information; and a control unit 35 that controls the entire user terminal 30.

[0054] The storage unit 34 can store a client program 34a for a client. The client program 34a may be installed in the user terminal 30 during the manufacturing stage of the user terminal 30, or may be additionally installed in the user terminal 30 from an external storage medium such as a USB memory, or may be additionally installed in the user terminal 30 from a network.

[0055] The control unit 35 includes, for example, a CPU, a ROM that stores programs and various data, and a RAM as memory used as a work area for the CPU of the control unit 35. The CPU of the control unit 35 executes programs stored in the storage unit 34 or the ROM of the control unit 35.

[0056] The control unit 35 executes the client program 34a to implement a client 35a.

[0057] The user of the user terminal 30 may be the manufacturer of the client 35a, or may be someone other than the manufacturer of the client 35a.

[0058] Next, the operation of the service providing system 20 when an API request is received from the client 35a will be described.

[0059] In the following, the user terminal 30 will be described as a representative of the user terminals. However, user terminals other than the user terminal 30 can also perform the same operations as the user terminal 30.

[0060] FIG. 8 is a flowchart showing the operation of the service providing system 20 when an API request is received from the client 35a.

[0061] When using an API provided by the service providing system 20, the client 35a transmits an API request to the service providing system 20, to which is attached the API key of the client 35a that is the request source of the API request and the tenant ID of the tenant that is the request destination of the API request. Upon receiving the API request, the service providing system 20 executes the operation shown in Fig. 8. Hereinafter, the API request that causes the service providing system 20 to start the operation shown in Fig. 8 will be referred to as a "target request" in the description of the operations shown in Figs. 8 and 9.

[0062] As shown in Figure 8, the data transmitter / receiver 25d of the service providing system 20 writes the date and time the data transmitter / receiver 25d received the target request, the request ID assigned to the target request by the data transmitter / receiver 25d, and the API key and tenant ID of the target request into the request history information 24e (S101).

[0063] When the process of S101 ends, the data transmitter / receiver 25d determines whether the API key assigned to the target request exists in the client management information 24b (S102).

[0064] When the data transmitter / receiver 25d determines in S102 that the API key assigned to the target request exists in the client management information 24b, it determines whether the tenant ID assigned to the target request exists in the tenant management information 24c (S103).

[0065] If the data transmitter / receiver 25d determines in S102 that the API key assigned to the target request does not exist in the client management information 24b, or determines in S103 that the tenant ID assigned to the target request does not exist in the tenant management information 24c, it sends an API response including an error message indicating that the target request is not a legitimate API request to the client 35a (S104), and terminates the operation shown in Figure 8.

[0066] When the priority processing unit 25f determines in S103 that the tenant ID assigned to the target request exists in the tenant management information 24c, it writes the date and time of reception of the target request by the data transmission / reception unit 25d, the request ID of the target request, and the processing status of the target request as "waiting for processing" into the unfinished request management information 24d (S105).

[0067] When the process of S105 is completed, the priority management unit 25g executes a priority determination process to determine the priority of the target request (S106).

[0068] FIG. 9 is a flowchart of the priority determination process shown in FIG.

[0069] When the processing of S105 (see FIG. 8) is completed, the priority management unit 25g requests the priority management unit 25g to determine the priority of the target request. When the priority management unit 25g is requested to determine the priority of the target request, the priority management unit 25g executes the operation shown in FIG.

[0070] As shown in FIG. 9, the priority management unit 25g collects information used to determine the priority of the target request (S121).

[0071] The information collected in S121 may include, for example, the API key of the target request.

[0072] The information collected in S121 may include, for example, the tenant ID of the target request.

[0073] The information collected in S121 may include the amount of API usage by a specific API user (hereinafter referred to as "API usage amount"). Here, an API user is either a client that is the source of an API request, a tenant that is the destination of an API request, or a combination of a client and a tenant.

[0074] The API usage amount collected in S121 may include, for example, the number of times a specific API request was received during a specific period in the past, starting from the current date and time (hereinafter referred to as the "number of requests"). Here, the specific API request may be any of an API request assigned with the same combination of API key and tenant ID as the combination of API key and tenant ID assigned to the target request, an API request assigned with the same API key as the API key assigned to the target request, and an API request assigned with the same tenant ID as the tenant ID assigned to the target request. The priority management unit 25g can acquire the number of requests from the usage status analysis unit 25h. The usage status analysis unit 25h can analyze the number of requests based on the request history information 24e.

[0075] The API usage collected in S121 may include, for example, the total amount of data communication volume (hereinafter referred to as "total data communication volume") in processing specific API requests during a specific period in the past, starting from the current date and time. Here, the specific API request may be any of an API request assigned with the same combination of API key and tenant ID as the combination of API key and tenant ID assigned to the target request, an API request assigned with the same API key as the API key assigned to the target request, and an API request assigned with the same tenant ID as the tenant ID assigned to the target request. The priority management unit 25g can acquire the total data communication volume from the usage status analysis unit 25h. The usage status analysis unit 25h can analyze the total data communication volume based on the request history information 24e.

[0076] The API usage collected in S121 may include, for example, the communication volume obtained by dividing the total data communication volume of a specific API request by the number of requests of the specific API request (hereinafter referred to as the "average data communication volume"). Here, the specific API request may be any of the following: an API request assigned with the same combination of API key and tenant ID as the combination of API key and tenant ID assigned to the target request; an API request assigned with the same API key as the API key assigned to the target request; and an API request assigned with the same tenant ID as the tenant ID assigned to the target request. The priority management unit 25g can acquire the average data communication volume from the usage status analysis unit 25h. The usage status analysis unit 25h can analyze the average data communication volume based on the request history information 24e.

[0077] The API usage collected in S121 may include, for example, the total amount of time (hereinafter referred to as the “total processing time”) spent processing specific API requests by the backend service server 25a during a specific past period starting from the current date and time. Here, the specific API request may be any of the following: an API request assigned with the same combination of API key and tenant ID as the combination of API key and tenant ID assigned to the target request; an API request assigned with the same API key as the API key assigned to the target request; and an API request assigned with the same tenant ID as the tenant ID assigned to the target request. The priority management unit 25g can acquire the total processing time from the usage status analysis unit 25h. The usage status analysis unit 25h can analyze the total processing time based on the request history information 24e. The usage status analysis unit 25h can determine the processing time of the API request by the backend service server 25a as the time from the start time of processing the API request by the backend service server 25a to the end time of processing the API request by the backend service server 25a.

[0078] The API usage collected in S121 may include, for example, a processing time (hereinafter referred to as "average processing time") obtained by dividing the total processing time of a specific API request by the number of requests for the specific API request. Here, the specific API request may be any of an API request assigned with the same combination of API key and tenant ID as the combination of API key and tenant ID assigned to the target request, an API request assigned with the same API key as the API key assigned to the target request, and an API request assigned with the same tenant ID as the tenant ID assigned to the target request. The priority management unit 25g can acquire the average processing time from the usage status analysis unit 25h. The usage status analysis unit 25h can analyze the average processing time based on the request history information 24e.

[0079] In S121, the priority management unit 25g may collect at least one of the number of requests, the total data communication volume, the average data communication volume, the total processing time, and the average processing time for each time period. For example, various time periods can be used, such as a time period from 10 PM to 5 AM, or a time period from 5 AM to 10 PM.

[0080] When the process of S121 is completed, the priority management unit 25g determines the priority of the target request based on the information collected in S121 and the priority determination rules indicated in the priority determination rule information 24f (S122).

[0081] As a priority determination rule, for example, a numerical value (hereinafter referred to as "evaluation value") for evaluating priority may be calculated based on the information collected in S121, and if the evaluation value is equal to or greater than a specific numerical value, the priority of the target request may be determined to be high priority, and if the evaluation value is less than the specific numerical value, the priority of the target request may be determined to be low priority.

[0082] The priority determination rule may be one that adds a numerical value corresponding to the API key of the target request to the evaluation value, or one that determines the priority of the target request as high if the API key of the target request is a specific API key.

[0083] The priority determination rule may be one that adds a numerical value corresponding to the tenant ID of the target request to the evaluation value, or one that determines the priority of the target request as high if the tenant ID of the target request is a specific tenant ID.

[0084] The priority determination rule may be one that tends to determine the priority of a target request as high when the number of requests is less than a specific number, compared to when the number of requests is equal to or greater than a specific number. The priority determination rule may be one that adds a numerical value corresponding to the number of requests to the evaluation value. For example, the priority determination rule may be one that adds a larger numerical value to the evaluation value when the number of requests is less than a specific number, compared to when the number of requests is equal to or greater than a specific number. The priority determination rule may be one that determines the priority of a target request as high when the number of requests is less than a specific number, and determines the priority of a target request as low when the number of requests is equal to or greater than a specific number.

[0085] The priority determination rule may be one that tends to determine the priority of a target request as high when the total data communication volume is less than a specific volume, compared to when the total data communication volume is equal to or greater than the specific volume. The priority determination rule may be one that adds a numerical value corresponding to the total data communication volume to the evaluation value. For example, the priority determination rule may be one that adds a larger numerical value to the evaluation value when the total data communication volume is less than the specific volume, compared to when the total data communication volume is equal to or greater than the specific volume. The priority determination rule may be one that determines the priority of a target request as high when the total data communication volume is less than the specific volume, and determines the priority of a target request as low when the total data communication volume is equal to or greater than the specific volume.

[0086] The priority determination rule may be one that tends to determine the priority of a target request as high when the average data communication volume is less than a specific volume, compared to when the average data communication volume is equal to or greater than a specific volume. The priority determination rule may be one that adds a numerical value corresponding to the average data communication volume to the evaluation value. For example, the priority determination rule may be one that adds a larger numerical value to the evaluation value when the average data communication volume is less than a specific volume, compared to when the average data communication volume is equal to or greater than a specific volume. The priority determination rule may be one that determines the priority of a target request as high when the average data communication volume is less than a specific volume, and determines the priority of a target request as low when the average data communication volume is equal to or greater than a specific volume.

[0087] The priority determination rule may be one that tends to determine the priority of a target request as high when the total processing time is less than a specific time, compared to when the total processing time is equal to or greater than a specific time. The priority determination rule may be one that adds a numerical value corresponding to the total processing time to the evaluation value. For example, the priority determination rule may be one that adds a larger numerical value to the evaluation value when the total processing time is less than a specific time, compared to when the total processing time is equal to or greater than a specific time. The priority determination rule may be one that determines the priority of a target request as high when the total processing time is less than a specific time, and determines the priority of a target request as low when the total processing time is equal to or greater than a specific time.

[0088] The priority determination rule may be one that tends to determine the priority of a target request as high when the average processing time is less than a specific time, compared to when the average processing time is equal to or greater than a specific time. The priority determination rule may be one that adds a numerical value corresponding to the average processing time to the evaluation value. For example, the priority determination rule may be one that adds a larger numerical value to the evaluation value when the average processing time is less than a specific time, compared to when the average processing time is equal to or greater than a specific time. The priority determination rule may be one that determines the priority of a target request as high when the average processing time is less than a specific time, and determines the priority of a target request as low when the average processing time is equal to or greater than a specific time.

[0089] The priority determination rule may be one that tends to determine the priority of a target request as high when the number of requests in a specific time period is less than a specific number, compared to when the number of requests in a specific time period is equal to or greater than a specific number. The priority determination rule may be one that adds a numerical value corresponding to the number of requests in a specific time period to the evaluation value. For example, the priority determination rule may be one that adds a larger numerical value to the evaluation value when the number of requests in a specific time period is less than a specific number, compared to when the number of requests in a specific time period is equal to or greater than a specific number. The priority determination rule may be one that determines the priority of a target request as high when the number of requests in a specific time period is less than a specific number, and determines the priority of a target request as low when the number of requests in a specific time period is equal to or greater than a specific number.

[0090] The priority determination rule may be one that tends to determine the priority of a target request as high when the total data communication volume during a specific time period is less than a specific communication volume, compared to when the total data communication volume during the specific time period is equal to or greater than the specific communication volume. The priority determination rule may be one that adds a numerical value corresponding to the total data communication volume during the specific time period to the evaluation value. For example, the priority determination rule may be one that adds a larger numerical value to the evaluation value when the total data communication volume during the specific time period is less than a specific communication volume, compared to when the total data communication volume during the specific time period is equal to or greater than the specific communication volume. The priority determination rule may be one that determines the priority of a target request as high when the total data communication volume during the specific time period is less than a specific communication volume, and one that determines the priority of a target request as low when the total data communication volume during the specific time period is equal to or greater than the specific communication volume.

[0091] The priority determination rule may be one that tends to determine the priority of a target request as high when the average data communication volume in a specific time period is less than a specific communication volume, compared to when the average data communication volume in the specific time period is equal to or greater than a specific communication volume. The priority determination rule may be one that adds a numerical value corresponding to the average data communication volume in a specific time period to the evaluation value. For example, the priority determination rule may be one that adds a larger numerical value to the evaluation value when the average data communication volume in a specific time period is less than a specific communication volume, compared to when the average data communication volume in the specific time period is equal to or greater than a specific communication volume. The priority determination rule may be one that determines the priority of a target request as high when the average data communication volume in the specific time period is less than a specific communication volume, and one that determines the priority of a target request as low when the average data communication volume in the specific time period is equal to or greater than a specific communication volume.

[0092] The priority determination rule may be one that tends to determine the priority of a target request as high when the total processing time in a specific time period is less than a specific time, compared to when the total processing time in a specific time period is equal to or greater than a specific time. The priority determination rule may be one that adds a numerical value corresponding to the total processing time in a specific time period to the evaluation value. For example, the priority determination rule may be one that adds a larger numerical value to the evaluation value when the total processing time in a specific time period is less than a specific time, compared to when the total processing time in a specific time period is equal to or greater than a specific time. The priority determination rule may be one that determines the priority of a target request as high when the total processing time in a specific time period is less than a specific time, and one that determines the priority of a target request as low when the total processing time in a specific time period is equal to or greater than a specific time.

[0093] The priority determination rule may be one that tends to determine the priority of a target request as high when the average processing time in a specific time period is less than a specific time, compared to when the average processing time in the specific time period is equal to or greater than a specific time. The priority determination rule may be one that adds a numerical value corresponding to the average processing time in a specific time period to the evaluation value. For example, the priority determination rule may be one that adds a larger numerical value to the evaluation value when the average processing time in a specific time period is less than a specific time, compared to when the average processing time in the specific time period is equal to or greater than a specific time. The priority determination rule may be one that determines the priority of a target request as high when the average processing time in the specific time period is less than a specific time, and determines the priority of a target request as low when the average processing time in the specific time period is equal to or greater than a specific time.

[0094] When the process of S122 is completed, the priority management unit 25g writes the priority of the target request determined in S122 into the unfinished request management information 24d and the request history information 24e (S123), and ends the priority determination process shown in FIG.

[0095] As shown in FIG. 8, when the priority determination process in S106 ends, the priority processing unit 25f determines whether or not to start processing of the target request until it determines to start processing of the target request (S107).

[0096] FIG. 10 is a flowchart of the operation of the service providing system 20 when a priority is written in the outstanding request management information 24d in a case where the first priority processing rule is indicated in the priority processing rule information 24g.

[0097] When the first priority processing rule is indicated in the priority processing rule information 24g, the priority processing unit 25f performs the operation shown in FIG. 10 when the priority is written to the unfinished request management information 24d in S123 (see FIG. 9).

[0098] As shown in FIG. 10, the priority processing unit 25f determines whether the API request whose priority is written in the outstanding request management information 24d (hereinafter referred to as the “target request” in the description of the operation shown in FIG. 10) is a high-priority request (S141).

[0099] When the priority processing unit 25f determines in S141 that the target request is a high-priority request, it adds the target request to the end of the current processing order in the unfinished request management information 24d (S142). That is, if a processing order is not written in the unfinished request management information 24d, the priority processing unit 25f writes number 1 as the processing order of the target request in the unfinished request management information 24d. Furthermore, if a processing order is written in the unfinished request management information 24d, the priority processing unit 25f writes the processing order one after the last processing order of the processing orders currently written in the unfinished request management information 24d as the processing order of the target request in the unfinished request management information 24d.

[0100] If the priority processing unit 25f determines in S141 that the target request is not a high-priority request, it determines whether or not there are any low-priority requests waiting to be processed other than the target request, based on the pending request management information 24d (S143).

[0101] If the priority processing unit 25f determines in S143 that there are no low-priority requests waiting to be processed other than the target request, it determines whether the number of high-priority requests that have been processed since the previous processing of the low-priority request (hereinafter referred to as the "number of processed high-priority requests") is equal to or greater than a specific number (S144). Here, the priority processing unit 25f can calculate the number of processed high-priority requests based on the request history information 24e.

[0102] If the priority processing unit 25f determines in S144 that the number of processed high-priority requests is equal to or greater than a specific number, it adds the target request to the beginning of the current processing order in the unfinished request management information 24d (S145). That is, if the processing order of the high-priority request is not written in the unfinished request management information 24d, the priority processing unit 25f writes the target request as number 1 in the unfinished request management information 24d as the processing order. Furthermore, if the processing order of the high-priority request is written in the unfinished request management information 24d, the priority processing unit 25f shifts the processing order of the high-priority request written in the unfinished request management information 24d back by one, and then writes the target request as number 1 in the unfinished request management information 24d as the processing order.

[0103] The priority processing unit 25f terminates the operation shown in FIG. 10 when the processing of S142 is completed, when it determines in S143 that there are low priority requests waiting to be processed other than the target request, when it determines in S144 that the number of high priority requests being processed is less than a specific number, or when it executes the processing of S145.

[0104] FIG. 11 is a flowchart of the operation of the service providing system 20 when writing the processing order of low-priority requests into the outstanding request management information 24d when the first priority processing rule is specified in the priority processing rule information 24g.

[0105] The priority processing unit 25f executes the operation shown in FIG. 11 when the first priority processing rule is indicated in the priority processing rule information 24g.

[0106] As shown in FIG. 11, the priority processing unit 25f determines whether or not there are any low-priority requests awaiting processing, for which a specific time has elapsed since the date and time of reception and for which no processing order has yet been assigned, in the unfinished request management information 24d, until it determines that there are any low-priority requests awaiting processing, for which a specific time has elapsed since the date and time of reception and for which no processing order has yet been assigned, in the unfinished request management information 24d (S161).

[0107] When the priority processing unit 25f determines in S161 that there are low-priority requests awaiting processing for which a specific time or more has passed since their reception date and time and for which no processing order has yet been assigned in the unfinished request management information 24d, the priority processing unit 25f adds the low-priority request with the earliest reception date and time (hereinafter referred to as the "target request" in the description of FIG. 11) among the low-priority requests awaiting processing for which a specific time or more has passed since their reception date and time and for which no processing order has yet been assigned in the unfinished request management information 24d, to the end of the current processing order of low-priority requests (S162). In other words, when the processing order of low-priority requests and the processing order of high-priority requests are not written in the unfinished request management information 24d, the priority processing unit 25f writes "1" as the processing order of the target request in the unfinished request management information 24d. Furthermore, when the processing order of low-priority requests is not written in the unfinished request management information 24d but the processing order of high-priority requests is written in the unfinished request management information 24d, the priority processing unit 25f shifts the processing order of the high-priority requests written in the unfinished request management information 24d backward by one, and then writes number 1 as the processing order of the target request in the unfinished request management information 24d. Furthermore, when the processing order of low-priority requests is written in the unfinished request management information 24d but the processing order of high-priority requests is not written in the unfinished request management information 24d, the priority processing unit 25f writes the processing order one after the last processing order of the processing orders currently written in the unfinished request management information 24d into the unfinished request management information 24d as the processing order of the target request. Furthermore, when the processing order of low-priority requests is written in the unfinished request management information 24d and the processing order of high-priority requests is also written in the unfinished request management information 24d, the priority processing unit 25f shifts the processing orders of the high-priority requests written in the unfinished request management information 24d backward by one, and then writes the processing order one after the last processing order of the low-priority requests currently written in the unfinished request management information 24d as the processing order of the target request in the unfinished request management information 24d.

[0108] When the process of S162 ends, the priority processing unit 25f executes the process of S161.

[0109] FIG. 12 is a flowchart of the operation of the service providing system 20 when it is determined to start processing an API request when the first priority processing rule is indicated in the priority processing rule information 24g.

[0110] The priority processing unit 25f executes the operation shown in FIG. 12 when the first priority processing rule is indicated in the priority processing rule information 24g.

[0111] As shown in FIG. 12, the priority processing unit 25f determines whether there are any API requests whose processing status is "in processing" based on the unfinished request management information 24d until it determines that there are no API requests whose processing status is "in processing" (S181).

[0112] When the priority processing unit 25f determines in S181 that there is no API request whose processing status is "in processing", it determines whether there is an API request whose processing order is first in the unfinished request management information 24d (S182) until it determines that there is an API request whose processing order is first in the unfinished request management information 24d.

[0113] When the priority processing unit 25f determines in S182 that there is an API request with the first processing order in the unfinished request management information 24d, it determines to start processing the API request with the first processing order that exists in the unfinished request management information 24d (hereinafter referred to as the "target request" in the description of the processing shown in Figure 12) (S183).

[0114] When the processing of S183 ends, the priority processing unit 25f changes the processing status of the target request for which it was determined in S183 that processing should be started to "in processing" in the unfinished request management information 24d (S184). Therefore, after deleting the processing order of the target request, the priority processing unit 25f shifts the processing order of the API requests that exist in the unfinished request management information 24d and have been assigned processing orders forward by one.

[0115] When the process of S184 ends, the priority processing unit 25f executes the process of S181.

[0116] As shown in FIG. 8, when it is determined in S107 that the processing of the target request is to be started, the request executing unit 25e executes communication with the backend service server 25a to process the target request (S108).

[0117] When the process of S108 ends, the request execution unit 25e writes the start time of the processing of the target request by the backend service server 25a in the request history information 24e (S109).

[0118] When the processing of S109 is completed, the request execution unit 25e determines whether or not the result of the processing of the target request by the backend service server 25a has been received (S110) until it determines that the result of the processing of the target request by the backend service server 25a has been received.

[0119] When the priority processing unit 25f determines in S110 that it has received the results of processing the target request by the backend service server 25a, it writes the data communication volume in processing the target request by the backend service server 25a and the end time of processing the target request by the backend service server 25a to the request history information 24e (S111).

[0120] When the process of S111 is completed, the priority processing unit 25f deletes the information of the target request from the unfinished request management information 24d (S112).

[0121] When the process of S112 is completed, the data transmitter / receiver 25d transmits an API response including the result of the processing of the target request by the backend service server 25a to the client (S113), and the operation shown in FIG. 8 is completed.

[0122] The above has been described as a case where the first priority processing rule is indicated in the priority processing rule information 24g. Below, a description will be given of a case where the second priority processing rule is indicated in the priority processing rule information 24g.

[0123] When the second priority processing rule is indicated in the priority processing rule information 24g, the service providing system 20 executes the operation shown in Fig. 13, which will be described below, instead of the operation shown in Fig. 10. When the second priority processing rule is indicated in the priority processing rule information 24g, the service providing system 20 executes the same operation as the operations shown in Fig. 11 and Fig. 12.

[0124] FIG. 13 is a flowchart of the operation of the service providing system 20 when a priority is written in the outstanding request management information 24d in a case where the second priority processing rule is indicated in the priority processing rule information 24g.

[0125] When the second priority processing rule is indicated in the priority processing rule information 24g, the priority processing unit 25f performs the operation shown in FIG. 13 when the priority is written to the unfinished request management information 24d in S123 (see FIG. 9).

[0126] As shown in FIG. 13, the priority processing unit 25f determines whether the API request whose priority has been written in the outstanding request management information 24d (hereinafter referred to as the “target request” in the description of the operation shown in FIG. 13) is a high-priority request (S241).

[0127] If the priority processing unit 25f determines in S241 that the target request is a high-priority request, it adds the target request to the end of the current processing order in the unfinished request management information 24d, similar to the process in S142 (S242).

[0128] If the priority processing unit 25f determines in S241 that the target request is not a high-priority request, it determines whether or not there are any low-priority requests waiting to be processed other than the target request, based on the pending request management information 24d (S243).

[0129] If the priority processing unit 25f determines in S243 that there are no low-priority requests waiting to be processed other than the target request, it determines whether the time that has elapsed since the previous low-priority request was processed (hereinafter referred to as the "time since low-priority request processing") is equal to or greater than a specific time (S244). Here, the priority processing unit 25f can calculate the time since low-priority request processing based on the request history information 24e. The specific time in S244 may be longer than the specific time in S161 (see FIG. 11).

[0130] If the priority processing unit 25f determines in S244 that the time since the low-priority request processing is equal to or longer than a specific time, it adds the target request to the top of the current processing order in the unfinished request management information 24d, similar to the processing in S145 (S245).

[0131] The priority processing unit 25f terminates the operation shown in FIG. 13 when the processing of S242 is completed, when it determines in S243 that there is a low priority request waiting to be processed other than the target request, when it determines in S244 that the time since the low priority request was processed is not longer than a specific time, or when it executes the processing of S245.

[0132] The above has been described as a case where the first priority processing rule or the second priority processing rule is indicated in the priority processing rule information 24g. Below, a case where the third priority processing rule is indicated in the priority processing rule information 24g will be described.

[0133] When the third priority processing rule is indicated in the priority processing rule information 24g, the service providing system 20 performs the same operations as those shown in Figures 10 and 11. When the third priority processing rule is indicated in the priority processing rule information 24g, the service providing system 20 performs the operations shown in Figures 14 and 15, which will be described below, in addition to the operations shown in Figures 10 and 11.

[0134] Figure 14 is a flowchart of the operation of the service providing system 20 when the API interface unit 25b receives the results of processing an API request from the backend service server 25a when the third priority processing rule is indicated in the priority processing rule information 24g.

[0135] When the third priority processing rule is indicated in the priority processing rule information 24g, the priority processing unit 25f executes the operation shown in FIG. 14 every time the processing of S111 (see FIG. 8) ends.

[0136] As shown in FIG. 14, the priority processing unit 25f determines whether the API request whose processing end time was written immediately before in the request history information 24e is a high-priority request (S301).

[0137] When the priority processing unit 25f determines in S301 that the API request whose processing end time was most recently written in the request history information 24e is a high-priority request, it determines whether or not there is a low-priority request that is first in the processing order, based on the unfinished request management information 24d (S302).

[0138] If the priority processing unit 25f determines in S302 that there is no low-priority request that is first in the processing order, it determines whether there is a low-priority request waiting to be processed based on the pending request management information 24d (S303).

[0139] If the priority processing unit 25f determines in S303 that there are low-priority requests waiting to be processed, it determines whether the number of processed high-priority requests is equal to or greater than a specific number (S304). Here, the priority processing unit 25f can calculate the number of processed high-priority requests based on the request history information 24e. The specific number in S304 is the same as the specific number in S144.

[0140] When the priority processing unit 25f determines in S304 that the number of processed high-priority requests is equal to or greater than a specific number, it adds the low-priority request with the earliest received date and time (hereinafter referred to as the "target request" in the description of the operation shown in FIG. 14) among the low-priority requests waiting to be processed to the beginning of the current processing order in the unfinished request management information 24d (S305). That is, if the processing order of a high-priority request is not written in the unfinished request management information 24d, the priority processing unit 25f writes the target request as number 1 in the unfinished request management information 24d as the processing order. Furthermore, if the processing order of a high-priority request is written in the unfinished request management information 24d, the priority processing unit 25f shifts the processing order of the high-priority request written in the unfinished request management information 24d back by one, and then writes the target request as number 1 in the unfinished request management information 24d as the processing order.

[0141] The priority processing unit 25f terminates the operation shown in FIG. 14 when it determines in S301 that the API request whose processing end time was written immediately before in the request history information 24e is not a high priority request, determines in S302 that there is a low priority request that is first in the processing order, determines in S303 that there are no low priority requests waiting to be processed, determines in S304 that the number of high priority requests processed is not equal to or greater than a specific number, or terminates the processing of S305.

[0142] FIG. 15 is a flowchart of the operation of the service providing system 20 when it is determined to start processing an API request when the third priority processing rule is indicated in the priority processing rule information 24g.

[0143] The priority processing unit 25f executes the operation shown in FIG. 15 when the third priority processing rule is indicated in the priority processing rule information 24g.

[0144] As shown in FIG. 15, the priority processing unit 25f determines whether there are any API requests whose processing status is "in processing" based on the unfinished request management information 24d until it determines that there are no API requests whose processing status is "in processing" (S381).

[0145] If the priority processing unit 25f determines in S381 that there is no API request whose processing status is "in progress", it determines whether there is an API request with the first processing order in the unfinished request management information 24d (S382).

[0146] If the priority processing unit 25f determines in S382 that there is no API request with the first processing order in the unfinished request management information 24d, it determines whether there is a low-priority request awaiting processing that has not yet been assigned a processing order in the unfinished request management information 24d (S383).

[0147] If the priority processing unit 25f determines in S383 that there are no low-priority requests awaiting processing that have not yet been assigned a processing order in the pending request management information 24d, it executes the process of S382.

[0148] When the priority processing unit 25f determines in S383 that there are low-priority requests awaiting processing and for which a processing order has not yet been assigned in the unfinished request management information 24d, it writes the number 1 in the unfinished request management information 24d as the processing order for the low-priority request with the earliest reception date and time among the low-priority requests awaiting processing and for which a processing order has not yet been assigned that exist in the unfinished request management information 24d (S384).

[0149] When the priority processing unit 25f determines in S382 that there is an API request in the unfinished request management information 24d that has the first processing order, or when the processing of S384 is completed, it determines to start processing the API request in the unfinished request management information 24d that has the first processing order (hereinafter referred to as the "target request" in the description of the processing shown in Figure 15) (S385).

[0150] When the processing of S385 ends, the priority processing unit 25f changes the processing status of the target request for which it was determined in S385 that processing should be started to "in processing" in the unfinished request management information 24d (S386). Therefore, after deleting the processing order of the target request, the priority processing unit 25f shifts the processing order of the API requests that exist in the unfinished request management information 24d and have been assigned processing orders forward by one.

[0151] When the process of S386 ends, the priority processing unit 25f executes the process of S381.

[0152] As described above, when the service providing system 20 determines the priority of an API request in S122 such that the higher the priority of the API request, the less API usage by the client that is the request source of the API request, it is possible to reduce the possibility that processing resources for the API request will be monopolized by an API request from a specific client, thereby improving fairness of services.When the service providing system 20 determines the priority of an API request in S122 such that the higher the priority of the API request, the less API usage by the tenant that is the request destination of the API request, it is possible to reduce the possibility that processing resources for the API request will be monopolized by an API request for a specific tenant, thereby improving fairness of services.

[0153] When determining the priority of a specific request in S122 such that the higher the priority of the API request, the fewer the number of times an API request whose API user is the same as the specific request as the specific API request is received, the service providing system 20 can improve the appropriateness of the priority of the API request.When determining the priority of a specific request in S122 such that the higher the priority of the API request, the fewer the amount of data communication required to process an API request whose API user is the same as the specific request as the specific API request, the service providing system 20 can improve the appropriateness of the priority of an API request.When determining the priority of a specific request in S122 such that the higher the priority of the API request, the fewer the processing time required for an API request whose API user is the same as the specific request as the specific API request, the service providing system 20 can improve the appropriateness of the priority of an API request.

[0154] When the service providing system 20 determines the priority of an API request in S122 based on the usage volume of the API by a specific API user per time period, it can reduce the possibility that API request processing resources will be monopolized by a user that tends to use a lot of API request processing resources in a specific time period, thereby improving the fairness of the service.

[0155] If the service providing system 20 has processed a specific number or more API requests with a higher priority than the low-priority request (YES in S144 or YES in S304) after previously processing a low-priority request as the API request with the lowest priority, the service providing system 20 processes one low-priority request (YES in S107, S108, S145, S183 and S305), thereby reducing the possibility of excessive delays in processing low-priority requests and, as a result, improving the fairness of services.

[0156] If a specific time or more has passed since the last processing of a low-priority request, which is the API request with the lowest priority (YES in S244), the service providing system 20 processes one low-priority request (YES in S107, S108, S183 and S245), thereby reducing the possibility of excessive delays in processing low-priority requests and, as a result, improving the fairness of services.

[0157] If a specific time or more has passed since receiving a low-priority request as the API request with the lowest priority (YES in S161), the service providing system 20 processes the low-priority request (YES in S107, S108, S162 and S183), thereby reducing the possibility of excessive delays in processing the low-priority request and, as a result, improving the fairness of the service. [Explanation of symbols]

[0158] 20 Service provision system (computer, information processing device) 24a Service Delivery Program 35a Client

Claims

1. determining the priority such that the higher the priority of an API request, the less the amount of use of the API by a specific API user; The API request is processed with a higher priority, and The service providing system is characterized in that the user is one of a client that is the request source of the API request, a tenant that is the request destination of the API request, and a combination of the client and the tenant.

2. The service providing system of claim 1, characterized in that the usage amount when determining the priority of a specific request as a specific API request includes at least one of the number of times the API request whose user is the same as the specific request is received, the amount of data communication in processing the API request whose user is the same as the specific request, and the processing time of the API request whose user is the same as the specific request.

3. 2. The service providing system according to claim 1, wherein the priority is determined based on the amount of use for each time period.

4. The service providing system described in claim 1, characterized in that, after a low-priority request as the API request with the lowest priority has been previously processed, if a specific number or more of API requests with a higher priority than the low-priority request have been processed, one of the low-priority requests is processed.

5. The service providing system according to claim 1, characterized in that one low priority request is processed if a specific time or more has passed since the last processing of the low priority request as the API request with the lowest priority.

6. The service providing system according to claim 1, characterized in that the low priority request is processed if a specific time or more has elapsed since the low priority request was received as the API request with the lowest priority.

7. determining the priority such that the higher the priority of an API request, the less the amount of use of the API by a specific API user; The API request is processed with a higher priority, and The information processing apparatus is characterized in that the user is one of a client that is a request source of the API request, a tenant that is a request destination of the API request, and a combination of the client and the tenant.

8. A service providing program executed by a computer, causing the computer to determine the priority such that the higher the priority of an API request, the less the amount of use of the API by a particular API user; causing the computer to process the API requests with a higher priority; The service providing program, wherein the user is any one of a client that is a request source of the API request, a tenant that is a request destination of the API request, and a combination of the client and the tenant.

Images