JP2005338943A - Charging apparatus of computer, and charging method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a charging method that allows providing or using computer resources under proper conditions. <P>SOLUTION: This computer charging apparatus includes a request creating part 201 that presets process requirements, including the amount that the resources are used, and the amount of charging that is the fee for using the resources, as request requirements used when other computers constituting a distributed computer system are requested to perform processes; and a request input part 202 that, prior to a request to process a desired job to be actually requested, creates a sample job consuming resources equal to those consumed by the request requirements set by the request creating part 201 and the desired job and then presents the other computers with the sample job created. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a computer billing apparatus and billing method, and more particularly to a computer billing method in a distributed computer system.

  In recent years, in the field of scientific and engineering computations that perform large-scale numerical computations, it has become difficult for one computer to secure a processing capability that meets the intended computations. For this reason, a processing method that divides a target process into a plurality of processes that can be processed in parallel, and distributes the divided processes to a plurality of computers that operate independently in parallel and processes them in parallel is generally performed. It has become. According to this method, it is possible to easily secure the processing capacity corresponding to the target processing.

  In addition, when the processing scale is too large for a small portable computer, etc., processing is requested to another computer with high processing capability via the network and only the result is acquired. The form is also known. A system that achieves a predetermined purpose by using a plurality of computers in cooperation in this way is called a distributed computer system.

  When constructing a distributed computer system, for example, a specific organization recruits volunteers to construct a distributed computer system, and determines the purpose of this system, unit price, etc. Into the system. Attempts have also been made to build a large scale distributed computer system on a global scale, but it has only been successful in some special cases of free support from owners who agree with the objectives of interest. Absent. To realize a large-scale distributed computer system on a global scale to cope with the larger-scale processing required in scientific and technological calculations, to buy and sell processing power between computer centers, or to arrive at the ubiquitous network society Therefore, there is a need for a highly flexible billing method that makes it possible to request and accept processing between computers with a higher degree of freedom than ever before.

  By the way, each computer has its own owner. For this reason, in a distributed computer system or the like, when the owner makes another person use the computer, it is natural that a fee corresponding to the use is collected. For this reason, a billing system that performs billing according to the usage time of a computer or the usage amount of resources such as memory and disk has come to be used.

  As a method of charging between a plurality of computers constituting a distributed computer system, a common charging unit price is determined in advance among the computers, and the actual charging amount (usage fee) is integrated by the computer that manages the charging. Billing methods to manage are known. According to this method, when a process is requested from one computer to another computer, the computer that has requested the process obtains the accounting information relating to the computer that has requested the process from the computer that collects the accounting, and converts the accounting information to the obtained accounting information. Based on this, it is determined whether or not to accept the processing request. When the requested process is executed, the charge amount is calculated on the computer side that executes the process, and the calculation result is transmitted to the computer that collects the charge.

