Method and system for the dynamic allocation of resources based on a multi-phase negotiation mechanism

Abstract

A system and method for the dynamic allocation of resources based on multi-phase negotiation mechanism. A resource allocation decision can be made based on an index value computed by a selection index function. A negotiation process can be performed based on a schedule, a number of resources, and a price of resources. A user requesting a resource for a low priority task can negotiate based on the schedule, the user demanding the resource for a medium priority task can negotiate based on the schedule and/or the number of resources, and filially the user requesting the resource for a high priority job can successfully negotiate based on per unit resource price. The multi-phase negotiation mechanism motivates the users to be cooperative among them and improves a cooperative behavior coefficient and an overall user satisfaction rate.

Description

TECHNICAL FIELD

Embodiments are generally related to resource allocation methods and systems. Embodiments are also related to service sharing and process management applications. Embodiments are additionally related to the allocation of resources based on a multi-phase negotiation mechanism.

BACKGROUND OF THE INVENTION

Resource allocation is utilized in a number of applications and is typically employed to assign available resources in a cost effective manner. Resource allocation may be determined utilizing, for example, algorithms and computer programs applied to a specific domain to automatically and dynamically distribute resources. Resource allocation is useful in a number of areas including, for example, service sharing, shared hosting platforms, and project management.

The project management domain involves the planning, organizing, and securing of resources in order to successfully complete specific project goals and objectives. In project management, resource allocation typically includes the scheduling of activities and resources required while taking into consideration both the resource availability and the project time. Resource allocation can thus involve the use of a large number of algorithmic solutions to allocate problems.

Demand patterns, however, may undergo permanent or seasonal variations in demand during the life cycle of a process due to changes in, for example, customer and user requirements. Additionally, changes in the execution speed of particular processes may result as process operators become more proficient at their tasks or begin performing new types of tasks. As a consequence, a process may move into a state of sub-optimal performance. Such changes can render the initial resource allocation of project sub-optimal, which can result in below-par performance of the intended process. The actual number of resources required may be higher or lower than the number initially allocated as a part of the project management process.

Conventional models for allocating resources include, for example, an even resource distribution, a highest priority first, a shortest job first, and a first come first serve. Such resource allocation models either focus on a system “fairness” or system throughput measurement. The “fairness” measure (e.g., a fairness index) can be calculated utilizing Jain's fairness index and a max-min ratio. The Jain's fairness index is only efficient for a homogenous user demand (i.e., user having similar demand and equal priority). The max-min ratio mechanism does not lead to precise evaluation of the fairness measure because it considers only the maximum and minimum allocations while computing the fairness measure.

For example, the even resource distribution approach is only efficient for the homogenous user demand so that the resources can be allocated evenly. The fairness measure of the even resource distribution allocation can be computed utilizing the Jain's fairness index as indicated in equation (1) as follows:

$\begin{array}{cc}f\left(x\right)=\frac{{\left[\sum _{i=1}^n{x}_i\right]}^2}{\sum _{i=1}^n{x}_i^2}& \left(1\right)\end{array}$

According to the definition of the Jain's fairness index f(x) ∈ [0,1], where value of 0 implies least fair and value of 1 implies maximum fair. Such fairness model can be applied to the user having similar demand and doesn't yield high system throughput. The highest priority first approach offers a high throughput solution, however, it is not fair in cases where R<<D where R represents total available resources and D is the total demand of all the users. Similarly, the shortest job first approach and the first come first serve algorithm offers partially efficient solutions which are either fair or yield high throughput. Additionally, such prior art models either utilize a price negotiation or a demand negotiation based on single variable such as, for example, number of resources.

Based on the foregoing, it is believed that a need exists for an improved system and method for dynamically allocating resources based on multiphase negotiation mechanism, as will be described in greater detail herein.

BRIEF SUMMARY

The following summary is provided to facilitate an understanding of some of the innovative features unique to the disclosed embodiment and is not intended to be a full description. A full appreciation of the various aspects of the embodiments disclosed herein can be gained by taking the entire specification, claims, drawings, and abstract as a whole.

It is, therefore, one aspect of the disclosed embodiments to provide for an improved process management systems and methods.

It is another aspect of the disclosed embodiments to provide for an improved system and method for dynamically allocating resources based on multi-phase negotiation mechanism.

The aforementioned aspects and other objectives and advantages can now be achieved as described herein. A system and method for the dynamic allocation of resources based on multi-phase negotiation mechanism is disclosed. A resource allocation decision can be rendered based on an index value computed via a selection index function. A negotiation process can be performed based on a schedule, a number of resources, and a price of resources. A user requesting a resource for a low priority task can negotiate based on the schedule, the user demanding the resource for a medium priority task can negotiate based on the schedule and/or the number of resources, and finally the user requesting the resource for a high priority job can successfully negotiate based on per unit resource price. The multi-phase negotiation mechanism motivates the users to be cooperative among them and improves a cooperative behavior coefficient and an overall user satisfaction rate. Such resource allocation approach provides a Pareto optimal solution without implementing market mechanisms and leads to high user satisfaction and retention rates.

