Dynamic resource reallocation

[0002] The present invention relates to messaging systems and, in particular, to allocation of resource usage to various applications in a messaging system.

[0003] Voice messaging systems are common in today's business community. Most business organizations or enterprises make use of a private branch exchange (PBX) to direct a caller's telephone call to the appropriate extension of the called party. If the called party is unable to answer the telephone call, the telephone call is forwarded to a voice messaging system, which allows the caller to leave a voice message in the mailbox assigned to the called party. Messages left for called parties within the business organization can be retrieved from memory by calling the voice messaging system using a telephone and entering appropriate commands via a touch-tone keypad. Retrieved messages can be played, forwarded or deleted. An example of a voice messaging system of this nature is the Series 6 sold by Mitel Corporation of Ottawa, Ontario, Canada.

[0004] In addition to voice messages, communications within business organizations are also stored in facsimile and text formats. In the past, separate messaging systems have been used to handle these different types of communications. Unfortunately, prior art messaging systems designed to handle one type of communication have not provided any means to interact with messaging systems handling other types of communications. This has required users to access each messaging system individually to retrieve messages and has required business organizations to maintain and manage multiple messaging systems separately. As a result, it has been necessary to establish separate accounts, address lists and message mailboxes in each messaging system for the various users in the business organizations.

[0005] More recently, attempts have been made to interconnect different messaging systems to provide access to different types of messages from a single point. For example, U.S. Pat. No. 5,349,636 to Irribarren discloses a system and method for voice mail systems and interactive voice response (IVR) systems. The Irribarren system includes a voice message system and a text message system integrated via a network, which coordinates the functions of each individual message system. A user may access messages stored in the voice message system and in the text message system via a single telephone call. Although this system allows access to different types of messages, the voice message and text message systems require separate management.

[0006] The current trend is to integrate these various messaging systems to allow users to access all types of communications once a connection is made to the messaging system. To that end, unified messaging systems have been developed to provide users access to virtually all of their communications. Messaging systems of this nature store all messages for entities within the enterprise at a common location. The entities may be individuals, groups, departments, or any appropriate logical organizations. Users accessing the messaging system via a telephone, desktop computer or other communication device have access to all of their messages regardless of message type and regardless of the type of communication device used to access the messaging system. Appropriate message translators such as text-to-speech (TTS) converters, speech-to-text (SST) converters etc. are included to enable users to retrieve messages stored in formats not supported by the communication devices used to access the messaging system.

[0007] Unified messaging systems include both incoming (messaging, auto-attendant, etc.) and outgoing (paging, fax delivery, call-me, etc.) applications. These incoming and outgoing applications run either on separate or shared ports or resources. Using separate ports for applications does not make particularly good use of available hardware but guarantees resource availability. Using shared ports, makes good use of available hardware but does not provide for guaranteed resource availability. Typically, the administrator of the messaging system statically assigns separate and shared ports to the applications within the messaging system based on a traffic model for the messaging system. Unfortunately, statically assigning ports to the applications can lead to a number of problems depending on traffic.

[0008] Consider a case of an eight (8) port messaging system having four ports dedicated to handle only incoming calls, two shared ports capable of handling any application, and two shared ports dedicated to handle only outgoing applications. The two shared ports and two outgoing application ports provide four ports for fax resources, which are available on a first-come, first-served basis. With this static port allocation, a number of problems can arise depending on traffic. If, for example, a large number of fax and page delivery jobs are pending and if two ports are being used by an outgoing application such as call-me and one port is being used for normal messaging, then only two ports are available to handle the fax and page delivery jobs even though three of the incoming call ports are idle. As another example, if there are no fax or page delivery jobs pending but six of the ports are being used for normal messaging, the two outgoing application ports will be available to handle any upcoming fax or page delivery jobs. Hence, a caller to the messaging system will get a busy tone since no ports are available to handle the incoming call even though the two outgoing application ports are idle. As will be appreciated, statically assigning ports to applications can lead to poor resource allocation especially if unexpected traffic situations arise.

[0009] Thus, there is a need for improvements to resource allocation in messaging systems.

[0010] The present invention provides improved resource allocation to applications of a messaging system. By monitoring the messaging system, resource allocation to applications can be performed dynamically so that better and more effective utilization of the resource can be had. The improved resource allocation leads to more responsive servicing of applications (e.g., incoming and outgoing applications) by the messaging system.