Patent Document 1 discloses a distributed computing system that exchanges incentives and surplus computer resources according to preferences between a computer that requests processing and a computer that requests processing.
JP 2003-256387 A

  As described above, in the conventional distributed computer system, in order to charge for the usage amount of the computer resource, it is necessary to share the charging unit price among the computers constituting the distributed computer system in advance. On the other hand, actual computer owners have various circumstances. For this reason, it is difficult to increase the scale of the system by increasing the number of computer owners who agree with the distributed computer system with a fixed type of fixed charging unit price determined in advance. That is, with such a billing method, the number of computers constituting the distributed computer system must be small.

  Moreover, in the distributed computing system described in Patent Document 1, it is shown that incentives according to preferences and surplus computer resources are exchanged. However, in a conventional system including this system, whether or not a billing amount (usage fee) corresponding to this processing amount can be obtained with respect to the processing amount actually performed is determined after actually performing the processing. Without it, it cannot be judged. In other words, this system does not consider the owner's circumstances regarding the amount of processing and the amount of charge commensurate with it, and a value that satisfies the owner of both the computer requesting the processing and the computer requesting the processing is obtained. Not always.

  The present invention has been made in view of these problems, and provides, for example, a charging method that can provide or use surplus computer resources under appropriate conditions.

  In order to solve the above problems, the present invention employs the following means.

  Request creation unit that presets processing conditions including resource usage and billing as resource usage as request conditions when requesting processing to other computers that make up the distributed computer system, and target job that is actually requested Before the processing request, a request input unit is provided that generates a sample job that consumes the same resource as the request condition and the target job set by the request creation unit, and presents the generated sample job to another computer.

  Since the present invention has the above-described configuration, it is possible to provide a billing method that can provide surplus computer resources under appropriate conditions.

  Hereinafter, the best embodiment will be described with reference to the accompanying drawings. FIG. 1 is a diagram for explaining a distributed computer system according to the present embodiment. FIG. 2 is a diagram for explaining the outline of the processing flow in this distributed computer system. The dashed arrows indicate data transmission / reception.

  The distributed computer system includes a requester system (101) that requests processing and a provider system (107) that provides computer resources, and functions as a distributed computing system by operating in cooperation.

  The requester operates the requester system (101) to set (102) various conditions (105) of the request, and inputs the target job (103) (step 1501). The various conditions setting (102) is, for example, an upper limit value of a billing unit price (request unit price) for a request to be made in the future.

  The client system (101) creates a sample job (106) from the target job (103) (step 1502). Next, the requester system (101) creates a request (104) by adding various conditions (105) to the created sample job (106) (step 1503). The various conditions (105) define the charging (115) for execution of the job (112) or the execution deadline.

  Next, the client system (101) recruits a provider system (107) that executes the job (112) using the Internet or the like (step 1504).

  On the other hand, the provider (computer resource provider) sets various conditions (108) in the provider system (107) (step 1515). The various conditions setting (108) is, for example, a lower limit value of a charging unit price per usage amount of computer resources, which includes a CPU usage amount, a memory usage amount, a disk usage amount, and the like. The provider system (107) circulates the Internet and searches for the request (104) from the client system (101) (step 1516). The provider system (107) having found the request (104) (step 1517) obtains the request (104) from the requester system (101) (step 1518).

  The provider system (107) executes the sample job (106) when the conditions (105) of the request (104) match the conditions (105) of the request (104) (step 1520). Then, an application (109) is created from the result data (111) and the conditions (110) presented by the provider system (107), and an application for the request (104) is applied to the client system (101) (step 1521). ). The conditions (110) presented by the provider system (107) are billing (115) billed as compensation for providing the execution result of the requested job (112).

  Upon receiving the application (109) (step 1505) (step 1506), the client system (101) determines that the conditions (110) of the application (109) match the conditions (102) of its own (step 1507). ) Request the actual job (112) from the provider system (107). The requester system (101) sends an application rejection signal (step 1508) to the provider system (107) when the application does not match its own conditions setting (102) (step 1507).

  When requesting an actual job, the client system (101) sends the job (112) to the provider system (107) (step 1509). The provider system (107) receives the job (112) (step 1522) (step 1523), processes the job (112) (step 1525), records the charge (115) (step 1526), Data (114) and billing (115) are transmitted as a result (113) to the client system (101) (step 1527).

  The client system (101) receives and records the result (113) (step 1510). If the job (112) still exists (step 1512), the job (112) is further sent. If the job (112) does not exist (step 1512), a termination signal is sent to the provider system (107) (step 1512). 1513) From the result (113), the target result (116) and the charge total (117) are totaled (step 1514).

  The job execution history is managed as accounting information by both the client system (101) and the provider system (107). This is because billing is settled later by means such as electronic payment based on the billing information.

  The billing unit price initially presented from the client system (101) to the provider system (107) is as low as possible, for example, 0, which is lower than the billing unit price lower limit set in the provider system (107). In this case, the provider system (107) requests the requester system (101) for the charge unit price at the charge unit price lower limit set in the provider system (107), and the requested charge unit price is requested. When the upper limit of the charging unit price set in the provider system (101) is exceeded, the processing request for the job (112) from the requester system (101) is accepted by the provider system (107). That is, the job (112) is processed at a charge unit price agreed upon by both parties.

  Next, details of the configuration and processing operation of the client system (101) and the provider system (107) will be described. The computer resource will be described using three examples: CPU, memory, and disk.

