Estimating aggregate costs using tokens

In general, one aspect of the subject matter described can be embodied in a method that includes receiving a first repair request for a first computer hardware component and receiving a second repair request for a second computer hardware component. The method can further include selecting first numerical tokens to describe the first repair request and selecting second numerical tokens to describe the second repair request, wherein each of the first and second tokens are associated with a different level of a hierarchy of tokens. The method can additionally include, for each level of the hierarchy of tokens, selecting each unique individual token associated with the level of the hierarchy of tokens from the first tokens and from the second tokens. The method can further include determining an aggregate cost of the first request and the second request from the selected unique individual tokens.

BACKGROUND

The present disclosure relates to estimating costs associated with performing requested actions.

In management accounting, cost accounting establishes the budget and actual cost of operations, processes, departments or products and the analysis of variances, profitability or use of funds. Managers use cost accounting to support decision-making to cut a company's costs and improve profitability. Cost estimation models are mathematical algorithms or parametric equations typically used to estimate the costs of a product or project. The results of the models are commonly needed to obtain approval to proceed, and are factored into business plans, budgets, and other financial planning and tracking mechanisms.

SUMMARY

This specification describes technologies relating to cost estimation.

In general, one aspect of the subject matter described in this specification can be embodied in a method that includes receiving a first repair request for a first computer hardware component of a first computer and receiving a second repair request for a second computer hardware component of the first computer. The method can further include selecting first numerical tokens to describe the first repair request wherein the first tokens include one or more first pairs of tokens that are related as hardware component and subcomponent and wherein each of the first tokens is associated with a different level of a hierarchy of tokens; and selecting second numerical tokens to describe the second repair request wherein the second tokens include one or more second pairs of tokens that are related as hardware component and subcomponent and wherein each of the second tokens is associated with a different level of the hierarchy of tokens. The method can additionally include, for each level of the hierarchy of tokens, selecting each unique individual token associated with the level of the hierarchy of tokens from a set of individual tokens the include at least a first individual token from the first tokens associated with the level of the hierarchy of tokens and a second individual token from the second tokens associated with the level of the hierarchy of tokens; and determining an aggregate cost of the first request and the second request from the selected unique individual tokens.

These and other embodiments can optionally include one or more of the following features. The first numerical tokens can include three individual tokens and the second numerical tokens comprises three individual tokens and where the set of selected unique individual tokens is comprised of at least one individual token from the first numerical tokens and at least one individual token from the second numerical tokens. The three individual tokens of the first numerical tokens can be associated with a hardware component type for the first computer hardware component, a location of the first computer hardware component within the first computer, and a computer hardware subtype for the first computer hardware component; and the three individual tokens of the second numerical tokens can be associated with a hardware component type for the second computer hardware component, a location of the second computer hardware component within the first computer, and a computer hardware subtype for the second computer hardware component.

The first computer hardware component can be different than the second computer hardware component. The first hardware component can be one of the group consisting of: a hard drive, a hard drive cable, a processor, a heatsink, a fan, a power supply, a power supply cable, random access memory, and a motherboard. The levels of the hierarchy of tokens can be associated with levels of abstraction of hardware components of the first computer. Determining the aggregate cost can include determining a cost associated with each of the selected unique individual tokens. The cost associated with a selected unique individual tokens can correspond to a cost of a hardware component and a cost of labor associated with the individual token. The determined aggregate cost can include a first cost associated with performing the first repair request plus a second cost associated with performing the second repair request minus a third cost associated a portion of the second repair request that is performed as part of the first repair request.

Particular embodiments of the subject matter described in this specification can be implemented to realize one or more of the following advantages. The efficiency and accuracy by which costs can be estimated is increased. Redundant actions are identified by simply comparing the tokens representing the received requests. Additionally, the complexity associated with managing and identifying cost savings associated with performing multiple requests together is decreased. When a new request is added to the system, it is assigned a group of individual tokens from the existing token hierarchy based upon the hardware component associated with the request. There is no comparison between the new request and the existing request and no rules need to be created.

DETAILED DESCRIPTION