[0011] According to one aspect of the present invention there is provided a resource allocation manager to allocate resources to handle applications in a messaging system. The resource allocation manager includes: a database storing a set of resource allocation rules to govern the allocation of resources to applications; a resource allocation engine responsive to events that potentially effect the manner in which the resources are allocated, the resource allocation engine accessing the database and interpreting the resource allocation rules in response to events to determine if the events warrant a reallocation of the resources to applications; and allocation agents responsive to the resource allocation engine and reallocating the resources to applications when detected events warrant a reallocation of the resources.

[0012] In one embodiment, the resource allocation manager further comprises a plurality of event detection agents to monitor the messaging system to detect the events and to communicate the events to the resource allocation engine. The event detection agents include a traffic level agent to detect traffic levels. The event detection agents can also include a system clock agent to detect particular times of the day, which is useful for detecting traffic peak periods and non-peak periods or business and non-business hours.

[0013] According to another aspect of the present invention there is provided a method for allocating resources to handle applications in a messaging system. The method includes the operations of: establishing a set of resource allocation rules to govern the allocation of the resources to applications; monitoring the messaging system to detect events that potentially effect the manner in which the resources are allocated; accessing the resource allocation rules in response to the detected events to determine if the detected events warrant a reallocation of the resources to handle applications; and reallocating the resources to handle applications in accordance with the resource allocation rules if the detected events warrant a reallocation of resources.

[0014] According to another aspect of the present invention there is provided a computer readable medium including computer code for allocating resources of a messaging system to handle applications in the messaging system. The computer readable medium includes: computer program code for accessing a set of resource allocation rules that govern allocation of the resources to applications in the messaging system; computer program code for monitoring of the messaging system to detect events that potentially effect the manner in which the resources are allocated; computer program code for determining whether the detected events trigger a reallocation of the resources to handle applications based on the resource allocation rules; and computer program code for reallocating the resources to handle applications when the computer program code for determining triggers the reallocation.

[0015] The present invention provides advantages in that resources are allocated to applications dynamically to accommodate changes in messaging system requirements. As a result, situations where some resources are idle yet at the same time resources are unavailable to handle other applications, occur to a lesser extent than in conventional messaging systems implementing a static resource allocation methodology. In high capacity messaging systems, a rules-based approach for allocating resources to applications provides for the reallocation of a significant number of resources in an intelligent manner.

[0016] An embodiment of the present invention will now be described more fully with reference to the accompanying drawings in which:

[0017] FIG. 1 is a schematic drawing of a resource allocation manager in accordance with the present invention; and

[0018] FIG. 2 is a representative use case showing traffic related resource reallocation.

[0019] The present invention relates to a messaging system including a resource allocation manager to allocate resources dynamically to applications. The present invention can be implemented in virtually any type of messaging system where applications are allocated resources such as voice messaging systems, interactive voice response (IVR) systems, voice and text messaging systems, and unified messaging systems.

[0020] Turning now to FIG. 1, a resource allocation manager 10 for a messaging system is shown. As can be seen, the resource allocation manager 10 includes a resource allocation engine 12. The resource allocation manager 10 can, for example, run on an allocation server. The resource allocation engine 12 is responsive to trigger events of interest generated by trigger event agents 14 and communicates with a rules database 16. The rules database 16 stores resource allocation rules. The resource allocation engine 12 also communicates with a plurality of allocation agents 26. Each allocation agent 26 is associated with a respective port of the messaging system. The allocation agents 26 assign ports to applications within the messaging system in response to resource allocation directives 28 generated by the resource allocation engine 12. The resource allocation directives 28 may be of the interrupting or non-interrupting type. A non-interrupting directive takes effect after completion of a current task or immediately if no task is in progress. An interrupting directive takes effect immediately regardless of the resource status.