(1) Requester System FIG. 3 is a diagram for explaining the requester system (101). The requester system (101) includes a request creation unit (201), a request input unit (202), a provider reception unit (203), a result reception unit (204), and a result totaling unit (205). The request creation unit (201), the request input unit (202), the provider reception unit (203), the result reception unit (204), and the result totaling unit (205) operate independently and in parallel, and request as a whole. Function as an operator system (101).

  FIG. 4 is a diagram for explaining the flow of processing of the request creation unit (201) of the client system 101. In the request creation unit (201), the requester (209) inputs the request condition setting information (102) through the terminal (208) (step 1601) and inputs the target job (103) (1602). Next, the request creation unit (201) creates a sample job (106) from the target job (103). The sample job (106) is a job (112) that consumes resources equivalent to the job (112) obtained by dividing the target job (103) into appropriate units, and the result of executing the sample job (106) In addition to the processing result, the function has a function of recording the time taken to execute the sample job (106) (step 1603).

  The request creation unit (201) creates a request (104). Each parameter of the request (104) is determined based on the request condition setting information (102), and the sample job (106) is stored in the request (104) (step 1604). Next, the request creation unit (201) divides the target job (103) into a plurality of jobs (112) in an appropriate unit (step 1605). Next, the same number of profiles (207) as the number of jobs (112) are created, and one job (112) is linked to each profile (207) (step 1606). Next, the request creation unit (201) queues the profile (207) to the request (104), and associates the divided job (112) with the request (104) via the profile (207) (step 1607). Next, the request (104) is queued to the request queue (206) (step 1608).

  FIG. 5 is a diagram for explaining the request condition setting information (102). The request condition setting information (102) includes the electronic certificate (401) of the requester system (101), the title of the request (402), the processing condition (403), the resource usage (408), and the request deadline. (412), a piece of information that stores the maximum sample execution time (413), the billing unit price (414) to be presented, and the upper limit (415) of the billing unit price. The processing condition (403) is a set of information that stores the CPU type (404), the OS type (405), the memory size (406), and the disk size (407). Also, the resource usage (408) serving as a resource reference is a set of information storing the CPU usage (409), the memory usage (410), and the disk usage (411).

  FIG. 6 is a diagram for explaining request information to be set in the request (104). As shown in FIG. 6, the request information includes the electronic certificate (501) of the requester system (101), the title of the request (502), the processing condition (503), the sample job (508), and the execution of the job (112). A set of usage quantities (509), a billing unit price for a request (513), a deadline for request (514), a pointer to request (515), a pointer to profile (516) Information.

  FIG. 7 is a diagram illustrating the job (112). As shown in FIG. 7, the job (112) includes an electronic certificate (901), a request title (902), a job number (903), a program (904), and data (905) of the client system (101). It is a piece of information that stores.

  FIG. 8 is a diagram for explaining the profile (207). As shown in FIG. 8, the profile (207) stores a pointer (701) to the job (112), a pointer (702) to the result (113), and a pointer (703) to the next profile (207). It is information of unity.

  FIG. 9 is a diagram for explaining the processing flow of the request input unit (202) of the client system (101). The request input unit (202) takes out one request (104) from the request queue (206) (step 1701). If there is a request (104) (step 1702), the request (104) is stored in an area accessible by the provider system (107) via the Internet (step 1703). If there is no request (104) (step 1702), the process returns to the process (step 1701) for retrieving the request (104) from the request queue (206).

  Note that the HTTP protocol or the like may be used for data transmission / reception between the client system and the provider system. Further, since the request (104) includes an electronic certificate, the subsequent communication can be SSL communication using a certificate authority.

  FIG. 10 is a diagram for explaining the processing flow of the provider accepting unit (203) of the client system (101). The provider accepting unit (203) waits for an application (109) to execute the request (104) (step 1801) (step 1802), and receives the application (109) as a provision request for the job (112). 109), the execution result (114) of the sample job (106) by the provider system (107) and the conditions (110) presented by the provider system (107) are extracted (step 1803).

  When the execution result (114) is not correct (step 1804), the provider accepting unit (203) rejects the application (109) (step 1805). When the execution result (114) is correct (1804), the time spent for executing the sample job (106) is read from the execution result (114). When the execution time of the sample job (106) is longer than the longest execution time (413) set in the request condition setting information (102) (step 1807), the application (109) is rejected (step 1808).

  When the time taken for execution is shorter than or equal to the longest execution time (413) set in the request condition setting information (102) (step 1807), and the conditions (110) presented by the provider system (107) ) Included in the request condition setting information (102) is larger than the charge unit price upper limit (415) (step 1809), the application (109) is rejected (step 1810).

  When the requested charging unit price (804) is not larger than the charging unit price upper limit (415) set in the request condition setting information (102) (step 1809), the job (112) is sent to the provider system (107). (Step 1811).

  FIG. 11 is a diagram for explaining the details of the application (109). As shown in FIG. 11, the electronic certificate (801) of the provider system (107) and the electronic certificate (802) of the requester system (101) are shown. ), The request title (803), the requested charging unit price (804), and the processing result data (805).

  FIG. 12 is a diagram for explaining the processing flow of the result receiving unit (204) of the client system (101). The result receiving unit (204) waits for the arrival of the result (113) (step 1901) (step 1902). When the result (113) is received from the provider system (107), the result receiving unit (204) links it to the corresponding profile (207). (Step 1903). If the job (112) still exists (step 1904), the next job (112) is transmitted to the provider system (107) (step 1906). If there is no job (112) (step 1904), a signal indicating that the job (112) has disappeared is transmitted to the provider system (107) (step 1905).

  FIG. 13 is a diagram for explaining the details of the result (113). As shown in FIG. 13, the result (113) is the electronic certificate (1001) of the provider system (107), the electronic certificate (1002) of the requester system (101), the title (1003) of the request, and the billing settlement flag. (1004), billing (1005), and processing result data (1006) as a set of information.

  FIG. 14 is a diagram for explaining the flow of processing of the result counting unit (205) of the client system (101). The result totaling unit (205) waits for the arrival of the result (113) (step 2001), and the result (113) sufficient to search the request queue (206) and total the result (113) is collected (step 2002). ) The results (113) of the request (104) are totaled and stored in the request (104) (step 2003). In response to an instruction from the terminal (208) of the requester (209) (step 2004), the result of the specified request (104) is output to the terminal (208) (step 2005). As a result, the client (209) can obtain the desired result (116).