The negotiation based on schedule with respect to each user can be performed by considering a selection index, a user demand, and a demand schedule tuple. The user demand schedule represents the number of resources required by the user within a specified time frame. An actual schedule can be analyzed and a new schedule can be offered to satisfy the user demand. The scheduling can be performed based on the selection index value and a higher priority is provided to a higher index value. The value of the total available resources can be determined based on the user demand. The schedule which is closer to the actual schedule of the user is offered by the system in subsequent time steps. If the system is not able to satisfy the demands of the user, then the user with the lowest selection index value can be removed and considered for negotiation based on the number of resources.

The negotiation based on the number of resources can be performed by considering the selection index and the user demand tuple. A reduction factor which determines the percentage reduction in the user requirement can be determined so that the demand of the user can be fulfilled. The value of the reduction factor can be chosen in such a way that a minimum resource allocation quantity is equivalent to a lowest unit of resource. The system enters into an iterative negotiation process with the user, where subsequent iterations offers number of resources closer to an actual user demand. If the system is not able to satisfy the demands of the user, then the user with the lowest selection index value can be removed and considered for negotiation based on the price of resources.

The negotiation based on the price of resources can be performed by considering the selection index and the user demand tuple. A cost factor, which determines the new per unit price of the resource to be allocated to the user, can be set. The value of the cost factor can be increased in each iteration and the process continues until the user demand is equal to the total availability. With the increase in unit price in successive iterations, the user can reduce the demand to 0 (i.e., to quit the negotiation process). The user with low values of the behavior coefficient can be considered as a greedy user and the user with high values are considered as a cooperative user. The greedy users tend to be less flexible in the negotiation process, while cooperative users are more flexible in the negotiation process. As a result, the cooperative users lead to a more efficient resource allocation process and in order to motivate the users to be more cooperative the behavior coefficient value can be assigned to each user depending on the user behavior. The user with higher values of behavior coefficient (i.e., cooperative users) can have higher probability of selection in future interactions, as compared to the user with lower values of behavior coefficient (i.e., greedy users). The multi-phase negotiation provides an efficient solution to the resource allocation problems by increasing the user satisfaction rate. The multi-phase negotiation mechanisms can be implemented by a virtual broker in an ACS marketplace.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying figures, in which like reference numerals refer to identical or functionally-similar elements throughout the separate views and which are incorporated in and form a part of the specification, further illustrate the present invention and, together with the detailed description of the invention, serve to explain the principles of the present invention.

FIG. 1 illustrates a schematic view of a data-processing system, in which disclosed embodiments may be implemented;

FIG. 2 illustrates a schematic view of a software system including a dynamic resource allocation module, an operating system, and a user interface, in accordance with the disclosed embodiments;

FIG. 3 illustrates a block diagram of a dynamic resource allocation system, in accordance with the disclosed embodiments;

FIG. 4 illustrates a high level flow chart of operation illustrating logical operational steps of a method for dynamically allocating resources based on multi-phase negotiation mechanism, in accordance with the disclosed embodiments;

FIGS. 5-6 illustrate a graph depicting data indicative of percentage of satisfied users with respect to various resource allocation approaches, in accordance with the disclosed embodiments; and

FIGS. 7-8 illustrate a graph depicting data indicative of user waiting time with respect to various resource allocation approaches, in accordance with the disclosed embodiments.

DETAILED DESCRIPTION

The particular values and configurations discussed in these non-limiting examples can be varied and are cited merely to illustrate at least one embodiment and are not intended to limit the scope thereof.

The embodiments will now be described more fully hereinafter with reference to the accompanying drawings, in which illustrative embodiments of the invention are shown. The embodiments disclosed herein can be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

As will be appreciated by one skilled in the art, the present invention can be embodied as a method, data processing system, or computer program product. Accordingly, the present invention may take the form of an entire hardware embodiment, an entire software embodiment or an embodiment combining software and hardware aspects all generally referred to herein as a “circuit” or “module.” Furthermore, the present invention may take the form of a computer program product on a computer-usable storage medium having computer-usable program code embodied in the medium. Any suitable computer readable medium may be utilized including hard disks, USB flash drives, DVDs, CD-ROMs, optical storage devices, magnetic storage devices, etc.

Computer program code for carrying out operations of the present invention may be written in an object oriented programming language (e.g., java, c++, etc.). The computer program code, however, for carrying out operations of the present invention may also be written in conventional procedural programming languages such as the “c” programming language or in a visually oriented programming environment such as, for example, visual basic.

The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to a user's computer through a local area network (LAN) or a wide area network (WAN), wireless data network e.g., WiFi, WiMax, 802.11x, and cellular network or the connection can be made to an external computer via most third party supported networks (e.g. through the Internet via an internet service provider).

