Abstract:
A system includes a first interface to connect with a network, and a second interface to connect with a telephone device of an enterprise. A unit controls a connection between the first and second interfaces for an outgoing call from the telephone device to a remote telephone device connected to the network. A processor subsystem coupled with the unit operates to initiate communications with a telephone device associated with a supervisor having authority to allow or deny the call. The processor subsystem also operates too present the supervisor with information that includes a purpose or reason for the outgoing call. It is emphasized that this abstract is provided to comply with the rules requiring an abstract that will allow a searcher or other reader to quickly ascertain the subject matter of the technical disclosure.

Description:
TECHNICAL FIELD 
     The present disclosure relates generally to the fields of telephony and communication systems. 
     BACKGROUND 
     To save money, many business enterprises implement some sort of authorization system to control and/or restrict the placement of telephone calls by their employees. For example, forced authorization codes (FACs), which require a caller to enter a valid authorization code prior to extending calls to classes of dialed number, are commonly used in private branch exchange (PBX) systems to regulate the types of calls that certain users can place (e.g., international calls and external toll calls). In such a system, a user placing a call needs to enter a valid FAC code in order for the call to be extended beyond the PBX. Modern PBX systems typically implement this feature by having an administrator set the FAC codes in the system, and then distribute these codes to selected users that have a legitimate business need to place an international or toll call. 
     One problem with the FAC approach to regulating toll calls is that the authorization rights are statically assigned to users, which, often times, is counter productive. For example, in a large organization or enterprise a number of employees normally have no need to place long distance or international calls as part of their normal work. The system administrator may therefore block or restrict their ability to place these types of calls. Occasionally, however, a blocked employee may need to place such a call in the course of performing their work duties. In such cases, the use of statically assigned FACs does not work very well. That is, the FAC feature in existing PBX systems lacks the flexibility to allow a normally restricted employee (one without access to a valid FAC) to place certain international or toll calls in special situations. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present disclosure will be understood more fully from the detailed description that follows and from the accompanying drawings, which however, should not be taken to limit the invention to the specific embodiments shown, but are for explanation and understanding only. 
         FIG. 1  illustrates an example telephony/communication system. 
         FIG. 2  illustrates an example authorization queue for use in the PBX system shown in  FIG. 1 . 
         FIG. 3  illustrates an example Remote Authorization Mode module shown in  FIG. 1 . 
         FIG. 4  illustrates an example IP telephone device with softkey functions. 
         FIG. 5  illustrates an example display screen of the IP telephone device shown in  FIG. 4 . 
         FIG. 6  is an example detailed block diagram of a PBX system. 
         FIG. 7  illustrates an example graphical user interface (GUI) window for use in authorizing a remote call. 
         FIG. 8  illustrates an example method for third party authorization of a call prior to connecting the call. 
     
    
    
     DETAILED DESCRIPTION 
     In the following description specific details are set forth, such as device types, system configurations, communication methods, etc., in order to provide a thorough understanding of the present invention. However, persons having ordinary skill in the relevant arts will appreciate that these specific details may not be needed to practice the present invention. 
     According to one embodiment, a mechanism is provided for a PBX system that allows persons without access to a valid FAC to dynamically seek the permission from a set of pre-designated supervisors/managers who can authorize (or deny) the call based on information provided regarding the purpose of the call. In other embodiments, the PBX system may generally comprise any communications node capable of the implementing the functions described herein. 
       FIG. 1  illustrates an example telephony/communication system  10  that includes a PBX system  11  that runs a call management software (or firmware) program for implementing call routing, processing and telephony functions. In the embodiment shown, PBX  11  is capable of communicating with other devices over an Internet protocol (IP) network. In other embodiments, PBX  11  comprises a more conventional PBX system that handles calls sent over a conventional public switched telephone network (PSTN). PBX  11  is shown including an authorization queue  13 , a FAC module  12 , and a configurable Remote Authorization Mode (RAM) module  14 . Authorization queue  13  is used to hold or collect calls waiting for authorization by an appropriate supervisor. During the time that the outbound call is in queue  13  or while being reviewed by a supervisor, the call is essentially paused, with no connection being yet made to the destination telephone device addressed by the dialed number. 
     FAC module  12  stores the FACs and associated call route patterns. RAM module  14  associates certain route patterns with particular remote users/supervisors or sets of supervisors that may be contacted to authorize or deny a toll call placed by a person or user from a telephone device  19  within the organization. By way of example,  FIG. 1  shows a set  17  of supervisors  18  that may be contacted by PBX  11  via network  15  for the purpose of authorizing a call for persons who do not have a FAC. Network  15  may comprise an IP network, intranet, PSTN, ISDN, or any other voice/data network capable of communications with PBX  11 . In this example, PBX  11  is also shown connected with an IP network  16 , which may be utilized for communications with a remote user (callee) of telephone device  20 . It is appreciated that other types of networks, such as a PSTN or a cellular wireless network may also be connected with PBX  11 . 
       FIG. 6  is an example detailed block diagram of a PBX system  11  that includes a processor subsystem  51  having one or more processors coupled to a memory  52  (e.g., random-access memory) that may comprise a database containing existing user preferences and/or configuration settings. PBX  11  also includes an IVR unit  57 , hardware/software modules  54 , which may include FAC module  12  and RAM module  14  (see  FIG. 1 ), and a call manager/controller unit  55  that functions to route calls between interfaces  58  &amp;  59  having lines connected to network  15 , IP network  16 , a PSTN, etc., as well as telephone devices of the enterprise (e.g., device  19 , as shown in  FIG. 1 ). Call router/controller unit  55  may also be utilized for communications with callers and the users of the enterprise telephone devices. An example of such communications is the play-out of IVR scripts to a caller during the process of authorizing a remote (e.g., international or toll) call, as described in more detail below. 
     Practitioners in the art will appreciate that modules  54  may be implemented in software, hardware, or firmware components, and, in certain embodiments, may be connected to PBX  11  as separate components, rather than being incorporated within system  11 . 
     In one implementation, IVR unit  57  may comprise a telephony script or a navigation menu module that may prompt a caller to state his identity, client matter number, the purpose or reason for his call, etc., and also to notify a third party supervisor that an outgoing call requires authorization. IVR unit  57  is typically embodied in one or more software or firmware modules with code that executes on one or more processors of subsystem  51 . In other embodiments, IVR unit  57  may include dedicated processors that perform various tasks, such as speech processing, verification, and recognition. It is appreciated that PBX system  11  may also include a variety of other devices (e.g., controllers, EEPROMs, specialized processors, etc.) not shown in  FIG. 6 . 
     Referring again to  FIG. 1 , RAM  14  may be configured for various different communications modes, such as Instant Messaging (IM) or standard phone numbers. For each of these modes, there is a remote, supervisory party configuration which may comprise an Instant Message ID or a phone number. For each communications mode configuration, there is an associated number configuration (NC), which contains lists of phone numbers of users. By way of example, when a user of telephone device  19  calls a number that requires a FAC (e.g., a call to phone  20 ), PBX  11  first determines whether telephone device  19  has a number listed in its NC lists; if so, the system retrieves the associated remote, supervisory party information. PBX  11  then establishes communication with the remote, supervisory party (e.g., a supervisor  18 ) using the configured communications mode (e.g., IM or phone). The supervisor may either extend (i.e., authorize) or reject the call based on information provided about the nature or reason for the call. 
     When a person in the organization who does not have a FAC places a toll call, the route pattern of that call is associated with a particular supervisor or set of supervisors, each of which may have a preferred mode of communications. For instance, RAM  14  may identify that the appropriate communications mode for a particular supervisor is IM. Thus, when the system refers the call to that supervisor for authorization, an IM message may pop up on the display screen of the supervisor&#39;s PC with a message such as “X is trying to reach Y. Please press the ‘Authorize’ button on the screen if call needs to be extended or press the ‘Deny’” button if call is to be dropped”. In such an embodiment, the IM client may automatically generate and display the “Authorize” and “Deny” buttons. Alternatively, the supervisor may type the word “authorize” followed by an authorization code, etc., or “reject”. In one embodiment, if the supervisor denies the call then he may also type in a reason for denying the call. This reason may then be played back to the user (caller). If the particular supervisor is not logged in, or does not respond to the IM message within pre-specified timer, then system may take a default action, e.g., deny the call, or attempt to contact another supervisor in the set. 
     Alternatively, PBX  11  may identify that the appropriate communications mode for a particular supervisor is via a telephone number. In this case, system  11  may place a telephone call to the remote supervisor and play an IVR message that asks the supervisor to either authorize or reject the call. Remote party can then authorize or reject using DTMF digits (such as # 11  to authorize and # 12  to reject) or using recognizable speech responses, e.g., by saying “authorize” or “reject”. In one embodiment, the supervisor may state the reason for denying the call, which reason is then played back to the user (caller). Again, if the supervisor does not answer the call, then system may take a default action or attempt to contact another supervisor in the set. 
     In one embodiment, when a call is referred to a particular supervisor for authorization review, he may explicitly forward the decision-making authority over that call to another supervisor. The new supervisor receiving the forwarded call may or may not be included RAM  14 . Basically, the supervisor is transferring his authority to someone else for just that one call or instance. For example, in the case where a software engineer is making a call to a customer, his manager (who has been configured as the supervisor) may transfer the authority to allow or reject that call to his technical leader who is dealing with that customer&#39;s cases. If the new supervisor (e.g., the technical leader) is not in the RAM, then the system may try various communication modalities or use a presence server to contact the new supervisor. In another embodiment, the supervisor may set up a preference in the PBX system such that all authorization requests related to customer ABC or case number XYZ be forwarded to his technical lead for authorization. 
       FIG. 3  illustrates an example Remote Authorization Mode module  14  shown in  FIG. 1 . As can be seen, module  14  contains a set of route patterns (RP 1 , RP 2  . . . RPN), each of which is associated with a set of supervisors to be contacted when a particular user in the organization attempts to place a call to a number that requires authorization. For instance, Supervisor Set  1  is shown having four supervisors (S 1 A-S 1 D), each having associated communication or contact information (e.g., IM, phone number, etc.). In this example, each supervisor has a preferred communication mode (e.g., IM) for purposes of authorizing calls. In certain implementations, a presence server may be utilized by system  11  to determine whether a particular supervisor is currently logged onto his PC, e.g., for purposes of receiving an IM communication. If not, the system may attempt to contact that supervisor via an alternative form of communication (e.g., phone, pager, email, etc.). 
     In the case a supervisor who is contacted to authorize a particular call, and who is logged onto a PC that is running an IM client or tool, PBX system  11  may dynamically seek out the supervisor and contact him via an IM message that pops up in a window on the screen of his PC. By way of example,  FIG. 7  illustrates an example graphical user interface (GUI) window  70  for use in authorizing a remote call. Window  70  is displayed on the screen of the supervisor&#39;s PC with various call context information, such as the name of the caller, the caller&#39;s direct supervisor (who may be different than the supervisor designated for review/authorization of international and toll calls), the number called, the customer number associated with the call, a work-related case number, and a text note field  75 . The context information shown in  FIG. 7  may be provided by the caller via a series of IVR menu prompts, or automatically by the system. For example, PBX system  11  may automatically recognize or associate the dialed phone number with a particular customer number and/or case number. 
     Note field  75  may be utilized by the caller/user to communicate special information related to the call, or to present a specific request to the reviewing supervisor. In this example, note field  75  includes a user request for a consultation in order to explain the specific purpose or reason for the call. The supervisor may accept the request for a consultation with the caller, James Smith, by pressing or selecting (e.g., clicking) icon or button  73 . Alternatively, the supervisor can consult with the caller&#39;s direct supervisor, John Jones, by clicking on button  74  in order to determine whether the call should be authorized. In different embodiments, consultations may be implemented in the GUI by another pop-up window that provides for IM communication, or, alternatively, by initiating a phone call form the supervisor to a phone number of the person with whom a consultation is desired. 
     In still other embodiments, note field  75  may be eliminated entirely, leaving the decision to consult with the caller (or his direct supervisor) solely in the hands of the supervisor via GUI window  70 . For instance, the supervisor may click on button  73  to automatically establish a voice session with the caller (e.g., via either a standard call offer or a barge-in) in order to converse with the caller to determine the reason for the call. 
     Window  70  also includes buttons  71  &amp;  72  for respectively approving or denying the call. In this example, buttons  71  &amp;  72  may be clicked on or selected at any time by the supervisor. For instance, if the supervisor is convinced that the outbound call should be allowed, he may simply click on approval button  71 . In one embodiment, clicking  72  may also bring up a dialog box or field to allow the supervisor to enter a reason for denial. In another embodiment, window  70  already has a dialog box to allow the supervisor to enter a reason for denying the call. 
       FIG. 4  illustrates an example IP telephone device  25  with softkey functions that may be utilized by a caller/user who wishes to place a long-distance or toll call without a FAC. IP telephone  25  includes a liquid crystal display (LCD) screen  27 , dynamic softkeys  26 , a handset  29 , and an alphanumerical keypad  28 . In one embodiment, softkeys  26  may be used to automatically request a consultation with the reviewing supervisor. Such a consultation may be useful in relating the particular reason or business purpose of the call. For example,  FIG. 5  illustrates screen  27  of IP telephone device  25  displaying a text message asking the caller whether they want to request a consultation with the reviewing supervisor. Softkeys  26 A &amp;  26 B are automatically configured as single-button inputs to allow the user to either request (“Yes”) or forego (“No”) a consultation. 
     In yet embodiment, telephone device  25  may also be configured to have a text field where the user may enter his reason(s) for requesting approval (e.g., customer no., case no. etc.) using the alphanumeric key pad. 
     It is appreciated that different embodiments may execute different routines/approaches for establishing communications between the user and the selected meeting participant. For instance, in one embodiment, the softkeys of a user&#39;s telephone device might be automatically configured to provide the caller with the option of directing the call to a particular supervisor. In another embodiment, the caller is provided with the option (at the time of placing the call) of specifying the contact details (e.g., IM or phone number) of the supervisor who will decide whether to authorize that call. In another embodiment, rather than have the system automatically select an alternative supervisor from the set or pool of available supervisors in the event that the first or primary supervisor is unavailable, the system prompts the caller to enter the contact details of an alternate supervisor who can authorize placement of the call. 
     PBX system  11  may also be configured in a variety of ways to achieve different specific functions or implement certain features. In one embodiment, the system includes a mapping to a particular set of supervisors based on the time of day. For example, if someone is placing a call at 11 p.m. from a site in California, the system may automatically route the call to a set of supervisors located in another time zone, e.g., India, where supervisors are working normal business hours, and thus are available to authorize or deny the call. In other words, the system may implement various selection rules for routing calls to an appropriate pool of supervisors. 
     In another embodiment, the system provides a mechanism where a line owner of a telephone device can set a supervisory number (e.g., the owner&#39;s mobile phone) for outbound calls on the line. When activated, any call from the line automatically results in the system placing a call to line owner seeking permission or authorization for the call. Line owner then has the option to authorize or reject the call. This embodiment is useful in scenarios outside of a traditional business organization, such as where a father purchases a cell phone for his teenage daughter, but wants to control limit the number or type of calls she can place. Similarly, a store manager may want to restrict his employees from placing international or long distance calls, allowing such calls only after receiving a notification from the system asking for permission whenever an employee attempts to place an international or long distance call. 
       FIG. 2  illustrates an example authorization queue for use in the PBX system shown in  FIG. 1 . In this example queue  13  comprises separate queues  21  and  22  for collecting/holding future and current calls, respectively, consistent with an embodiment that provides for pre-authorization of calls by supervisors. Such embodiment allows a caller to request pre-authorization of a particular call in advance of the actual call time. 
     Calls for which pre-authorization is requested are placed in queue  21 , while current calls are placed in queue  22 . One of the set of designated supervisors may authorize a call in queue  21  before the time the call is actually placed. The authorization is attached to the called number by the system along with the associated caller number and scheduled time of the call. For instance, an employee may request authorization for a call to a customer located in Japan with the call being scheduled next week at around 8 p.m. (e.g., +5 minutes) local time. An appropriate supervisor is then notified of the call by the system well in advance of the scheduled call time window. If the supervisor approves the call, the employee can call the customer at the scheduled time. 
       FIG. 8  illustrates an example method for third party authorization of a call prior to actually establishing a call connection between the caller and callee. The example of  FIG. 8  begins with the caller dialing a long-distance number from within an organization (block  81 ). Upon receiving the call and in response to the route pattern indicated by the number, the organization&#39;s PBX system prompts the caller/user to enter a FAC to connect the call. The prompt may be made via an IVR system, or, alternatively via IM if the user is logged onto or is placing the call from his PC. If the user is able to enter a valid FAC (block  84 ), then the PBX simply connects the call to the telephone number dialed (block  85 ). If, on the other hand, the user does not have a valid FAC, then the PBX system operates to contact an appropriate remote supervisor that has the authority to allow or deny the call (block  86 ). As previously discussed, a variety of different techniques, communications modes, and mechanisms may be used contact a particular supervisor. 
     Once the supervisor has been contacted and the call information is before the supervisor (e.g., via a GUI window or IVR playout), the supervisor is presented with the option of consulting with the caller or caller&#39;s direct supervisor (block  87 ). Because in most cases the decision to allow or deny a call is primarily based on the purpose or reason for the call, the supervisor may opt of a consultation to allow either the caller or the caller&#39;s supervisor to elaborate on the business purpose for making the call (block  88 ). In some cases consultation is unnecessary, as the purpose may be clearly evident from the information already provided to the supervisor. In other cases, the supervisor may summarily deny the call without consultation due to a change in business priorities, cost-cutting concerns, new business plans, changing customer relations protocols, etc. In still other instances, the supervisor may forward his decision-making authority to another person. 
     Whatever the case, at some point the supervisor makes a decision (block  89 ), and the call is either connected (block  90 ) or dropped (block  91 ). In certain embodiments, the supervisor may ignore the call such that after a predetermined time period where no decision has been made, the system automatically makes a default decision, i.e., either approve or deny depending on the default setting. In some embodiments the supervisor may also provide a reason for declining the call. 
     It should be further understood that elements of the present invention may also be provided as a computer program product which may include a machine-readable medium having stored thereon instructions which may be used to program a computer (e.g., a processor or other electronic device) to perform a sequence of operations. Alternatively, the operations may be performed by a combination of hardware and software. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnet or optical cards, or other type of machine-readable medium suitable for storing electronic instructions. 
     Additionally, although the present invention has been described in conjunction with specific embodiments, numerous modifications and alterations are well within the scope of the present invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.