(2) Provider System FIG. 15 is a diagram illustrating the provider system. The provider system (107) includes a request collection unit (301), a sample execution unit (302), a target job processing preparation unit (303), a target job processing execution unit (304), and a result totaling unit (305). The request collection unit (301), sample execution unit (302), target job processing preparation unit (303), target job processing execution unit (304), and result totaling unit (305) operate independently and in parallel and are provided as a whole. Function as an expert system (107).

  FIG. 16 is a diagram for explaining the processing flow of the request collection unit (301) of the provider system (107). The request collection unit (301) reads one requester system information (1200) from the requester system list (306) (see FIG. 17) (step 2101). The request rejection system list (307) is searched using the electronic certificate (1201) of the requester system (101) included in the requester system information (1200) as a key, and matches the electronic certificate (1201) in it. If the electronic certificate (1201) to be included is included (step 2102), the requester system information (1200) is ignored, and the next requester system information (1200) is read (step 2101).

  If it is not included in the request rejection system list (307) (step 2102), the URL (1202) included in the requester system information (1200) is accessed (step 2103). If there is no request (104) as a result of the access (step 2104), one requester system information (1200) is read from the requester system list (306) (step 2101).

  When there is a request (104) (step 2104), the request (104) is read from the requester system (101) (step 2105) and queued in the request queue (314) (step 2106). Next, the request queue (314) is scanned and the expired request is deleted (step 2107).

  The client system list (306) may be fixed with preset values, or may be automatically updated using a search service on the Internet. The request rejection system list (307) is set in advance.

  FIG. 17 is a diagram for explaining the details of the client system list (306). The client system list (306) is a list of client system information (1200) as shown in FIG. The client system information (1200) is a set of information that stores the electronic certificate (1201) and URL (1202) of the client system (101).

  FIG. 18 is a diagram for explaining the details of the request rejection system list (307). As shown in FIG. 18, the request rejection system list (307) is a list of requester system information (1200) for which a request is to be rejected.

  FIG. 19 is a diagram illustrating the flow of processing of the sample execution unit (302) of the provider system (107). Evaluation condition setting information (108) is set in advance in the sample execution unit (302).

  The sample execution unit (302) retrieves one request (104) from the request queue (314) (step 2201), and the provider system (107) satisfies the execution condition described in the request (104) (Step 2202) The sample job (106) stored in the request (104) is executed to obtain execution result data, processing time, memory usage, and disk usage (Step 2203). Next, the sample execution unit (302) creates one application, sets each parameter, and stores execution result data of execution of the sample job (106) in the application (step 2204) (step 2205).

  Based on the charging unit price (513) described in the request (104) (see FIG. 6), as shown in FIG. 20, the charging unit price per processing time (602), the charging unit price per memory usage (603), and The billing unit price (604) per disk usage is calculated and stored in the evaluation (309) (steps 2206, 2207, 2208).

  The evaluation result is compared with the minimum charge per processing time (1407), the minimum charge per used memory (1408), and the minimum charge per used disk (1409) included in the evaluation condition setting information (108) shown in FIG. The request (104) that does not satisfy the condition is deleted from the request queue (314) (step 2212). For a request that does not satisfy the condition, the unit price per processing time is not larger than the minimum unit price per processing time (step 2209), or the unit price per memory usage is larger than the minimum unit price per memory usage. There is no charge (per step 2210), or the charged unit price per disk usage is not greater than the minimum charged unit price per disk usage (step 2211).

  Unit price per processing time, unit price per memory usage, unit price per disk usage, and coefficient (1410) to processing time set in the evaluation condition setting information (108) shown in FIG. The evaluation value (601) shown in FIG. 20 is calculated using the coefficient (1411) for the used memory and the coefficient (1412) for the used disk (step 2213), and the calculated evaluation value (601) is calculated per processing time. The charge unit price (602), the charge unit price per memory usage (603), and the charge unit price per disk usage (604) are stored in the evaluation (309) (step 2214). This evaluation (309) is shown in FIG. As described above, the request is queued in the evaluated request queue (308) in a state in which the evaluation values (601) are sorted in descending order (step 2215).

  FIG. 20 is a diagram for explaining the evaluation (309). As shown in FIG. 20, the evaluation (309) includes an evaluation value (601), a charging unit price per processing time (602), a charging unit price per used memory (603), a charging unit price per used disk (604), a request A set of information storing a pointer (605) to (104) and a pointer (606) to the next evaluation.

  FIG. 21 is a diagram for explaining the evaluation condition setting information (108). As shown in FIG. 21, the evaluation condition setting information (108) includes an electronic certificate (1401) of the provider system (107), a processing condition (1402), a minimum charge per processing time (1407), and a per-used memory. A person storing a minimum charge (1408), a minimum charge per used disk (1409), an evaluation coefficient for processing time (1410), an evaluation coefficient for used memory (1411), and an evaluation coefficient for used disk (1412) It is information of unity. The minimum charge per processing time (1407), the minimum charge per used memory (1408), and the minimum charge per used disk (1409) are information used in steps 2209, 2210, and 2211 in FIG. The evaluation coefficient for the processing time (1410), the evaluation coefficient for the used memory (1411), and the evaluation coefficient for the used disk (1412) are information used in step 2213 of FIG.

  FIG. 22 is a diagram for explaining the processing flow of the target job processing preparation unit (303) of the provider system (107).

  The target job processing preparation unit (303) (see FIG. 15) reads one request (104) from the evaluated request queue (308) (step 2301). The largest unit price among the unit price per processing time (602), the unit price per memory used (603), and the unit price per disk used (604) stored in the evaluation (309) shown in FIG. Is stored in the application (109) as the requested billing unit price (804) (step 2302). Next, the target job processing preparation unit (303) transmits an application (109) to the client system (101) (step 2303) and waits for a job (steps 2304 and 2305).

  When transmission of the job (112) is rejected from the requester system (101) (step 2306), the request (104) is deleted from the evaluated request queue (308) (step 2307). The received job (112) is linked to the profile (207) (step 2308) and queued to the request (104) (step 2309).

  The request (104) having the executable profile (207) and not queued to the execution request queue (310) (step 2310) and not expired (step 2313) is the execution request queue. Queue to (310) (step 2314).

  On the other hand, if the request has been queued to the execution request queue (310) (step 2310) and the request (104) has expired (step 2311), the request (104) is deleted from the execution request queue (310). (Step 2312).

  FIG. 23 is a diagram for explaining the execution waiting request (311). As shown in FIG. 23, the execution waiting request (311) is a piece of information storing a pointer (1101) to the next execution waiting request and a pointer (1102) to the request (104).

  FIG. 24 is a diagram for explaining the processing flow of the target job processing execution unit (304) of the provider system (107). The target job processing execution unit (304) reads one profile (207) from the execution request queue (310) (step 2401), takes out the job (112) accordingly (step 2402), and processes the job (112). Then, processing result data is obtained (step 2403). Next, the result (113) shown in FIG. 13 is created, each parameter is set (step 2404), and the processing result data is stored in the result (113) (step 2405).

  Next, the target job processing execution unit (304) describes the requested charging unit price (804) stored in the application (109) as the charging (1005) of the result (113) (step 2406), and displays the result (113). Link to the profile (207) (step 2407). Next, the target job process execution unit (304) transmits the result (113) to the client system (101). The request (104) having no executable profile (207) is deleted from the execution waiting request queue (310) (step 2409).

  FIG. 25 is a diagram for explaining the processing flow of the result totaling unit (305) of the provider system (107). When the provider (313) operates the terminal (312) shown in FIG. 15 to instruct the result output (steps 2501 and 2502), the result totaling unit (305) requests from the evaluated request queue (308) (104). ) And the profile (207), and the total of charges is totaled from the result (113) (step 2503). Next, the aggregation result is displayed on the terminal (312) used by the provider (313) in association with the information of the client system (101) described in the request (104) (step 2504), etc. 313) can know the result. When the provider (313) instructs to delete the evaluated request (steps 2501, 2502, 2505), the request (104) is deleted from the evaluated request queue (308) (step 2506).

  Since the request collection unit (301), sample execution unit (302), target job processing preparation unit (303), target job processing execution unit (304), and result totaling unit (305) operate independently, A request (104) queued in the request queue (314), a request (309) queued in the evaluated request queue (308), and an execution waiting request queued in the execution waiting request queue (310) The requests from a plurality of requester systems (101) are mixed. As a result, the load on the provider system (107) can be constantly increased, and computer resources can be used with high efficiency.

  As described above, according to the present embodiment, when a computer requests processing to another computer, before making an actual processing request, a sample of the processing to be requested and a unit price for the requested processing are set. Create a collective request, post the request on the Internet, etc., and recruit computers to process the request. On the other hand, the computer that wants to apply for the request executes the sample after finding the request and obtaining the request, and the usage amount of the resources spent for executing the sample is the unit price indicated in the form included in the request. Evaluate whether it is sufficient by comparison based on the conditions set in the system in advance. If the conditions are met, the unit will be charged at the unit price. If the conditions are not met, it will be accepted. A required billing unit price is created as a condition, and the billing unit price is shown together with a sample execution result to the requesting computer.

  On the other hand, the computer requesting the processing evaluates the execution result of the sample from the computer that has applied and the requested unit price based on various conditions set in advance in its own system. Send the request that contains the requested processing and data to the computer that applied.

  As a result, the computer owner who requests the processing is charged for the processing, and the computer owner who is requested for the processing is charged at a unit price that can satisfy both the charging for the resource usage. Can be determined.

  In addition, according to the present embodiment, the charge unit price can be set for each computer constituting the distributed computer system, so that the scale (number) of computers constituting the distributed computer system can be increased. Because, in a distributed computer system composed of a plurality of computers configured by providing computers owned by a plurality of computer owners, the payment amount (budget) on the side requesting the processing was actually processed. This is because it is possible to construct an environment in which each owner can be satisfied and distributed to the computer owner (s) without arranging a computer that controls the entire computer. This allows individual computer owners to satisfy their economic circumstances.

  In addition, when providing computer resources, the computer's free time is allocated to lending resources to the owner of the computer by establishing measuring means for obtaining an appropriate price for the provided resource. Since a clear incentive is generated, the scale of the distributed computer can be easily increased. Consumer personal computers around the world can contribute to the effective use of this resource because there are many times when the owner does not use it at night.

  In addition, in this system, a computer owner who can start price negotiation after it is time to decide whether to request / undertake processing can always participate in this distributed computing system. In addition, since a computer that controls the entire system is unnecessary, and it is not necessary to share the billing unit price with the entire distributed computer system in advance, it is possible to construct a large-scale distributed computer system on a global scale. For this reason, the application is not limited to dividing and executing a huge job efficiently, and it is possible to trade computer processing as a business between the requesting side and the providing side. Also, even in the case of a small portable computer, it is possible to virtually acquire a large-scale processing capacity that cannot be processed by itself, so that it can be applied to the field of mobile services, etc. Is possible.