The embodiments are described at least in part herein with reference to flowchart illustrations and/or block diagrams of methods, systems, and computer program products and data structures according to embodiments of the invention. It will be understood that each block of the illustrations, and combinations of blocks, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function/act specified in the block or blocks.

The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the block or blocks.

FIGS. 1-2 are provided as exemplary diagrams of data-processing environments in which embodiments of the present invention may be implemented. It should be appreciated that FIGS. 1-2 are only exemplary and are not intended to assert or imply any limitation with regard to the environments in which aspects or embodiments of the disclosed embodiments may be implemented. Many modifications to the depicted environments may be made without departing from the spirit and scope of the disclosed embodiments.

As illustrated in FIG. 1, the disclosed embodiments may be implemented in the context of a data-processing system 100 that can include, for example, a central processor 101, a main memory 102, an input/output controller 103, a keyboard 104, an input device 105 (e.g., a pointing device such as a mouse, track ball, pen device, etc.), a display device 106, a mass storage 107 (e.g., a hard disk), and a USB (universal serial bus) peripheral connection 122. As illustrated, the various components of data-processing system 100 can communicate electronically through a system bus 110 or similar architecture. The system bus 110 may be, for example, a subsystem that transfers data between, for example, computer components within data-processing system 100 or to and from other data-processing devices, components, computers, etc.

FIG. 2 illustrates a computer software system 150 for directing the operation of the data-processing system 100 depicted in FIG. 1. Software application 154, stored in main memory 102 and on mass storage 107, generally includes a kernel or operating system 151 and a shell or interface 153. One or more application programs, such as software application 154, may be “loaded” (i.e., transferred from mass storage 107 into the main memory 102) for execution by the data-processing system 100. The data-processing system 100 receives user commands and data through user interface 153; these inputs may then be acted upon by the data-processing system 100 in accordance with instructions from operating system module 151 and/or software application 154.

The following discussion is intended to provide a brief, general description of suitable computing environments in which the system and method may be implemented. Although not required, the disclosed embodiments will be described in the general context of computer-executable instructions such as program modules being executed by a single computer. In most instances, a “module” constitutes a software application.

Generally, program modules include, but are not limited to, routines, subroutines, software applications, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types and instructions. Moreover, those skilled in the art will appreciate that the disclosed method and system may be practiced with other computer system configurations such as, for example, hand-held devices, multi-processor systems, data networks, microprocessor-based or programmable consumer electronics, networked PCs, minicomputers, mainframe computers, servers, and the like.

Note that the term module as utilized herein may refer to a collection of routines and data structures that perform a particular task or implements a particular abstract data type. Modules may be composed of two parts: an interface, which lists the constants, data types, variable, and routines that can be accessed by other modules or routines; and an implementation, which is typically private (accessible only to that module) and which includes source code that actually implements the routines in the module. The term module may also simply refer to an application such as a computer program designed to assist in the performance of a specific task such as word processing, accounting, inventory management, etc.

The interface 153, which is preferably a graphical user interface (GUI), can serve to display results, whereupon a user may supply additional inputs or terminate a particular session. In some embodiments, operating system 151 and interface 153 can be implemented in the context of a “windows” system. It can be appreciated, of course, that other types of systems are possible. For example, rather than a traditional “windows” system, other operation systems such as, for example, a real time operating system (RTOS) more commonly employed in wireless systems may also be employed with respect to operating system 151 and interface 153. The software application 154 can include, for example, a dynamic resource allocation module 152 to constantly adjust the resource allocation based on fairness, throughput, and multi-phase negotiation mechanism. The dynamic resource allocation module 152 can include instructions such as those of method 400 discussed herein with respect to FIG. 4.

FIGS. 1-2 are thus intended as examples and not as architectural limitations of disclosed embodiments. Additionally, such embodiments are not limited to any particular application or computing or data-processing environment. Instead, those skilled in the art will appreciate that the disclosed approach may be advantageously applied to a variety of systems and application software. Moreover, the disclosed embodiments can be embodied on a variety of different computing platforms including Macintosh, Unix, Linux, and the like.

FIG. 3 illustrates a block diagram of a dynamic resource allocation system 300, in accordance with the disclosed embodiments. Note that in FIGS. 1-8, identical or similar blocks are generally indicated by identical reference numerals. The dynamic resource allocation system 300 can be configured to include the dynamic resource allocation module 152 to constantly adjust the resource allocation based on multi-phase negotiation mechanism 360. The multi-phase negotiation mechanism 360 further includes a user behavior computation module 305, a schedule based negotiation module 330, a number of resources based negotiation module 340, and a price based negotiation module 350. A selection index function 315 computes an index value 320 in order to make a resource allocation decision.