[0021] The resource allocation rules stored in the rules database 16 determine how ports are to be allocated to handle applications and are typically specified by a messaging system administrator based on the site requirements and traffic patterns. The resource allocation rules may include application usage restrictions based on time of day, application type, call traffic etc. As will be appreciated, message traffic in a messaging system is unpredictable. For example, a large number of incoming faxes and telephone calls may occur at the same time requiring more ports than are currently allocated to handle this type of traffic. As a result, it may be necessary to allocate more ports capable of handling incoming applications to deal with the unexpected traffic. By using the resource allocation rules, port allocation can be varied based on traffic patterns and on current messaging system traffic. Therefore, if the messaging system is experiencing heavy incoming traffic and there are few incoming application ports available, a predetermined number of shared ports can be reassigned to handle the incoming applications. Likewise, if incoming traffic is low, the shared ports can be re-assigned to allow use by other applications.

[0022] Table 1 below shows rule definitions for a thirty (30) port messaging system having eight (8) facsimile ports.

[0023] In this embodiment, the ports of the messaging system are divided into five groups. Voice ports 1 to 6 and fax ports 1 and 2 form group 1. Voice ports 7 to 12 and fax ports 3 and 4 form group 2. Voice ports 13 to 20 and fax port 5 form group 3. Voice ports 21 and 22 and fax port 6 form group 4. Fax ports 7 and 8 form group 5. Assigned to each group of ports are resource allocation rules. As can be seen, for group 1, the resource allocation rules dedicate the ports to normal messaging for all hours. For group 2, the resource allocation rules dedicate the ports to normal messaging during peak hours only. As a result, at non-peak hours, the ports can be used as needed and therefore, other applications including outgoing applications can be allocated to the ports of group 2. However, during non-peak hours, if messaging traffic is higher than a predetermined threshold n, then the ports are dedicated to normal messaging. For group 3, regardless of the time of day, if messaging traffic is higher than the predetermined threshold n, the resource allocation rules dedicate the ports to normal messaging. Otherwise, the ports are used as needed. For group 4, the resource allocation rules dedicate the ports to outgoing applications only. For group 5, the resource allocation rules dedicate the ports to any application called by VIP class users during business hours. During non-business hours, the ports are used as needed.

[0024] As mentioned above, in order to determine the resource needs of the messaging system, the resource allocation engine 12 responds to trigger events generated by the trigger event agents 14 that effect the manner in which resources are allocated to applications to make better use of messaging system resources. Examples of trigger event agents 14 are shown in FIG. 1 and include a CPU utilization trigger event agent 18, a resource usage trigger event agent 20, a call traffic trigger event agent 22, and a system clock trigger event agent 24.

[0025] The CPU trigger event agent 18 generates CPU trigger events when CPU utilization is not available or not at an optimal rate. The resource usage trigger event agent 20 generates resource usage trigger events when resources are not available to handle applications and it is necessary to re-assign ports to handle the applications. The call traffic trigger event agent 22 generates call traffic events when the amount of incoming or outgoing traffic is higher or lower than a predetermined threshold level. In the case of incoming or outgoing traffic above the threshold level, the call traffic trigger events signify a need for additional port allocation to handle the traffic. In the case of incoming or outgoing traffic below the threshold level, the call traffic trigger events signify additional port availability. The system clock trigger event agent 24 generates system clock trigger events at specific times of the day to signal peak and non-peak hours as well as business and non-business hours.

[0026] During operation, the resource allocation engine 12 awaits receipt of trigger events from the trigger event agents 14. The resource allocation engine 12 in response to the trigger events accesses the rules database 16. Using the trigger events, the resource allocation engine 12 interprets the resource allocation rules and generates resource allocation directives 28. The resource allocation directives 28 are in turn conveyed to the appropriate allocation agents 26. The allocation agents 26 in response to the resource allocation directives 28 condition their associated ports to handle applications specified by the resource allocation rules and satisfy the messaging system requirements. Since the resource allocation engine 12 is responsive to non-traffic related trigger events, traffic level is not the only criteria used to allocate ports.

[0027] Turning now to FIG. 2, an example of reassignment of resource allocation by the resource allocation manager 10 in response to a call traffic trigger event generated during peak hours is illustrated as a representative use case. In this case, high traffic above the threshold level is detected by the call traffic trigger event agent 22. The call traffic trigger event agent 22 in turn generates a call traffic trigger event 30 and conveys the call traffic event to the resource allocation engine 12. When the resource allocation engine 12 receives the call traffic trigger event, the resource allocation engine 12 accesses the resource allocation rules database 16 and checks 32 the resource allocation rules therein. Using the rules in Table 1, the resource allocation engine 12 generates a resource allocation directive 34 for the allocation agents 26 handling the ports of group 3. When the resource allocation agents 26 receive the resource allocation directive 34, they condition 36 their ports so that they become allocated to handle incoming applications. The resource allocation agents 26 also send an acknowledgment 38 to the resource allocation engine 12 confirming the re-assignment of the group 3 ports.