It is a figure explaining the distributed computer system which concerns on this embodiment. It is a figure explaining the outline | summary of the flow of a process in a distributed computer system. It is a figure explaining a client system. It is a figure explaining the flow of a process of the request preparation part of a requester system. It is a figure explaining request condition setting information. It is a figure explaining the request information set to a request. It is a figure explaining a job. It is a figure explaining a profile. It is a figure explaining the flow of a process of the request input part of a requester system. It is a figure explaining the flow of a process of the provider reception part of a requester system. It is a figure explaining the details of application. It is a figure explaining the flow of a process of the result receiving part of a client system. It is a figure explaining the detail of a result. It is a figure explaining the flow of a process of the result total part of a client system. It is a figure explaining a provider system. It is a figure explaining the flow of a process of the request collection part of a provider system. It is a figure explaining the detail of a requester system list. It is a figure explaining the detail of a request refusal system list. It is a figure explaining the flow of a process of the sample execution part of a provider system. It is a figure explaining evaluation. It is a figure explaining evaluation condition setting information. It is a figure explaining the flow of a process of the target job process preparation part of a provider system. It is a figure explaining the execution waiting request. It is a figure explaining the flow of a process of the target job process execution part of a provider system. It is a figure explaining the flow of a process of the performance total part of a provider system.