The schedule based negotiation module 330 performs negotiation if a user requesting the resources for a low priority task using the selection index function 315, a user demand 325, and a demand schedule 335. The schedule based negotiation module 330 and/or the number of resources based negotiation module 340 performs the negotiation if the user demanding the resources for a medium priority task using the selection index function 315 and the user demand 325. The price based negotiation module 350 performs the negotiation if the user requesting resources for a high priority job utilizing the selection index function 315 and the user demand 325. A user behavior coefficient 310 with respect to a user can be computed to determine the degree of cooperativeness of the user with other users. The value of user behavior coefficient 310 can be updated each time it interacts with the system 300. The resource allocation system 300 provides a Pareto optimal solution without implementing market mechanisms and leads to high user satisfaction and retention rates.

FIG. 4 illustrates a high level flow chart of operation illustrating logical operational steps of a method 400 for dynamically allocating resources based on the multi-phase negotiation mechanism 360, in accordance with the disclosed embodiments. Initially, a resource allocation decision can be made based on an index value computed by a selection index function, as indicated at block 410. For example, consider n users that can be represented as (U₁, U₂ . . . , U_x . . . , U_n) and the corresponding demands at each time step can be represented by ((d₁, d₂ . . . , d_x . . . , d_n)¹, (d₁, d₂ . . . , d_x . . . , d_n)², . . . , (d₁, d₂ . . . , d_x . . . , d_n)^T), wherein T is the total number of time steps. The resource allocation decisions can be made by the system 300 based on the index values 320 computed by the selection index function 315 as shown in equation (2) below:

$\begin{array}{cc}{\mathrm{SI}}^i\left(x\right)=\frac{\begin{array}{c}{\alpha }_f^i\left(1-\frac{w_x}{t}\right)+{\alpha }_{\tau }^{1-i}\left(1-\frac{d_x}{d_{\max }}\right)+\\ {\beta }_x^U\left(t-1\right)+{\beta }_x^P\left(t-1\right)\end{array}{\beta }_x^S\left(t-1\right)+}{2}& \left(2\right)\end{array}$
wherein the term

$\left(1-\frac{w_x}{t}\right)$
introduces the notion of fairness which restricts the system 300 from allocating the resources to same user repetitively and the term

$\left(1-\frac{d_x}{d_{\max }}\right)$
introduces the notion of (high) system throughput. The definitions of symbol used in equation (2) are illustrated in Table 1.

TABLE 1

Symbol   Definition

αf       Fairness coefficient, αf ∈ [0, 1]
αt       Throughput coefficient, αt ∈ [0, 1]
βxS(t-1) Avg. Behavior coefficient value for Ux for 1st negotiation phase,
         at (t-1)th time step
βxU(t-1) Avg. Behavior coefficient value for Ux for 2nd negotiation phase,
         at (t-1)th time step
βxP(t-1) Avg. Behavior coefficient value for Ux for 3rd negotiation phase,
         at (t-1)th time step
wx       Number of times Ux has won in past
t        Current trial number, t ∈ T
T        Total number of trials
dx       Demand of Ux
dmax     Maximum demand of user Ui ∈ U, max {d1, d2 . . . , di . . . , dn}

A negotiation process can then be performed, as depicted at block 420. A user requesting the resources for a low priority task can negotiate based on schedule by considering the selection index function 315, a user demand 325, and a demand schedule 335, as illustrated at block 430. The first phase of negotiation starts with offering new schedule to each user. In this phase of negotiation, the tuple for selection index 315, user demand 325, and demand schedule 335 can be considered as (SI(x), d_x, s_x) wherein SI(_x) represents the selection index value for U_x, d_x represents the corresponding demand of the user, and s_x represents the user's demand schedule. The user's demand schedule can be explained as the number of resources required by a user within a specified time frame. In this step, the system 300 analyzes the actual schedule [(s₁^I, s₂^I . . . , s_x^I . . . , s_n^I)]ⁱ and offers [(s₁^O, s₂^O . . . , s_x^O . . . , s_n^O)]ⁱ as a new schedule, which can satisfy the demands of all users. The scheduling can be done based on the selection index values and higher priority is given to higher Index value. The process is iterative where a new offer can be made at i^th time step if the user hadn't accepted the offer at (t−1)^th time step.

In i^th iteration {m:m≦n} is maximized wherein the users can be represented as [(SI(1), d′₁, s₁^F), (SI(2), d′₂, s₂^F) . . . , (SI(x), d′_x, s_x^F) . . . , (SI(m), d′_m, s_m^F)]_i subject to

$\sum _{i=0}^m{d}_i^{\prime }\le \frac{ℝ*\omega }{100},$
wherein R represents the total available resources, ω represents allocation factor, and d′_i is the new demand of U_i corresponding to s_i^F. The value of ω can be determined according to the user demand, i.e., if the user demand D>>R then the value of ω is more. The user behavior coefficient value for U_x at t^th time step of this negotiation phase is calculated as shown below in equation (3):

$\begin{array}{cc}{\stackrel{.}{\beta }}_x^S\left(t\right)=\frac{s_x^F-s_x^I}{s_x^O-s_x^I}& \left(3\right)\end{array}$