[0028] As will be appreciated, by providing rules governing the allocation of resources to applications based on specified events, resource allocation can be handled intelligently and dynamically to deal with messaging system needs. As a result, situations where resources are unavailable for certain applications while other resources remain idle are avoided. To illustrate the above, consider an eight port messaging system including the present resource allocation manager 10. In this example, the rules database 16 includes resource allocation rules, which specify the following port assignments:

[0029] two voice ports dedicated to handle incoming calls only;

[0030] during peak business hours, six voice ports and two fax ports dedicated to handle messaging applications;

[0031] under heavy messaging traffic conditions, all available voice ports and fax ports dedicated to handle messaging applications; and

[0032] under light incoming messaging traffic, additional voice ports and fax ports allocated to handle outgoing applications depending on the number of pending jobs.

[0033] Consider now the scenario where outside of business hours, a large number of outgoing faxes and page delivery jobs are pending, three ports are being used by outgoing applications and one port is being used by a normal messaging application. In this situation, based on the above resource allocation rules, the resource allocation manager 10 reallocates the two available voice ports and the available fax ports to handle the pending fax and page delivery jobs. Only two of the four voice ports are reallocated since the first resource allocation rule requires that two ports always be dedicated to handle incoming calls.

[0034] Now consider the scenario where there are no outgoing fax or page delivery jobs pending and six ports are being used for incoming applications. In this situation, based on the above resource allocation rules, when higher than normal incoming traffic is detected, the resource allocation manager 10 allocates all of the ports to handle incoming applications minimizing the chance that a caller receives a busy signal.

[0035] Finally, consider the scenario where a number of outgoing fax and page delivery jobs are pending and four ports are being used for fax delivery. Depending on the time of day, the resource allocation manager 10 will handle resource allocation differently. For example, during peak business hours, the resource allocation manager 10 would re-assign only two ports to handle the fax delivery jobs since the second rule specifies that six ports must be dedicated to handle incoming voice calls applications. However, outside of peak hours, the resource allocation manager 10 would re-assign additional ports to handle the fax delivery jobs.

[0036] As will be appreciated, the resource allocation manager 10 allocates resources to applications dynamically to accommodate changes in messaging system requirements. As a result, situations where ports are idle yet resources are unavailable to handle other applications occur to a lesser extent than in conventional messaging systems implementing a static resource allocation methodology. In high capacity messaging systems, the rules-based approach for allocating resources to applications provides for the reallocation of a significant number of resources in an intelligent manner.

[0037] If desired, a learning engine including artificial intelligence may also be included in the resource allocation manager to monitor traffic patterns and resource usage within the messaging system and modify automatically the resource allocation rules over time.

[0038] Although particular trigger event agents are shown in FIG. 1, those of skill in the art will appreciate that these trigger event agents are shown for illustrative purposes. The resource allocation manager 10 may be responsive to more or fewer trigger event agents. Also, although the trigger event agents are described as providing trigger events to the resource allocation engine 12, it should be appreciated that the resource allocation engine can poll the trigger event agents 14 for trigger events. Alternatively, a combination of polling and event based trigger event generation can be used.

[0039] Also, although the resource allocation manager 10 has been described as being used in a messaging system to allocate resources to handle applications, those of skill in the art will appreciate that the resource allocation manager may also be used to limit availability of certain types of resources to users, or classes of users. For example, in order to provide load stabilization, the resource allocation manager could disable/limit certain activities during high incoming traffic loads allowing resources to be allocated to handle more important tasks.

[0040] The invention can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data which can be thereafter be read by a computer system. Examples of the computer readable medium include read-only memory, random-access memory, CD-ROMs, magnetic tape, optical data storage devices. The computer readable medium can also be distributed over a network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

[0041] Although a preferred embodiment of the present invention has been described, those of skill in the art will appreciate that variations and modifications may be made without departing from the spirit and scope thereof as defined by the appended claims.