FIG. 1shows a diagram100illustrating an example token-based approach to determining costs associated with repairing a computer system. The diagram100illustrates a server102(e.g., a computing device such as a personal computer, a portable computer, a personal digital assistant, or a mobile phone) that receives requests104to repair computer hardware components. Based upon the received requests104, the server102determines an estimated aggregate cost107to repair the computer hardware components. The aggregate cost estimate107can include the cost of labor (e.g., the cost for a technician to travel to the site and to perform the repairs) and hardware (e.g., the cost of the hardware component being used for the repair or replacement) to fulfill the requests107.

For example, the server102receives three requests108a-cto repair hardware components in computer106. The first request108ais a request to replace hard drive A110aof computer106. The second request108bis a request to replace hard drive B110bof computer106. The third request108cis a request to replace a cable110cconnecting hard drive A110ato a mother board in computer106. The server102estimates an aggregate cost107for performing these three requests108a-c. For instance, the server102can estimate the aggregate cost107based on the cost associated with a technician to perform requests108a-cand the cost of replacement parts for the hard drive A110a, the hard drive B110b, and the cable110c.

The aggregate cost estimate107produced by the server102accounts for cost savings that are realized by performing related requests108a-ctogether. Cost savings can be realized at least when there are overlapping labor actions associated with the requests108a-c. For instance, there are labor actions associated with each of the requests108a-c(e.g., technician travels to the computer106, the technician opens the computer106, the technician replaces a part in the computer106etc.). An overlapping labor action is an action that is performed as part of two or more of the requests108a-c(e.g., to perform each of the requests108a-cindividually, a technician has to open the computer106). When there is a labor action associated with the requests108a-cthat overlaps, a cost savings is realized because the overlapping action is performed only once for all of the requests108a-cinstead of once for each of the requests108a-c. An amount of cost savings realized depends on at least the cost associated with the overlapping action (e.g., a cost for a technician to open the computer106) and a number of requests over which the action overlaps (e.g., if two requests have an overlapping action, the cost of the action is saved once; if three requests have an overlapping action, the cost of the action is saved twice, etc.).

For example, the cost associated with the request108ato replace hard drive A110acan include the labor cost associated with a technician traveling to computer106, opening computer106, accessing hard drive A110a, and replacing hard drive A110a. The cost associated with the request108cto replace cable110cconnecting hard drive A110ato the motherboard can include the labor cost associated with a technician traveling to computer106, opening computer106, accessing hard drive A110a, and replacing cable110c. The first three labor actions performed for the requests108aand108coverlap. When requests108aand108care performed together, a technician will only have to travel to computer106, open computer106, and access hard drive A110aonce. By performing requests108aand108ctogether, a cost savings can be realized since the three overlapping actions are performed once instead of twice. These cost savings are accounted for in the aggregate cost estimate107by the server102.

The server102uses tokens associated with the requests108a-cto efficiently estimate the aggregate cost107while accounting for cost savings. Each request can be associated with a group of tokens that collectively represent the request. Each individual token can represent a portion of a request, such as a type of action (or a collection of actions) that is performed as part of a request, a position at which an action is performed, or a type of hardware component to which an action is performed. For example, if the request108ais represented by a group of three individual tokens, then the first token can indicate that the request108apertains to an action related a hard drive, the second token can indicate that the request108aregards hard drive position A110aspecifically, and the third token can indicate the request108aspecifically regards replacing hard drive A110a.

The individual tokens that represent a request can be part of a hierarchy of tokens. By way of illustration, each of the individual tokens can represent a distinct part of the computer106at a different level of abstraction. Using the previous example, the first token is associated with a first level of abstraction where the computer106is divided into distinct parts such a hard drive, a processor, a motherboard, a power supply, memory, etc. The second token is associated with a second level of abstraction in which the distinct parts from the first level of abstraction are divided further into distinct parts. For instance, the first level of abstraction corresponding to hard drives can be divided into the distinct parts hard drive A110aand hard drive B110b. The third token is associated with a third level of abstraction within which the distinct parts from the second level are divided further. For example, the second level of abstraction corresponding to hard drive A110acan be divided into the distinct parts the hard drive A110aitself, the cable110cattaching to the hard drive A110ato the motherboard, a power supply cable attaching to hard drive A110a, etc.