The term {dot over (β)}_x^s(t) represents the user behavior coefficient value for U_x at t^th trial, which can be employed for calculating average value of behavior coefficient for U_x at t^th trial i.e.

${\beta }_x^S\left(t\right)=\frac{\stackrel{t}{\sum _{j=1}}{\stackrel{.}{\beta }}_x^S\left(j\right)}{t}$
can be employed for calculating the selection index value for U_x at (t+1)^th trial. For example, assume the system 300 is able to successfully negotiate with m_s users and the schedule at the end of the phase is {s₁^F, s₂^F . . . , s_x^F . . . , s_m^F} and the users are not considered in the following negotiation phases (i.e. β_x^U(t)=0, β_x^p(t)=0 ∀ x ∈ m_s). Moreover, the behavior coefficient value of remaining (n−m₁S) users for this negotiation phase is 0 i.e. β_x^s(t)=0 ∀ x ∉ m_s. The definitions of symbol used in equation (3) are illustrated in Table 2.

TABLE 2

Symbol Definition

sxI    Original schedule of Ux
sxO    Schedule offered to Ux by system
sxF    Final schedule of Ux after negotiation
ω      Allocation factor decides % age of total resources which could be allocated in this
βxS(t) Avg. behavior coefficient of Ux for 1st phase of negotiation

In subsequent time steps, the system 300 offers schedule which is closer to the actual schedule of the user and if the system is not able to satisfy the demands of all users, then users with the lowest selection index value 320 can be removed from this phase of negotiation and they are considered for negotiation in the next phase, where negotiation is done based on the number of resources 340.

The negotiation can be performed based on schedule and the number of resources by considering the selection index function 315 and the user demand 325 if user demanding resources for medium priority task, as depicted at block 440. The selection index 315 and user demand tuple 325 can be represented as (SI(x),d_x), wherein SI(x) represents selection index value, and d_x represents the corresponding demand of the user.

The reduction factor, γ which determines the percentage reduction in users' requirements, can be determined so that demands of all users (in this phase) can be fulfilled. The value of γ is chosen in such a way that minimum resource allocation quantity is equivalent to lowest unit of resource

$i.e.\underset{1\le x\le n}{\min }\left(d_x^{\prime }\right)=r,$
where d′_x represents new demand of user calculated using reduction factor and r represents lowest unit of resource (to be allocated). So, the resources offered to users in first iteration are

$\left\{\frac{\gamma *d_1}{100},\frac{\gamma *d_2}{100}\dots ,\frac{\gamma *d_x}{100}\dots ,\frac{\gamma *{\stackrel{.}{a}}_m}{100}\right\}.$
It is also an iterative process where a new offer is made at i^th time step if the user did not accept the previous offer at (t−1)^th time step.

In i^th iteration {m:m≦(n−m_s)} is maximized where the users are represented as [(SI(1), d′₁), (SI(2), d′₂) . . . , (SI(x), d′_x) . . . , (SI(n−m_s), d′_(n−mS))]ⁱ subject to

$\sum _{i=o}^m{d}_i^{\prime }\le R,$
wherein R represents total available resources and d′_i is the new demand of U_i calculated using reduction factor. The value of behavior coefficient for U_x at t^th trial is calculated as shown in equation (4) below:

$\begin{array}{cc}{\stackrel{.}{\beta }}_x^U\left(t\right)=\frac{d_x-d_x^{\prime }}{d_x\left(1-\frac{\gamma }{100}\right)}& \left(4\right)\end{array}$

Term {dot over (β)}_x^U(t) represents the user behavior coefficient value for U_x at t^th trial, which is employed for calculating an average value of the behavior coefficient for U_x at t^th trial i.e.

${\beta }_x^U\left(t\right)=\frac{\stackrel{t}{\sum _{j=1}}{\stackrel{.}{\beta }}_x^U\left(j\right)}{t}$
and it is used for calculating the selection index value for U_x at (t+1)^th trial. For example, assume the system 300 is able to successfully negotiate with m_u users and their demand at the end of this phase is {d′₁, d′₂, . . . , d′_x . . . , d′_m} and these users are not considered in next negotiation phase i.e. β_x^p(t)=0 ∀ x ∈ m_U. Moreover, the behavior coefficient value for remaining (n−m₁U) users for this negotiation phase is 0 i.e. β_x^U(t)=0 ∀ x ∉ m_U. The definitions of symbol used in equation (4) are illustrated in Table 3.

TABLE 3

Symbol Definition

dx     Original demand of usr
dx′    Demand of Ux at the end of 2nd phase of negotiation
γ      Reduction factor
βxU(t) User behavior coefficient for 2nd phase of negotiation

The system 300 enters into an iterative negotiation process with users, where subsequent iterations offers number of resources closer to actual user demand. As discussed in the previous phase, if the system 300 is not able to satisfy the demands of all users, then users with the lowest selection index value are removed from this phase of negotiation and they are considered for negotiation in the next phase, where negotiation is done based on price of resources.