Explanation of symbols

DESCRIPTION OF SYMBOLS 101 Requester system 107 Provider system 103 Target job 106 Sample job 201 Request creation part 202 Request input part 203 Provider reception part 204 Result reception part 205 Result total part 301 Request collection part 302 Sample execution part 303 Target job process preparation part 304 Target job processing execution unit 305 Result totaling unit

Claims (12)

A request creation unit that pre-sets processing conditions including resource usage and a billing amount that is a resource usage fee as request conditions when requesting processing to other computers constituting the distributed computer system;
A request submitting unit that generates a sample job that consumes resources equivalent to the request conditions set by the request creation unit and the target job before the processing request of the target job to be actually requested, and presents the generated sample job to another computer A computer billing apparatus comprising: The computer billing apparatus according to claim 1, wherein
Provided with a provider reception unit that receives the processing results of the sample job by the application computer, which is another computer that can be processed under the requested conditions, and sends the target job to the application computer based on the determination result of the received processing results A computer billing apparatus. The computer billing apparatus according to claim 2, wherein
A computer billing apparatus comprising: a result totaling unit that records a result of processing of a target job by an application computer and a charge that is a usage fee of a resource of the application computer. A request collection unit that collects a sample job that consumes resources equivalent to the request conditions provided by other computers constituting the distributed computer system and the target job to be actually processed;
A sample execution unit that executes the collected sample jobs;
When the charge amount set by the request processing computer is large by comparing the charge amount set by the request processing computer included in the request condition with the charge amount set by the providing computer providing the processing capability of the target job A computer billing apparatus comprising a target job processing preparation unit that requests transmission of a target job. The computer billing apparatus according to claim 4, wherein
An accounting apparatus for a computer, comprising: a target job execution unit for executing a received target job; and a result totaling unit for totaling execution results including a charge amount.    Request creation means for presetting processing conditions including resource usage and billing amount as resource usage as a request condition when requesting a computer to process another computer constituting the distributed computer system, and actually Request submission means for presenting to the other computer the request condition set by the request condition setting unit and the sample job generated by generating the sample job that consumes the same resource as the target job before the request processing of the requested target job A computer billing program characterized by functioning as a computer program. The computer billing program according to claim 6, wherein
Provider accepting means for receiving a processing result of a sample job by an application computer which is another computer capable of processing the computer under the presented request conditions, and transmitting the target job to the application computer based on the determination result of the received processing result A computer billing program comprising a program for causing a computer to function as a computer program. The computer billing program according to claim 7, wherein
A computer billing program comprising a program for causing a computer to function as a result totaling means for recording a result of processing a target job by an application computer and a charge that is a resource usage fee of the application computer.   Request collection means for collecting sample jobs that consume resources equivalent to the requested conditions and the target job to be actually processed, provided by other computers constituting the distributed computer system, and sample execution for executing the collected sample jobs The charge amount set by the request processing computer is large by comparing the charge amount set by the request processing computer included in the means and the request condition with the charge amount set by the providing computer providing the processing capability of the target job. If so, an accounting program for a computer that functions as a target job processing preparation means for requesting transmission of a target job. The computer billing program according to claim 9, wherein
A computer billing program comprising: a program for causing a computer to function as a target job execution unit for executing a received target job; and a result totaling unit for totaling execution results including a charge amount. A step of setting in advance processing conditions including resource usage and a billing amount that is a resource usage fee as request conditions when requesting processing to another computer;
Presenting the request condition and a sample job that consumes resources equivalent to the target job to be requested to other computers;
Receiving the processing result of the sample job by the application computer, which is another computer that can be processed under the presented request conditions, and sending the target job to the application computer based on the received processing result;
A computer billing method comprising a step of recording a processing result of a target job by an application computer and a charge amount which is a usage fee of a resource of the application computer. Collecting a sample job that consumes resources equivalent to the request conditions provided by other computers and the target job to be actually processed;
The request processing computer sets the charge amount set by the request processing computer included in the request condition and the charge amount set by the providing computer that provides the processing capability of the target job. A computer billing method comprising a step of requesting transmission of a target job when the billing amount is large.

Images