In some implementations, the number of levels of abstraction corresponds to the number of individual tokens used to represent a request. For example, if server102uses a token hierarchy having five levels of abstraction, then each of the requests108a-cwill be represented by a group of five individual tokens. The individual tokens are ordered such that the first individual token for each of the requests108a-ccorresponds to the same level of abstraction, the second individual token for each of the requests108a-ccorresponds to the same level of abstraction, etc. The individual tokens representing a request can be ordered in a variety of ways, including from the most general (the most abstract) level of abstraction to the most specific (the least abstract) level of abstraction.

A single request is uniquely represented by its associated group of tokens. However, the individual tokens within a group of tokens can be used in other groups of tokens to uniquely represent other requests (e.g., tokens A and B can uniquely represent request108aand tokens A and C can uniquely represent request108b). Two groups of tokens representing two requests share an individual token when there is an associated action that overlaps between the two requests. For two requests sharing an overlapping action (represented by having an individual token in common), the overlapping action can be removed by selecting a set of unique tokens from the groups of tokens associated with the two requests.

For instance, if a first request is received to replace a first hard drive and a second request is received to replace a second hard drive, the first token for both requests can be the same (e.g., refer generally to replacing a hard drive). When a unique set of tokens is determined for these two requests, this first token will only be included in the unique set once. As such, the labor cost associated with the first token (e.g., the time for a worker to travel to and open the machine) will only be counted once and the associated cost savings can be accounted for.

In various implementations and by way of illustration, to efficiently estimate the aggregate cost107using tokens, the server102performs three steps112,114, and118with regard to the received requests108a-c. At the first step112, the server102converts the requests108a-cinto tokens. To perform this conversion, the server102can refer to a predetermined mapping of request to tokens.

Tokens can be encoded in a variety of data types, such as integers in some implementations. In the example depicted in diagram100, tokens are integers that are represented as hexadecimal numbers. As shown at step112, request108ais converted into the token 0x010104, request108bis converted into the token 0x010204, and request108cis converted into token 0x020104. The individual tokens within these tokens can be represented by distinct bits (e.g., three individual tokens represented by 8 bits each) or they can be represented using overlapping bits (e.g., the bits for an individual token that more specifically represents a request includes the bits representing an individual token that more generally represents the request).

In the example depicted, each of the requests108a-care represented by three individual tokens having overlapping bits. The first individual token is represented by the right-most 8 bits (e.g., bit mask 0x0000ff), the second individual token is represented by the right-most 16 bits (e.g., bit mask 0x00ffff), and the third individual token is represented by the right-most 24 bits (e.g., bit mask 0xffffff). The individual tokens for the requests108a-care shown in Table 1 below.

Depending on the levels of abstraction used to define the hierarchy of tokens for the computer106, these individual tokens for the requests108a-cshown in Table 1 can represent a variety of things. For instance, using the three levels of abstraction described in a previous example, the first individual token (0x000004) for the requests108a-cindicates that each of the requests108a-ccorresponds to a hard drive. The second individual token (0x000104) for requests108aand108cindicates that requests108aand108crelate to hard drive A110a. The second individual token (0x000204) for request108bindicates that request108brelates to hard drive B110b. The third individual tokens (0x010204 and 0x010104) for request108aand108bindicate that requests108aand108bregards replacing hard drive A110aitself and hard drive B110bitself, respectively. The third individual token (0x020104) for request108cindicates that the request108cregards replacing the cable110c.

At the second step114, the server102selects a unique set of individual tokens116from the tokens representing requests108a-c. The unique set of individual tokens116can be derived by comparing the individual tokens (e.g., bitwise comparison of tokens, inserting the tokens into a set of unique tokens, inserting the tokens into a hash set of tokens, etc.). Since the individual tokens in this example are each represented by an 8-bit number, the server102can perform a bitwise comparison of the individual tokens to select the unique set of individual tokens116.