Finally, the negotiation can be performed based on per unit resource price by considering the selection index function 315 and the user demand 325 if user requesting resources for high priority task, as indicated at block 450. The next phase of the negotiation process includes negotiating on the basis of price of resources 350. In this phase of negotiation process 350, the selection index 315 and user demand tuple 325 is considered i.e. (SI(x),d_xp_x), wherein SI(x) represents selection index value, d_x represents the corresponding demand of the user, and p_x represents the actual price of the resource. This phase begins with setting δ (i.e., cost factor), which determines the new per unit price of the resource to be allocated to users.

The value of δ is increased in each iteration and this process continues till user demand is equal to total availability. With the increase in unit price in successive iterations, the users can reduce their demand and some can even reduce their demand to 0 (i.e., they quit the negotiation process). For example, assume the value of δ at i^th time step reaches a point, where the reduction of user demand is such that the total user demand becomes lesser than total availability of resources

$i.e.\sum _{i=o}^x{d}_i^{\prime }<R,$
where x is the number of users in negotiation process after i^th time step and R is the total availability of resources. In that case the value of δ is reduced to the value at (t−1)^th time step and higher priority is given to the users with higher values of selection index during resource allocation.

In i^th iteration {m:m≦(n−m_s−m_U)} is maximized where users are represented as [(SI(1), d′₁, p₁), (SI(2), d′₂, p₂) . . . , (SI(x), d′_x, p_x) . . . , (SI(n−m_s−m_U), d′_{(n−ms−mU)}, p_{(n−ms−mU)})]ⁱ subject to

$\sum _{i=o}^m{d}_i^{\prime }\le R,$
wherein R represents the total available resources and d′_i represents the new demand of U_i corresponding to new per unit price. The value of behavior coefficient for U_x in t^th trial is calculated as indicated in equation (5) below:

$\begin{array}{cc}{\stackrel{.}{\beta }}_x^P\left(t\right)=\frac{\delta }{100}*\frac{d_x^{\prime }}{d_x}& \left(5\right)\end{array}$

Term {dot over (β)}_x^p(t) represents user the behavior coefficient value for U_x at t^th trial, which is used for calculating average value of behavior coefficient for U_x at t^th trial i.e.

${\beta }_x^P\left(t\right)=\frac{\stackrel{t}{\sum _{j=1}}{\stackrel{.}{\beta }}_x^P\left(j\right)}{t}$
and it is used for calculating the selection index value for U_x at (t+1)^th trial. For example, assume the system 300 is able to successfully negotiate with m_p users and their demand at the end of this phase is {d′₁,d′₂, . . . , d′_x . . . , d′_m} and the behavior coefficient value for remaining (n−m_p) users is 0 i.e. β_x^p(t)=0 ∀ x ∉ m_p. β_x^U(t)=0 ∀ x ∉ m_U. The definitions of symbol used in equation (5) are illustrated in Table 4.

TABLE 4

Symbol Definition

dx     Original demand of user
dx′    Demand of Ux at the end of 3rd phase of negotiation
δ      Cost factor
βxP(t) User behavior coefficient for 3rd phase of negotiation

The users with low values of the behavior coefficient are considered as greedy users and those with high values are considered as cooperative users. The greedy users tend to be less flexible in the negotiation process, while cooperative users are more flexible in the negotiation process. As a result, cooperative users lead to a more efficient resource allocation process and in order to motivate users to be more cooperative, the behavior coefficient value is assigned to each user depending on the behavior. The users with higher values of behavior coefficient (i.e., cooperative users) can have higher probability of selection in future interactions as compared to users with lower values of behavior coefficient (i.e., greedy users). The multi-phase negotiation mechanism 360 motivates the users to be cooperative among them and improves a cooperative behavior coefficient and an overall user satisfaction rate, as shown at block 460.

The multi-phase negotiation mechanism 360 offers an efficient solution to the resource allocation problems which aims at increasing the user's satisfaction rate. The effectiveness of the multi-phase negotiation mechanism 360 can be tested in scenarios where D>>R, wherein D is total user demand and R is the total resource availability. The multi-phase negotiation mechanism 360 encourages the users to be cooperative among them using one of the three negotiation mechanisms according to their priority of tasks. The resource allocation system 300 increase the user satisfaction rate and motivates the users to be more cooperative among them which results in the overall increase in user's satisfaction rate. The increase in the user satisfaction leads to higher user retention which in turn increases the ACS's revenue.

FIGS. 5-6 illustrate a graph 500 and 600 depicting data indicative of percentage satisfied users, in accordance with the disclosed embodiments. The user satisfaction with respect to the allocation method 400 is compared with different allocation approaches, for example, even distribution 510, highest priority first 520, first come first serve 530, and fair allocation 540. The user satisfaction rate is directly proportional to throughput of an algorithm as higher is the number of satisfied users more is the retention rate. As the user waiting time is inversely proportional to the fairness of an algorithm the lower is the waiting time for the user (for getting a resource) the more is the fairness. The test case scenarios for analyzing the user satisfaction rate and user waiting time in different resource allocation algorithms are illustrated in TABLE 5.

