Patent Application
20130326067
The present invention is generally directed to routing service requests from one or more service requesters/users to one or more service providers.
In a distributed hosting environment, the hosted service is replicated to multiple servers (virtual or physical) to increase the performance of the service. Typically, access to the collection of servers is indirected through a hardware or software system acting as a reverse proxy. The reverse proxy distributes incoming requests for data to the collection of servers using a resource allocation technique (e.g., round-robin, random, shortest queue). In this manner, the reverse proxy enables the servers to collectively process a higher volume of requests than any single server could handle. However, the reverse proxy introduces a single point of failure when added to such distributed systems. That is, if the reverse proxy were to become unavailable, then the entire distributed system would be unavailable.
The present invention is generally directed to routing service requests on a network. Service requests may be issued by one or more users or service requesters on the network, and the present invention may distribute or allocate such service requests to service providers on the network, where these service providers are within a service provider set. The present invention may be in the form of a method for routing service requests over a network, or may be in the form of a system (e.g., a broker or a broker set) that is configured to route service requests in the manner addressed herein.
A first aspect of the present invention is directed to routing service requests over a network (e.g., a public cloud; a private cloud). Optimized weights for each service provider of a service provider set (having multiple service providers) may be derived using a non-linear function. The service providers of this service provider set are on the network. The optimized weights for the service providers of the service provider set collectively define a weighted distribution. A plurality of service requests are received by a broker over the network (e.g., the broker is part of the network). Each of the received service requests are routed over the network by the broker using the noted weighted distribution.
A second aspect of the present invention is directed to routing service requests over a network (e.g., a public cloud; a private cloud). Optimized weights for each service provider of a service provider set (having multiple service providers) may be derived by a broker using status information on each of the service providers within the service provider set. The service providers of this service provider set are on the network. The optimized weights for the service providers of the service provider set collectively define a weighted distribution. A plurality of service requests are received by the broker over the network. Each of the received service requests are routed over the network by the broker using the noted weighted distribution.
A third aspect of the present invention is directed to routing service requests over a network (e.g., a public cloud; a private cloud) having a plurality of brokers. Each broker derives its own weighted distribution using temporally independent status information on each service provider of its corresponding service provider set on the network (where each service provider set has multiple service providers). The weighted distribution for each broker is in the form of an optimized weight for each service provider of its corresponding service provider set. A plurality of service requests are received by each broker over the network. Received service requests are routed over the network by each broker using its corresponding weighted distribution.
A number of feature refinements and additional features are separately applicable to each of above-noted first, second, and third aspects of the present invention. These feature refinements and additional features may be used individually or in any combination in relation to each of the first, second, and third aspects.
Optimized weights for each service provider of a given service provider set (where the service provider set may have any appropriate number of multiple service providers on the network) may be derived using a non-linear function. This derivation may be undertaken by a broker—a broker may derive optimized weights for each service provider of its corresponding service provider set (e.g., a broker may be configured to undertake the noted derivation, for instance using at least one processor). In one embodiment, the broker includes a front end and a back end. Service requests may be received over the network by a given broker at its front end, and received service requests may be routed over the network by a given broker from its back end. In any case, the sum of optimized weights that are derived for a weighted distribution to be used by a broker in routing service requests over the network may be equal to “1.” Service requests that are routed by a broker each may be in the form of at least one transmission of one or more data packets including destination or address information (e.g., an IP address).
A broker may use price information on service providers within its corresponding service provider set to derive the optimized weights for these service providers. This price information may be calculated by a broker (e.g., using at least one processor). In one embodiment, a broker may receive status information (e.g., over the network) on each service provider within its corresponding service provider set. Status information on each service provider may be based upon a relationship between a maximum number of connections for a given service provider and a number of busy connections for this same service provider. In any case, the price of each service provider in a given service provider set may be calculated (e.g., by the broker, for instance using at least one processor) based upon this status information. In one embodiment, a broker may acquire status information directly from each service provider of its corresponding service provider set (e.g., by a broker issuing a request for status information over the network to each such service provider). In one embodiment, a broker may acquire the noted status information indirectly, for instance by the broker itself generating status information on each service provider of its corresponding service provider set (e.g., using at least one processor) based upon input that the broker acquires from at least one other broker within the same network.
A broker may set a preference for each service provider in its corresponding service provider set These preferences may be based upon a latency of the network. The network latency may be measured in any appropriate manner (e.g., by the broker), and may be measured from the broker to each service provider in its corresponding service provider set. In one embodiment, each preference is inversely proportional to its corresponding measured latency.
Optimized weights for a given weighted distribution may be derived (e.g., using at least one processor) and used by a broker to route service requests over the network. The optimized weights for a given weighted distribution may be updated on any appropriate basis (e.g., the derivation of optimized weights may be repeated on any appropriate basis). One embodiment has the derivation of optimized weights for a given weighted distribution being periodically updated. In any case, a first portion of service requests may be routed over the network by a given broker using a first weighted distribution (e.g., a first derivation of optimized weights that defines the first weighted distribution), and a second weighted distribution (e.g., from a subsequent-in-time derivation of optimized weights to define the second weighted distribution) may be used by this same broker to route a second portion of service requests over the network (e.g., the second portion being “later received” in relation to the first portion).
The routing of service requests from a broker, over the network, and using its corresponding weighted distribution may include transmitting each received service request to a particular service provider within its corresponding service provider set on the network. Service requests may be transmitted from a broker to a particular service provider within its corresponding service provider set on the network. In one embodiment, the optimized weights of a weighted distribution for a given broker are converted into a cumulative probability mass function, and service requests received by this broker are routed by the broker over the network using this cumulative probability mass function (e.g., a routed service request from a broker having associated destination/address information, for instance an IP address).
Multiple brokers may be utilized (e.g., a broker set) to distribute service requests over the network, each of which may be configured/operated in accordance with the foregoing. For instance, each of these brokers may derive their own weighted distribution (an optimized weight for each service provider in its corresponding service provider set, for instance using at least one processor) using temporally independent status information on each service provider within its corresponding service provider set. “Temporally independent status information” may be characterized as the optimized weights for each of the brokers in the broker set not needing to be based upon status information from the same point in time. In any case, service requests received by a given broker over the network may then be routed over the network by the broker based upon its corresponding weighted distribution.
The noted broker set may be characterized as collectively functioning as a reverse proxy server for distributing service requests to service providers on the network. Although multiple brokers may be utilized, each broker may operate/function autonomously. How a given broker in a broker set allocates service requests need not be dependent upon how any other brokers in the same broker set allocates service requests. As such, a particular broker in a broker set being unavailable in any respect should not preclude the remaining brokers in the broker set from continuing to allocate/distribute service requests.
Service requests may be transmitted to a given broker in any appropriate manner, for instance over the network and which may be of any appropriate type (e.g., the Internet; a public cloud; a private cloud). A service request may be associated with a user or service requester, and may be transmitted to a broker using a computer of any appropriate type (e.g., a desktop computer; a laptop computer; a tablet computer; a smart phone). Service requests may be in any appropriate form, for instance in the form of a computer-generated data packet(s) that is transmitted over an appropriate communication link to a broker.
Service requests may be sent from a given broker (e.g., to a service provider) in any appropriate manner, for instance over the network and which may be of any appropriate type (e.g., the Internet; public cloud; a private cloud). Each service provider in the service provider set for a given broker may be of any appropriate type, for instance in the form of a Web server. Service requests may be issued by a broker in any appropriate form, for instance as at least one transmission of one or more data packets including destination or address information (e.g., an IP address) and which may be sent on a communication link of any appropriate type.
At least one broker is used in relation to the present invention. As noted, the present invention may be in the form of how service requests are allocated/distributed using such a broker. However, the present invention may also be in the form of a broker that is configured to allocate/distribute service requests in the above-noted manner. For instance, a given broker may include a data processing system (e.g., one or more processors that are arranged in any appropriate manner and that use any appropriate processing architecture) and memory of any appropriate type or types (e.g., one or more data storage devices of any appropriate type and arranged in any appropriate data storage architecture). This data processing system may be configured to derive optimized weights for each service provider in its corresponding service provider set in accordance with the foregoing. One or more communication ports of any appropriate type may be used by a given broker to receive service requests. One more communication ports of any appropriate type may be used by a given broker to transmit service requests in accordance with its own weighted distribution.
Any feature of any other various aspects of the present invention that is intended to be limited to a “singular” context or the like will be clearly set forth herein by terms such as “only,” “single,” “limited to,” or the like. Merely introducing a feature in accordance with commonly accepted antecedent basis practice does not limit the corresponding feature to the singular (e.g., indicating that the present invention utilizes “a broker” alone does not mean that the present invention utilizes only a single broker). Moreover, any failure to use phrases such as “at least one” also does not limit the corresponding feature to the singular (e.g., indicating that the present invention utilizes “a broker” alone does not mean that the present invention utilizes only a single broker). Use of the phrase “at least generally” or the like in relation to a particular feature encompasses the corresponding characteristic and insubstantial variations thereof. Finally, a reference of a feature in conjunction with the phrase “in one embodiment” does not limit the use of the feature to a single embodiment.
The disclosure relates to a system and method for distributing/allocating service requests, preferably on a decentralized basis. A resource allocation technique and its implementation may be used to eliminate a single point of failure in reverse proxying. A reverse proxy function is provided to multiple service providers by a collection of multiple brokers (e.g., reverse proxy load balancers) in a distributed system. Incoming requests are received from service requesters at multiple brokers where they are routed to multiple service providers for processing. All service requests originate with service requesters or users (e.g., a person accessing the distributed system via a web browser or a computer system requesting processing from the distributed system). Service provider capacity and service provider utilization may be acquired to facilitate a price calculation for each service provider. In turn, each broker optimization problem may be optimized such that service requests may be distributed/allocated on a decentralized basis.
A service requester 120 may access the broker set 100 in any appropriate manner, for instance using a computer of any appropriate type (e.g., a desktop computer; a laptop computer; a tablet computer; a smart phone). Any appropriate number of service requesters 120 may be part of the network 50 at any given time. It should be appreciated that a given service requester 120 may be part of the network 50 on a full-time basis or only on a part-time basis (e.g., when there is an active communication link 140 between a given service requester 120 and the broker set 100).
The broker set 100 may collectively function as a reverse proxy server for distributing service requests to service providers 130. One or more brokers 110 may define the broker set 100. Any appropriate number of brokers 110 may be utilized by the broker set 100. A service request from any service requester 120 may be transmitted over the network 50 to any broker 110 within the broker set 100 on any appropriate basis.
The brokers 110 in the broker set 100 may operate/function autonomously—how a given broker 110 allocates service requests need not be dependent upon how other brokers 110 in the broker set 100 are allocating service requests. The network 50 may be configured such that a broker 110 becoming unavailable does not preclude other brokers 110 from continuing to allocate/distribute service requests. The “side” of a given broker 110 that communicates with the service requesters 120 may be referred to as the “front end.” The “side” of a given broker 110 that communicates with its service provider set 135 may be referred to as the “back end.”
The service provider set 135 may be defined by a plurality of service providers 130. The plurality of service providers 130 within a given service provider set 135 may be associated with a common entity. For instance, a service provider set 135 may be characterized as a Web site having a plurality of servers or service providers 130 (e.g., each service provider 130 may be in the form of a Web server (e.g., actual or virtual)). Any appropriate number of service providers 130 may define a given service provider set 135. A given service provider 130 could be a member of one or more service provider sets 135.
Each broker 110 in the broker set 100 may be associated with the same service provider set 135, although such may not be required in all instances. A given broker 110 may be associated with one service provider set 135, while another broker 110 may be associated with a different service provider set 135. These different service provider sets 135 may entail having no common or overlapping service providers 130, or these different service provider sets 135 could have at least some overlap in service providers 130 (e.g., a given service provider 130 could be in two or more service provider sets 135).
Each service provider 130 within the service provider set 135 is assigned what may be characterized as an “optimized weight” by each broker 110. The optimized weights for each of the service providers 130 within the service provider set 135 collectively define a weighted distribution on a broker 110-by-broker 110 basis. That is, the optimized weights for each of the service providers 130 for one broker 110 need not be, and may not be, of the same value in relation to the weights assigned by another of the brokers 110 to these same service providers 130. In one embodiment, the sum of the optimized weights for each of the service providers 130 within a service provider set 135 for a given broker 110 is equal to “1.”
Each broker 110 may update its set of optimized weights on any appropriate basis (e.g., periodically; in accordance with an algorithm; on some timed basis). In the event that the set of optimized weights associated with a given broker 110 are due for an update, the protocol 150 proceeds from step 152 to step 160. Step 160 is directed to acquiring status information on each service provider 130 of the service provider set 135 for the particular broker 110. Status information on a particular service provider 130 may relate to the capacity of this particular service provider 130 and the demand for this particular service provider 130. For instance, the status information for a particular service provider 130 may be the number of connections or threads to the service provider 130 that are currently available for communicating with the service provider 130 (e.g., the differential between the maximum number of connections or threads for the service provider 130, minus the number of busy connections or threads (e.g., those connections or threads that are currently being utilized to communicate with the service provider 130)). The capacity of a particular service provider 130 may refer to the advertised capacity or the true capacity of the service provider 130. The advertised capacity denotes a set point where higher utilization of the service provider will result in an increase in price for that service provider as opposed to a failure within the system. True capacity represents a hard limit on the service provider such that increase in utilization above that limit would result in a failure. The capacity of a service provider 130, as referred to herein, is the advertised capacity.
Status information on each service provider 130 within a service provider set 135 may be acquired by a broker 110 on any appropriate basis. For instance, a broker 110 could request status information directly from each service provider 130 within its corresponding service provider set 135 (e.g., in the manner discussed below in relation to the status acquiring protocol 200 of
Each broker 110 will calculate a price (e.g., using at least one processor) for each service provider 130 within its service provider weight set 135 (step 162) using the status information acquired pursuant to step 160. This will be discussed in more detail below. Optimized weights for each service provider 130 (one weight per service provider 130) are derived by each broker 110 (step 164) using the price data acquired pursuant to step 162. This will be discussed in more detail below. In one embodiment, the derivation associated with step 164 utilizes a non-linear function (discussed below). Step 166 of the protocol 150 is directed to assigning the optimized weights from step 164 to what is now an updated or current service provider weight set for the given broker 110.
With the service provider weight set being current, the protocol 150 of
Each broker 110 may execute the protocol 150 of
If the service provider 130 is not a multi-threaded service provider, the status acquiring protocol 200 may proceed to step 225. Step 225 of the status acquiring protocol 200 is directed to, for a given service provider 130 of the service provider set 135, acquiring the maximum number of concurrent connections to that service provider 130. In other words, in this example, the capacity of the service provider 130 may be acquired based on the maximum number of concurrent connections that the service provider 130 can support. The number of concurrent connections may be the total number of connections that can simultaneously be processed by the service provider 130 without queuing. After the capacity of the service provider 130 is acquired for that service provider 130, the status acquiring protocol 200 may proceed to step 230. Step 230 is directed to acquiring the current number of active concurrent connections to that same given service provider 130. In other words, the flow of the service provider 130 may be acquired based on the current measure of the utilization of that service provider 130 defined in the measure of the service provider 130.
If it is determined in step 210 that the service provider 130 is a multi-threaded service provider 130, the status acquiring protocol 200 may proceed from step 210 to step 215. Step 215 of the status acquiring protocol 200 is directed to, for a given service provider 130, acquiring the number of active threads and a portion of threads that may be activated as needed. For example, the capacity of the service provider 130 may be acquired based on not only the total number of active threads, but also those threads that may be run but have not yet been created (e.g., the capacity may be based on the maximum number of threads that may be activated). After the capacity of the status provider 130 is acquired for that service provider 130, the status acquiring protocol 200 may proceed to step 220. Step 220 is directed to acquiring the number of current busy threads for that same given service provider 130. In other words, the flow of the service provider 130 may be acquired based on the count of the number of busy threads on that service provider 130.
The acquiring step for each of steps 215, 220, 225, and 230 of the status acquiring protocol 200 (
In either case of a multi-threaded service provider 130 or a single threaded service provider 130, after the capacity of the service provider 130 and the flow of the service provider 130 has been acquired by a broker 110, the status acquiring protocol 200 proceeds to step 235. For purposes of step 235, status information (e.g., capacity and flow of the service provider 130) may be considered to be acquired by either receiving a response to a request for status information or setting the default status of the service provider 130. Step 235 is directed to determining whether status information has been acquired from each service provider 130 of the service provider set 135. If status information has not been acquired from each service provider 130 of the service provider set 135, status acquiring protocol 200 proceeds to and repeats steps 210, 225, 230 (e.g., for a single threaded service provider), 215, 220 (e.g., for a multi-threaded service provider) for each service provider 130 of the service provider set 135. In other words, broker 110 acquires status information from each service provider 130 of the service provider set 135. If status information has been acquired from each service provider 130 of the service provider set 135, status acquiring protocol 200 proceeds to step 240. Step 240 is directed to formulating a non-linear programming problem (e.g., the local optimization problem that each broker 110 may solve in a reasonable time to enable the collection/set of brokers 100 to produce a solution that tracks a globally optimal solution). In other words, the non-linear programming problem is expressed as a non-linear equation/function and optimized weights are chosen (e.g., using at least one processor) for each service provider 130 so that the non-linear equation/function is optimized, which will be discussed in detail below.
After a request for the number of active connections to a given service provider 130 of its corresponding service provider set 135 has been sent over the network 50 to each broker 110 of the broker set 100, the status acquiring protocol 250 may proceed to step 260. Step 260 of the status acquiring protocol 250 is directed to the requesting broker 110 summing the count of the number of active connections obtained from each broker 110 in the broker set 100. By summing the count of the number of active connections obtained from each broker 110 in the broker set 100, the requesting broker 110 can estimate/calculate (e.g., using at least one processor) the number of concurrent connections open to that given service provider 130. As such, the requesting broker 110 can acquire the total current number of concurrent open connections to that service provider 130. After the requesting broker 110 has acquired the number of active connections to a given service provider 130 from each broker 110 in the broker set 100, the status acquiring protocol 250 may proceed to step 265. Step 265 is directed to determining whether the number of active connections for each service provider 130 of its corresponding service provider set 135 has been obtained. In other words, the requesting broker 110 requests status information from each broker 110 of the broker set 100 for each service provider 130 of its corresponding service provider set 135. In this regard, if the number of active connections for each service provider 130 in its corresponding service provider set 135 has not been obtained by the requesting broker 110, steps 255, 260, and 265 are repeated until the requesting broker 110 requests status information from each broker 110 of the broker set 100 for each service provider 130 of its corresponding service provider set 135. If the number of active connections for each service provider 130 in its corresponding service provider set 135 has been obtained by the requesting broker 110, status acquiring protocol 250 proceeds to step 270. Step 270 is directed to formulating a non-linear programming problem (e.g., the local optimization problem that each broker 110 may solve in a reasonable time to enable the collection/set of brokers 100 to produce a solution that tracks a globally optimal solution). In other words, the non-linear programming problem is expressed as a non-linear equation/function and optimized weights are chosen (e.g., using at least one processor) for each service provider 130 so that the non-linear equation/function is optimized, which will be discussed in detail below.
As described above in relation to the service request distribution/allocation protocol 150 of
A constant step-size parameter is applied to each price update, denoted H, whose value must be greater than or equal to 0. The current price, denoted Hp, for each service provider 130 is updated (e.g., using at least one processor) using the following update procedure, where [x]+=max{x, 0}. Let Hpprior denote the previous price for service provider 130, fp denote the current capacity being consumed when the price is updated (e.g., service provider 130 flow as discussed above), and Cp denote the service provider 130 capacity to process requests. As such, the price update equation is given as Hp=[Hpprior−H(Cp−fp)]+. The step-size H determines the magnitude of price updates. That is, if H is too small, then the prices will be slow to react to changes in demand. For example, if price updates are too small and the demand for a service provider 130 is much greater than its capacity, then the price for the service provider 130 may not increase enough to cause a broker 110 to discontinue sending service requests to the highly demanded service provider 130. Alternatively, the step-size H should be large enough to enable the system/network 50 to react to substantial changes in demand (e.g., step-size H must be large enough to cause a sufficient increase in price that will deter recurrent excessive demand for that service provider 130).
As discussed above in relation to service request distribution/allocation protocol 150 of
Σp[ln(Tbpebp)−Hpebp], subject to ρpebp=1 and ∀p, ebp≧0, where:
The preference for each service provider 130 may be based on current network latencies from each broker 110 to each service provider 130. Each broker 110 may periodically measure the network latency from the broker 110 to each service provider 130. The preference for each service provider 130 may be inversely proportional to the measured latency from the broker 110 to the service provider 130. In this regard, each broker 110 may set preferences such that the preferred service provider 130 is the network closest service provider 130 that offers the smallest network latency. For example, a higher preference may be assigned to a service provider 130 that is deployed to the same cloud provider as the broker 110 setting the preference and that has the smallest measured network latency from the broker 110 to the service provider 130. As illustrated above in the non-linear equation, the preference will influence the derivation of optimized weights, but the actual distribution of service requests to service providers 130 may be determined by optimizing the non-linear equation given above (e.g., deriving and assigning the derived optimized weights to each service provider 130 of the service provider set 135).
As can be seen from the above non-linear equation, optimizing the distribution of service requests (e.g., maximizing the non-linear equation) is dependent on the prices obtained from each service provider 130 and information that is locally available to each broker 110 (e.g., setting a preference). As such, deriving optimized weights for each broker 110 does not require detailed knowledge of the optimized weights for the other brokers 110 within the broker set 100. Detailed knowledge of the optimized weights for the other brokers 110 within the broker set 100 is instead replaced by a collection of prices for the service provider 130 in the service provider set 135, where each price reflects the current demand for the capacity of each service provider 130 in the service provider set 135.
As discussed above in relation to the service request distribution/allocation protocol 150 of
In a first example, when a new service request has been received by a broker 110, a random number 305 may be generated. In this example, the generated random number 305 is 0.37. As such, the broker 110 determines if weight 322 is greater than or equal to random number 305. If weight 322 is greater than or equal to random number 305, SP1 is selected and the service request is transmitted to SP1. If weight 322 is not greater than or equal to random number 305, weight 322 is added with weight 324, and it is determined if the sum of weights 322 and 324 is greater than or equal to random number 305. If the sum of weights 322 and 324 is greater than or equal to random number 305, SP2 is selected and the service request is transmitted to SP2. If the sum of weights 322 and 324 is not greater than or equal to random number 305, weights 322, 324, and 326 are summed together. If the sum of weights 322, 324, and 326 is greater than or equal to random number 305, SP3 is selected and the service request is transmitted to SP3. If the sum of weights 322, 324, and 326 is not greater than or equal to random number 305, SP4 is selected by default and the service request is transmitted to SP4. As such, in this first example, since random number 305 is equal to 0.37, SP2 would be selected for transmitting the received service request (e.g., 0.1+0.3=0.4, which is greater than or equal to 0.37).
When a second new service request is received by broker 110, another random number 310 may be generated. In this example, random number 310 is equal to 0.54. As such, SP3 would be selected to receive this second service request. As such, broker 110 would transmit this second service request to SP3. When a third new service request is received by broker 110, another random number 315 may be generated. In this example, random number 315 is equal to 0.68. As such, SP4 would be selected to receive this third service request. As such, broker 110 would transmit this third service request to SP4. This process may be repeated a plurality of times for each service request received at broker 110. When it is determined that the set of optimized weights associated with a given broker 110 require updating, steps 160, 162, 164, and 166 of the service request distribution/allocation protocol 150 of
As discussed above, at each instant in time, each broker 110 in the broker set 100 may have a different representation of each of the capacity and flow, and subsequently the price, values. As such, each broker 110 in the broker set 100 may operate autonomously relative to the other brokers 110 in the broker set 100. In turn, an agent that synchronizes the capacity, flow, and price values across all brokers 110 is not needed on any service provider 130.
The storage unit 410 may be memory of the data processing system 400. For example, the storage unit 410 may store information on a temporary or permanent basis. The storage unit 410 may include read-only memory (ROM) (e.g., PROM, EPROM, EEPROM, EAROM, Flash memory) or read-write memory (e.g., random access memory, hard disk drive, solid state drive), to name a few. The storage unit 410 may be in communication with the input unit 405, the output unit 420, and/or the processing unit 415. For example, the storage unit 410 may receive data/information from the input unit 405 and may send data/information to the output unit 420. The storage unit 410 may send data/information to the processing unit 415 for processing. For example, the storage unit 410 may receive status information from the input unit 405 and may subsequently send the status information to the processing unit 415 for processing. In this regard, the processing unit 415 may include instructions (e.g., computer code) for processing data/information.
In one example, the processing unit 415 is in the form of a central processing unit (CPU) (e.g., one or more processors disposed in any appropriate processing architecture). The processing unit 415 may include instructions of a computer program, for example, for performing arithmetical, logical, and/or input/output operations of the data processing system 400. For example, when the processing unit 415 receives status information on each service provider 130 of the service provider set 135, the processing unit 415 may include instructions for calculating a price for each service provider set (step 162 of protocol 150 of
The output unit 420 may be in communication with the storage unit 410, the processing unit 415 and/or one or more output ports (not illustrated). For example, the output unit 420 may receive data from the storage unit 410 for transmitting to another device (e.g., service provider 130). In another example, the processing unit 415 may communicate an instruction to the output unit 420. The output unit 420 may be part of the processing unit 415. The output unit 420 may include instructions and/or logic for performing output functions. For example, the output unit 420 may transmit a request for service to a service provider 130, as described above.
The data processing system 400 may include one or more input units 405, storage units 410, processing units 415, and output units 420 and each of the input units 405, storage units 410, processing units 415, and output units 420 may be located at the same location or may be located at different location relative to one another such that service requests are distributed/allocated preferably on a decentralized basis.
The foregoing description of the present invention has been presented for purposes of illustration and description. Furthermore, the description is not intended to limit the invention to the form disclosed herein. Consequently, variations and modifications commensurate with the above teachings, and skill and knowledge of the relevant art, are within the scope of the present invention. The embodiments described hereinabove are further intended to explain best modes known of practicing the invention and to enable others skilled in the art to utilize the invention in such, or other embodiments and with various modifications required by the particular application(s) or use(s) of the present invention. It is intended that the appended claims be construed to include alternative embodiments to the extent permitted by the prior art.
This patent application is a non-provisional patent application of, and claims priority to, pending U.S. Provisional Patent Application Ser. No. 61/654,992 that is entitled “DECENTRALIZED RESOURCE ALLOCATION,” that was filed on Jun. 4, 2012, and the entire disclosure of which is hereby incorporated by reference in its entirety herein.
| Number | Date | Country | |
|---|---|---|---|
| 61654992 | Jun 2012 | US |