The unique set of individual tokens106representing requests108a-cincludes six individual tokens, as depicted in Table 1. There is one unique token (0x000004) associated with the first individual token because each of the requests108a-ccorresponds to a hard drive. There are two unique tokens (0x000104 and 0x000204) associated with the second individual token because there is overlap between requests108aand108c. The requests108aand108cboth relate to hard drive A110a. However, request108bdoes not overlap because it corresponds to hard drive B110b, which is a distinct component at the second level of abstraction. There are three unique tokens (0x010104, 0x010204, and 0x020104) associated with the third individual token because there is no overlap among the requests108a-cwith regard to the specific action that is performed.

At the third step118, a cost associated with each of the unique individual tokens116for the requests108a-cis obtained. As described previously, this cost associated with an individual token can include the cost of labor and the cost of parts (e.g., hardware components) associated with the individual token. To determine the labor and parts cost, the server102can refer to at least some predetermined association between an individual token, the labor to be performed, and the parts to be used.

Example costs associated with the unique individual tokens116are shown in chart120. The costs in chart120are provided for illustrative purposes. For the token 0x000004, there is an example labor cost of $11.28 and an example parts cost of $0.00. The actions associated with token 0x000004 can include a technician traveling to the computer106and opening the computer106so as to expose the hard drive area. The labor cost of $11.28 is the cost associated with the technician performing these actions. Since no new parts are being installed with these actions, there is not an associated parts cost.

For tokens 0x000104 and 0x000204, each has an associated labor cost of $1.83 and a parts cost of $0.00. The actions associated with these two tokens can include a technician accessing hard drive A110aand hard drive B110b, respectively (e.g., accessing hard drive A110acan include removing a housing that surrounds hard drive A110a). The labor cost of $1.83 is the cost associated with the technician performing each of these actions. Since no new parts are being installed with these actions, there is not an associated parts cost. Although these tokens have the same associated cost, they can have different costs. For example, hard drive A may be wedged into a location of computer106that requires more time for a technician to access. In such a scenario, the labor costs associated with token 0x000104 (e.g., hard drive A110a) would be greater than those associated with token 0x000204 (e.g., hard drive B110b).

For tokens 0x010104 and 0x010204, each has an associated labor cost of $8.04 and a parts cost of $30.00. The actions associated with these two tokens can include a technician installing replacement hard drives for hard drive A110aand hard drive B110b. The labor cost of $8.04 for each token is the cost of the technician performing each hard drive installation. The part cost of $30.00 for each token is the cost associated with each of the new hard drives that is being installed. In this example, the hard drive A110aand the hard drive B110bare being replaced with hard drives having equivalent cost. As explained in the previous paragraph, the labor cost and part cost for each of these tokens can differ.

For token 0x010204, there is an associated labor cost of $1.20 and a part cost of $0.50. The action associated with this token can include a technician replacing the cable110cthat connects hard drive A110ato the motherboard in computer106. The labor cost of $1.20 is the cost of the technician installing the new cable and the part cost of $0.50 is the cost of the new cable.

Once these costs have been obtained, an estimated cost for the requests108a-cis determined by aggregating all of the costs associated with the unique tokens116. Since redundant actions contained within the requests108a-chave been removed through the use of a hierarchy of tokens, the costs associated with the unique tokens116can be aggregated without adjustment. In this example, the aggregate cost estimate107for the requests108a-cis $92.72. The server102can return or display this value to a requestor that submitted the requests104.

In some implementations, instead of dropping duplicate tokens for two requests sharing an overlapping action, duplicate tokens are added to a set of tokens used to estimate an aggregate cost for the two requests. In such implementations, a cost associated with the duplicate token can added to the aggregate cost estimate with or without a discount. For instance, as depicted inFIG. 1and described above with reference to Table 1, each of the three requests108a-chas an associated token 0x000004. A full cost ($11.28) associated with one of the 0x000004 tokens ($11.28) and a discounted cost (e.g., $1.12) associated with two of the 0x000004 can be added to the cost estimate. The discounted cost (e.g., $1.12) can represent a variety of additional costs not included in the full cost ($11.28), such as a technician having to travel to different locations to retrieve each of the associated parts.