TABLE 5
	#	#	Min.	Max.
Test Case	Resources	Users	Demand/User	Demand/User	# Trials
Case 1	100	50	1	60	100
Case 2	100	50	1	10	100

FIGS. 5-6 illustrate the user satisfaction rates for case 1 and case 2 respectively. The user satisfaction rate in FIG. 6 is more than previous case because the maximum demand of a single user can be 10 and total resource availability is 100. Table 6 shows the average statistics for the user satisfaction rate in the test scenarios.

	TABLE 6
	Avg.	Avg.	%	Avg.	Avg.	%
	Satisfied	Dissatisfied	Satisfied	Satisfied	Dissatisfied	Satisfied
Algorithm	Case 1	Case 2
Even Distribution	1.68	48.32	3.36%	10.65	39.35	21.3%
First Come First	5.54	44.46	11.08%	19.56	30.44	39.12%
Serve
Highest Priority	2.3	47.7	4.6%	11.31	38.69	22.62%
First
Fair Allocation	11.56	38.44	23.12%	28.59	21.41	57.18%
Our Proposed	15.41	34.59	30.82	39.11	10.89	78.22%
Method

The analysis of the satisfaction rates on the basis of above statistics implies that the percentages of satisfied users are more in the allocation method 400 as compared to other approaches. The fairness component of the resource allocation approach 400 i.e.

$\left(1-\frac{w_x}{t}\right)$
accounts for higher user satisfaction rate and at the same time throughput component balances it depending on the value of throughput coefficient, thus achieving optimal fairness and throughput in the resource allocation.

FIGS. 7-8 illustrate graphs 700 and 800, which depict data indicative of user waiting time, in accordance with the disclosed embodiments. Tables 7 and 8 respectivley correspond to Test cases 1 and 2 respectively.

TABLE 7
	Min Wait	Max Wait	Avg. Wait	Std. Dev.
Algorithm	Time	Time	Time	Wait Time
Even Distribution	0	99	26.42	14.69
FCFS	0	99	25.29	21.96
HPF	0	82	19.97	8.72
Fair Allocation	0	24	3.22	0.4
Our Proposed	0	21	2.2	0.28
Method

TABLE 8
	Min Wait	Max Wait	Avg. Wait	Std. Dev.
Algorithm	Time	Time	Time	Wait Time
Even Distribution	0	38	3.68	0.94
FCFS	0	99	28.29	36.76
HPF	0	24	3.47	0.9
Fair Allocation	0	8	0.74	0.09
Our Proposed	0	5	0.28	0.04
Method

The users' waiting time in case of the allocation method 400 is much less than other approaches which implies the resource allocation method 400 is comparatively fairer. The user's waiting time with respect to the allocation method 400 is compared with different allocation approaches, for example, highest priority first 520 and fair allocation 540.

FIGS. 7-8 illustrate the total waiting time for users is lesser in the allocation method 400 as compared to the highest priority first 520 and the fair allocation 540 for both scenarios. This signifies that deviation between users' waiting time in case of the resource allocation method 400 is lesser than traditional resource allocation method 520 and 540 and it guarantees envy free allocation.

It will be appreciated that variations of the above-disclosed and other features and functions, or alternatives thereof, may be desirably combined into many other different systems or applications. Also, that various presently unforeseen or unanticipated alternatives, modifications, variations or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by the following claims.

Claims

1. A computer-implemented method for dynamically allocating resources in a process, said computer-implemented method comprising:

computing, by a user behavior computation module, a behavior coefficient of each user of a plurality of users to determine a degree of cooperativeness of each user with respect to said plurality of other users, wherein each user is associated with a task;

computing, by a selection index function, an index value of each task associated with each user, wherein the index value is based in part on the behavior coefficient of said user of each task;

performing a multi-phase negotiation utilizing negotiation mechanisms in response to a user of the plurality of users requesting a resource for a task including:

a schedule based negotiation mechanism when said index value of said task is low;

a schedule based negotiation mechanism or a number of resources based negotiation when said index value of said task is medium;

a price based negotiation mechanism when said index value of said task is high; and

dynamically allocating said resource based on said behavior coefficient and said multi-phase negotiation.

2. The computer-implemented method of claim 1 further comprising performing said schedule based negotiation mechanism if said request for said resource comprises a request for a low priority task by considering a selection index, said each user demand, and a demand schedule tuple.

3. The computer-implemented method of claim 2 further comprising:

analyzing an actual schedule and offering a new schedule to satisfy said each user demand and provide a higher priority to a higher index value;

determining a total available resource value based on said each user demand; and