FIG. 2shows an example diagram200illustrating a hierarchy of tokens used to represent two computer systems201and202. As described above with regard toFIG. 1, a hierarchy of tokens represents distinct parts within a computer system at different levels of abstraction. The example hierarchy of tokens depicted in diagram200present four different levels of abstraction.

A first level of abstraction corresponds to the computer systems201and202themselves. In this example, each computer system is defined by a motherboard. Motherboard203corresponds to computer system201and motherboard204corresponds to computer system202. For example, a housing that contains two motherboards would be defined as containing two computer systems. For this hierarchy of tokens, a received request to repair a computer hardware component (e.g., requests108a-c) will have a first token corresponding to the first level of abstraction. For example, token 0x00000001 can represent the computer system201and the token 0x00000002 can represent the computer system202.

A second level of abstraction corresponds to distinct parts (e.g., processor, power supply, motherboard, disk drives, etc.) of the computer systems201and202. For this example second level of abstraction, the distinct parts include the motherboard203, power supplies206a, processors206b, and disk tray206cfor computer system201, and the motherboard204, power supplies208a, processors208b, and disk tray208cfor computer system202. For this hierarchy of tokens, a received request to repair a computer hardware component (e.g., requests108a-c) will have a second token corresponding to the second level of abstraction. Example tokens corresponding to the computer parts206a-cand208a-cat the second level of abstraction are shown in Table 2 below.

The third level of abstraction corresponds to specific instances of the distinct parts identified in the second level of abstraction (e.g., hard drive A110aand hard drive B110b). For this example third level of abstraction, specific instances of the distinct parts include the motherboard203itself, the power supply unit (PSU) A210a, the central processing unit (CPU) A210b, a disk A210ccontained within the disk tray206c, and a disk B210dcontained within the disk tray206cfor the computer system201. The third level of abstractions additionally corresponds to the motherboard204itself, the PSU A212a, the CPU A212b, a disk A212ccontained within the disk tray208c, and a disk B212dcontained within the disk tray208cfor the computer system202. For this hierarchy of tokens, a received request to repair a computer hardware component (e.g., requests108a-c) will have a third token corresponding to the third level of abstraction. Example tokens corresponding to the computer parts at the third level of abstraction are shown in Table 3 below.

The fourth level of abstraction corresponds to distinct hardware components attached to (or including) the specific instances of distinct hardware parts identified in the third level of abstraction (e.g., cable110cattached to hard drive A110a). In this example hierarchy, the fourth level of abstraction specifically identifies the hardware component to which a received request refers. In this example fourth level of abstraction, the distinct hardware components include the motherboard203itself, the PSU A210aitself, power cable214aattached to PSUA210a, fan214battached to PSU A210a, the CPU A210bitself, heatsink214cattached to CPUA210b, disk A210citself, disk cable A214dattached to the disk A210c, disk B210ditself, and disk cable B214eattached to disk B210d. The third level of abstractions additionally corresponds to the motherboard204itself, the PSU A212aitself, power cable216aattached to PSUA212a, fan216battached to PSU A212a, the CPU A212bitself, heatsink216cattached to CPUA212b, disk A212citself, disk cable A216dattached to the disk A212c, disk B212ditself, and disk cable B216eattached to disk B212d. For this hierarchy of tokens, a received request to repair a computer hardware component (e.g., requests108a-c) will have a fourth token corresponding to the fourth level of abstraction. Example tokens corresponding to the computer parts at the fourth level of abstraction are shown in Table 4 below.

Although the hierarchy of tokens described above with reference toFIG. 2includes four levels of abstraction, any number of levels (e.g., 2, 3, 5, 6, 7, 8, etc.) can be used. For example, a three level hierarchy that does not account for the computer system (the first level of abstraction) could be used. The number of levels of abstraction can be based on the number of distinct hardware components within a computer system and the grouping of those components. For example, a computer system that has two separate disk trays (e.g., disk tray206c) each containing two hard drives (e.g., disk A214dand disk B214e) may require an additional level of abstraction over the levels of abstraction described above.

The computer systems201and202described above can be any variety of computing device, such as a rack-mounted server, a desktop machine, a laptop, a mobile device (e.g., a PDA, a cell phone, etc.), a printer device (e.g., a printer, a scanner, a copier, etc.) and a networking device (e.g., a switch, a wireless router). Although computer systems201and202are presented as having the same components, the hardware components as well the hierarchy representing the components of computing devices can vary.

FIG. 3shows an example system300for estimating a cost for a group of requests using a hierarchy of tokens. The system300is an example of a system in which the techniques described below can be implemented. Although several components are illustrated, there can be fewer or more components in the system300. Moreover, the components can be distributed on one or more computing devices connected by one or more networks or other suitable communication mediums.

The computer system300includes a server302, a client304, a network that enables communication between the client304in the server302, and a collection of databases308a-c. The client304generates request to repair computer hardware component and sends the requests to the server302over the network306. The server302estimates an aggregate cost for the received requests using the databases308a-cand returns the cost estimate to the client304.

The client304includes a request creator310which generates requests to repair computer hardware components. In some implementations, the request creator310receives input from a user that indicates, at least in part, that a computer hardware component should be repaired. In some implementations, the request creator310autonomously generates requests. For example, a computer in need of a repair, such as computer106, sends a message to the client304indicating that one of its components is in need of repair. In response, request creator310generates a request to send to the server302autonomously.

Once the request creator310has generated a request, the request creator310sends the created request to an input/output (I/O) interface312included in the client304. The I/O interface312sends a request generated by the request creator310through the network306to the client302. The network306can be in a variety of networks that enable communication between the client304and the server302, such as such as the Internet, a subnet, a LAN, or a wireless network.

The server302includes an I/O interface314, a request to token converter316, a unique token identifying component318, a token cost determination component320, and a cost reporting module322. The server302receives a request from the client304at an I/O interface314. The I/O interface314provides received requests to the request to token converter316. The requested to token converter316converts received requests into an associated group of individual tokens, similar to the conversions described above with reference toFIGS. 1 and 2. To perform such a conversion, the requested token converter316uses a request to token associations database308a. The request to token associations database308astores associations between requests and tokens, such as the associations described above with reference toFIGS. 1 and 2.

For example, an association between request108aregarding hard drive A110aand token 0x010104 can be stored in the request to token associations database308. The request to token associations database308acan be populated with predetermined associations that are based upon a hierarchy of tokens, such as the hierarchy of tokens described above with reference toFIG. 2. Associations can be selected such that requests having related actions will have overlapping individual tokens.

Once a request has been converted to tokens by the requested token converter316, the token can be sent to the unique token identifying component318. The unique token identifying component318can identify the unique tokens. The unique individual tokens that are identified can represent a set of actions (with overlapping actions removed) to be performed for multiple requests. The unique token identifying component318can identify a set of unique tokens in a variety of ways, such as performing a bitwise comparison of the individual tokens that represent the multiple requests.

Once the unique individual tokens are identified by the unique token identifying component318, the token cost determination component320determines an aggregate cost for the unique individual tokens. The token cost determination component320can employ the assistance of a token labor cost database308band a token parts cost database308c. The token labor cost database308bcan store a variety of information associated with labor costs for a given token. The token labor cost database308bcan include information such as an amount of time estimated to perform the actions associated with a token, hourly wage rates for technicians that to perform the associated actions, and a physical location for the technicians. An estimated time for a repair associated with a token can be based upon an actual amount of time the repair took previously. Using this information, the token cost determination component320can determine an estimated labor cost associated the unique individual tokens.

For example, if a token has an estimated time of 15 minutes (0.25 hours), the technician assigned to perform the task has an hourly wage of $20/hour, and the technician is located 6 minutes (0.1 hours) away from the repair site, then the token cost determination component320can determine the estimated cost for the token to be $7.00 ($20/hour*0.25 hours+$20/hour*0.1 hours=$7.00).

The token cost determination component320also uses the token parts cost database308b. The token parts cost database308bprovides a cost for computer hardware components associated with tokens. For instance, an individual token that is associated with the action of installing a new hard drive can be associated with the cost of the new hard drive. The token parts cost database308bstores the associated cost of the new hard drive.