removing a user with a lowest selection index value of said plurality of users and thereafter considering said user with said lowest selection index value for said number of resources based negotiation process if said user with said lowest selection index value demand is not satisfied.

4. The computer-implemented method of claim 1 further comprising performing said schedule based negotiation mechanism said number of resources based negotiation mechanism if said request for said resource comprises a request for a medium priority task by considering said selection index and said user demand tuple.

5. The computer-implemented method of claim 4 further comprising:

determining a reduction factor that determines a percentage reduction in said each user requirement in order to fulfill said each user demand wherein said reduction factor value is chosen in such a way that a minimum resource allocation quantity is equivalent to a lowest unit of resource;

entering into an iterative negotiation process with said each user wherein a subsequent iteration offers a number of resources closer to an actual user demand; and

removing a user with said lowest selection index value and thereafter consider said user with said lowest selection index value for said price based negotiation mechanism if said user with said lowest selection index value demand is not satisfied.

6. The computer-implemented method of claim 1 further comprises performing a price based negotiation process if said request for said resource comprises a request for a high priority task by considering said selection index and a user demand tuple.

7. The computer-implemented method of claim 6 further comprising:

setting a cost factor that determines a new per unit price of said resource and thereafter increase said cost factor value in each iteration of said multi-phase negotiation until said each user demand is equal to a total availability; and

considering a user of said plurality of users with a low value of said user behavior coefficient as a greedy user and a user with a high value of said user behavior coefficient as a cooperative user.

8. The computer-implemented method of claim 7 further comprising assigning said user behavior coefficient value to each user of said plurality of users depending on said behavior in order to motivate said each user to be more cooperative for efficiently allocating said resource.

9. The computer-implemented method of claim 7 wherein said cooperative user possesses a higher probability of selection in a future interaction as compared to said greedy user.

10. A system for dynamically allocating resources in a process, said system comprising:

a processor; and

a computer-usable medium embodying computer code, said computer-usable medium being coupled to said data bus, said computer program code comprising instructions executable by said processor and configured for:

computing, by a user behavior computation module, a behavior coefficient of each user of a plurality of users to determine a degree of cooperativeness of said each user with respect to said plurality of users, wherein each user is associated with a task;

computing, by a selection index function, an index value of the task associated with each user, wherein the index value is based in part on the behavior coefficient of said each user of each task;

performing a multi-phase negotiation utilizing negotiation mechanisms in response to a user of the plurality of users requesting resource for a task including:

a schedule based negotiation mechanism when said index value of said task is low;

a schedule based negotiation mechanism or a number or resources based negotiation when said index value of said task is medium;

a price based negotiation mechanism when said index value of said task is high; and

dynamically allocating said resource based on said behavior coefficient and said multi-phase negotiation.

11. The system of claim 10 wherein said instructions are further configured for performing said schedule based negotiation mechanism if said request for said resource comprises a request for a low priority task by considering a selection index, said each user demand, and a demand schedule tuple.

12. The system of claim 11 wherein said instructions are further configured for:

analyzing an actual schedule and offering a new schedule to satisfy said each user demand and provide a higher priority to a higher index value;

determining a total available resource value based on said each user demand; and

removing a user with a lowest selection index value of said plurality of users and thereafter considering said user with said lowest selection index value for said number of resources based negotiation process if said user with said lowest selection index value demand is not satisfied.

13. The system of claim 10 wherein said instructions are further configured for performing said schedule based negotiation mechanism said number of resources based negotiation mechanism if said request for said resource comprises a request for a medium priority task by considering said selection index and said user demand tuple.

14. The system of claim 13 wherein said instructions are further configured for:

determining a reduction factor that determines a percentage reduction in said each user requirement in order to fulfill said each user demand wherein said reduction factor value is chosen in such a way that a minimum resource allocation quantity is equivalent to a lowest unit of resource;

entering into an iterative negotiation process with said each user wherein a subsequent iteration offers a number of resources closer to an actual user demand; and

removing a user with said lowest selection index value and thereafter consider said user with said lowest selection index value for said price based negotiation mechanism if said user with said lowest selection index value demand is not satisfied.

15. A non-transitory processor-readable medium storing code representing instructions to cause a processor to perform a process for dynamically allocating resources in a process, said code comprising code to:

compute, by a user behavior computation module, a behavior coefficient of each user of a plurality of users to determine a degree of cooperativeness of said each user with respect to said plurality of users;

compute, by a selection index function, an index value of the task associated with each user, wherein the index value is based in part on the behavior coefficient of said each user of each task;

perform a multi-phase negotiation utilizing negotiation mechanisms in response to a user of said plurality of users requesting resource for a task including:

a schedule based negotiation mechanism when said index value of said task is low;

a schedule based negotiation mechanism or a number or resources based negotiation when said index value of said task is medium;

a price based negotiation mechanism when said index value of said task is high; and

dynamically allocate said resource in based on said behavior coefficient and said multi-phase negotiation.