Additionally, the token cost determination component320can use additional input beyond the databases308b-cto determine the cost associated with tokens. The token cost determination component320can use additional parameters, such as an age and a warranty associated with the part as well as a platform type for a part (e.g., parts for some vendor platforms are more expensive than other vendor platforms). For example, if a part to be replaced is still within its warranty, the parts cost can be reduced to the cost of submitting the part for warranty replacement. However, if the part has extended beyond its warranty, an associated cost for the part is a full replacement part.

Once the token cost determination component320has aggregated the labor and parts cost associated with the unique individual tokens identified by the unit token identifying component318, the aggregate estimated cost is forwarded to the cost reporting module322. The cost reporting module322transmits the estimated aggregate cost to the client304using the I/O interface314. The client304receives the estimated aggregate cost from the server302via the I/O interface312and displays the cost using a cost display module324.

FIG. 4is a flow chart describing an example technique400for estimating an aggregate cost for a group of received requests. The technique400can be performed by a variety of systems, for example, by the server system302, as described with reference toFIG. 3.

The technique400begins at step402by receiving a request for repair or replacement of a computer hardware component from a client. The received request is converted into tokens corresponding to the request (step404). The token representing the request can be based upon a hierarchy of tokens, as described above with reference toFIGS. 1 and 2. The token for the received request can be predetermined and stored in a data repository, such as the request to token associations database308a.

If there are more requests to convert into tokens (step406), then step402is repeated for the additional requests. If there are no more requests to convert into tokens (step406), then a unique set of tokens is determined from the requests converted into tokens (step408). As described above with reference toFIGS. 1 and 3, the unique tokens can be identified efficiently by doing a bitwise comparison of the tokens.

With the unique set of tokens identified, a cost for each of the tokens in the unique set of tokens is determined (step410). The costs for each token can include a cost for labor and a cost for parts used to perform an action associated with the token. As described above with reference toFIG. 3, data repositories storing associated labor and parts costs, such as the token labor cost database308band the token parts cost database308c, can be employed. The costs for the unique set of tokens can be aggregated to provide an estimated aggregate cost for performing the received requests (step412). This estimated aggregate cost can account for overlapping actions associated with the received requests, as explained above with reference toFIG. 1. The aggregate estimated cost is sent to the client (step414).

Additional implementations of the description above are possible. The token-based cost estimation described above can additionally apply to requests to repair or replace components in other, non-computer systems. For example, the token-based cost estimation described above can be used to estimate costs associated with other electrical or mechanical systems that include multiple components.

A variety of hierarchies can be used for the token-based cost estimation described above. In some implementations, the hierarchy is based on the actions that are performed as part of a request. For example, with regard to the request108a, in such implementations the first individual token 0x000004 represents a general action for the request108a(e.g., opening the computer106), the second individual token 0x000104 represents a more specific action (e.g., accessing a part of the computer106where hard drives are located), and the third individual token 0x010104 represents a specific action (e.g., replacing hard drive A110a).

In further implementations, the hierarchy is based on hardware components within the computer106. For instance, with regard to the request108a, in such implementations the first individual token 0x000004 represents a general computer hardware component type for the request108a(e.g., a hard drive), the second individual token 0x000104 specifies to which hard drive the request108acorresponds (e.g., hard drive A), and the third individual token 0x010104 represents the components associated with hard drive A (e.g., hard drive A itself, a cable connecting hard drive A to a power supply, etc.) to which the request108acorresponds.

In additional implementations, the hierarchy is based on factors related to testing or replacement of computer hardware components. Such a hierarchy can be based on actions and costs associated with testing and submitting parts for warranty (e.g., using a returned materials authorization (RMA) process). For instance, with regard to the request108a, the first individual token 0x000004 represents an RMA cost (e.g., testing a part, executing a warranty procedure for a part, etc.) associated with replacing any disk (e.g., a hard drive), the second individual token 0x000104 represents an RMA cost for replacing an old disk (e.g., a disk that is no longer covered by a warranty), and the third individual token 0x010104 represents a cost for replacing a disk that is tested to be bad or unusable (as opposed to a disk that can be reused or recycled). Such a hierarchy can be used in alone or in concert with the other hierarchy implementations, discussed above, for estimating an aggregate cost associated with a group of requests.