The present invention relates to a method and system for incorporating user mobility with the implementation of enhanced call service features at a remote location such that the PBX-like features can be accessed at any desired location.
During the past decade, the number of professionals that “telecommute” (i.e., work at home or other “virtual office” locations) has increased significantly. Although the proliferation of various types of computing and telephony equipment has enabled these workers to be effective, there remain a number of office-related advantages that cannot, without great expense, be duplicated at home. Additionally, in situations where an individual spends a significant amount of time traveling, it becomes even more difficult to provide certain advantages, such as PBX-based telecommunication features as are found in most conventional office environments. A private branch exchange (PBX) switch is commonly known in the art as a system useful in providing certain calling features such as abbreviated dialing, call transfer, hold, mute, and others, within an office complex served by the PBX switch. One exemplary PBX switch is the Definity™ switch sold by Avaya, Inc.
A PBX switch may be located “on site” as customer premise equipment—CPE—(one example of CPE being the Definity switch sold by Avaya) or located within the communications network and used by one or more different customers. An exemplary network-based PBX is disclosed in U.S. Pat. No. 5,742,596 issued to Y. Baratz et al. on Apr. 21, 1998. With a network-based PBX, the various office locations may be referred to as “remote” in the sense that the physical office locations need to establish a link with the network-based PBX to obtain the desired functionality. The office stations themselves, however, are equipped with the traditional PBX station set equipment. The actual location of the PBX switch, therefore, is of no concern to the office worker.
In some situations, “telecommuters” have incurred the expense of adding an additional phone line, or ISDN, to handle the increase in telephony traffic associated with working at home. While this solution is acceptable in some situations, it quickly becomes an expensive alternative for the employer. Further, the “traveling” employee has no “home office” within which to install such equipment, remaining disadvantaged with respect to the personnel at a traditional work location. Indeed, the technology deployed at the home office may “lag” the latest PBX-based innovations found in the office.
As described in our pending application Ser. No. 09/370,766, an individual at a location “remote” from the office may have “PBX-like” capabilities, with all communications being controlled by a remote office platform, linked to the remote worker. In particular, the remote office platform is linked to the office PBX system. Features such as abbreviated dialing for in-house calls, call forwarding, call transfer, hold, three-way calling, secretarial pick-up, and more, are provided at a remote location where an individual can connect to the remote platform and have a user interface display available. The graphical user interface (GUI), in a preferred embodiment, is a “soft phone”, displaying a PBX station-like set-up including a handset, call feature buttons, a message center, and the like.
The system as described in this pending application uses a remote office platform that communicates with both the office (or network) PBX and a data network coupled to the remote office location. The remote office platform includes the software necessary to “push” the GUI to the remote device and also comprises a database including necessary information regarding each employee permitted to access the “virtual PBX” system. Once activated by a remote worker, the remote office platform communicates with the office PBX so as to communicate all PBX-based requests from the remote location back to the office PBX. In the other direction, all incoming calls to the remote worker's PBX extension are forwarded by the PBX to the remote office platform and, ultimately, to the remote location. The term “office PBX” as used throughout this discussion is considered to include a customer-premise PBX, a network-based PBX (perhaps being shared by a number of different subscribers), or any other suitable PBX architecture.
In operation of this arrangement, a remote worker establishes authenticated communication with the remote office platform. Voice connectivity between the office PBX and remote worker can be provided over whatever telephony connection exists at the remote location (POTS over PSTN, cable, fixed wireless, among others). Data connectivity, used for transferring all call requests between the remote worker and the remote office platform, as well as enabling the PBX-like interface at the remote end, may be provided by any suitable data network including, but not limited to, the Internet.
Although the system as disclosed in our pending application is extremely proficient in allowing a “remote worker” access to many of the available office features, once the worker “logs out” of the system, all of the interconnect information is lost, and the worker must go through the entire process of logging in to be re-connected. While this is not very problematic for instances where the remote worker remains at the same off-site location, for those individuals that spend any quantity of time “on the road” or at multiple locations, it may become burdensome to constantly require the worker to re-activate the remote office system.
Thus, a need remains in the remote office environment for addressing the mobility of most remote workers, allowing such individuals to remain in communication with a remote office platform.
The need remaining in the prior art is addressed by the present invention, which relates to a method and system for incorporating user mobility with the implementation of enhanced call service features at a remote location such that the PBX-like features can be accessed at any desired location.
In accordance with the present invention, mobility is incorporated into a remote worker's environment by allowing the individual to enter a mobile number prior to ending an interconnect session with a remote office platform. Once the individual terminates a particular remote session, the stored mobile number associated with that individual will be used by the remote office platform to maintain an active session with the remote worker. In particular, a mobility process is created and maintained at a central server in the network so as to run in background mode, transparent to the user. When an individual terminates a remote session, the process will be triggered to initiate the mobile session. Thus, until the worker terminates the mobile session, the mobile number will be used by the remote platform to maintain contact with the remote worker. In one embodiment, the process may be implemented as a Java script applet, although other implementations are possible.
In accordance with the present invention, the mobile number is used only when the remote worker is not logged into the system; the mobile number remaining inactive, but ready to be re-activated once the individual ends the session. The worker may, at any time, change the mobile number stored within his data record at the remote platform database.
Other and further aspects of the remote worker mobility features of the present invention will become apparent during the course of the following discussion and by reference to the accompanying drawings.
Referring now to the drawings,
An exemplary architecture 10 for implementing the mobility feature of a “remote office” platform is illustrated in
A “remote”/home office location 22 is also shown in
The “remote office” features are provided to location 22 via a remote office platform 34, configured as shown in
The following discussion will provide details associated with “call flow” to/from a remote worker prior to activating the “mobility” option of the present invention, since it is important to first understand the workings of the remote office platform and the implementation of the PBX-like features for a remote worker. As mentioned above, a remote worker must first “log in” to the virtual PBX system in order to avail himself of any of the call features discussed above. To log in, a remote worker dials in, via his endpoint terminal (such as computer terminal 38) over data network 20 to a security system 52 within service controller 44.
Various security arrangements can be used to authenticate the remote worker and his capability to access the virtual PBX system. For example, a personal ID number and password may be used. Other arrangements are possible. Once the remote worker is authenticated, service controller 44 sends a message to switch controller 42, indicating that the control of all telecommunications associated with the identified remote worker are to be passed by PBX 14 to remote platform 34. Switch controller 42 then sends a message identifying the remote worker to PBX 14 and as a result, PBX 14 will now hand off all call control to remote platform 34 for calls received for the remote worker's identified station 12 within office 16 (whether the calls originate within the office or outside of the office) and PBX 14 will react based upon instructions from remote platform 34. Obviously, the same mechanism will be utilized for a network-based PBX, where switch controller 42 instructs switch 40 to locate PBX switch 14P and function as described above to hand off all telecommunications traffic destined for the remote worker to remote office platform 34.
An important feature of the “virtual PBX” arrangement which is particularly advantageous when incorporating the mobility aspect of the present is that the remote worker's actual location is not necessary for others to know in order reach him at his usual office phone number. That is, a caller places a call to the remote worker in the usual fashion, dialing the office phone number associated with the remote worker (for internal calls, abbreviated dialing in terms of a 4 or 5-digit number may be dialed; for external calls, the conventional full number is dialed). PBX 14, upon recognition of the dialed number, will “hand off” the incoming call to remote platform 34 via (for example) a CTI link 56 to switch controller 42 (network PBX 14P utilizing a similar CTI link 56P). The call is then passed to service controller 44 which performs a look-up in database 46 to determine the “reach” number for the remote worker. As will be discussed in detail below, the “reach” number becomes, by default, the worker's mobile number once a “remote session” is completed. Once the reach number is obtained, service controller 44 sends an “incoming call” message to the remote worker's “soft phone” via data network 20. If the remote worker is on another call, they have the option to place the first call on hold (such as by “clicking” the “hold” button 62 on soft phone display 60 of
The remote worker is also capable of placing outbound calls from endpoint terminal 38, where these calls will ultimately be processed by PBX 14. Therefore, the remote worker may use a speed dialing list, or any other PBX-like feature associated with his office station set 12 and stored in database 46 of remote office platform 34. The request to place the call may be initiated by activating, for example, “connect” button 66 on display 60. The “call connect” message is then sent, via data network 20, to remote platform 34. Service controller 44, in turn, tells switch controller 42 to instruct PBX 14 to place the call. PBX 14 ultimately connects the parties by launching a first call to the remote worker's station and a second call to the called party number, then bridges the calls together. In this “virtual PBX” arrangement, therefore, the remote worker's telephone will remain “on hook” for outbound calls until the remote platform calls back to bridge the calls together.
An exemplary “soft phone” display 60 is illustrated in
In accordance with one embodiment of the present invention, once a “mobile” remote session is active, a check is made to determine if PDA 74 can support a “mobile” soft phone GUI (such as display 60 of
Various other features may be included in soft phone display 60, and utilized at either the remote worker's “home” office equipment 38 or PDA 74 (if possible). As shown, a graphical handset 74 may be included and activated to go “off-hook” by a mouse click—either to answer an incoming “soft phone” call (to be forwarded from the office PBX) or place an outbound call “soft phone” call (to be forwarded to the office PBX for completion). Display 60 may also include a set of line indicators, in this example, a pair of line indicators 76 and 80 (showing that two separate “soft phone” lines are coming into endpoint terminal 38), where the indicators will illustrate the presence of an incoming call (by changing color, for example) or the “hold” state of one call while another is being answered (by “blinking”, for example). Other elements, discussed in detail in our co-pending application include, speed dialing, a message area (in which information such as caller ID may be displayer). Display 60 may also include “message waiting” lights and indicators to activate various types of call treatment (e.g., hold, forward, conference, mute, etc.).
In an environment as described above where the mobile device cannot support a soft phone GUI, the remote worker's mobile access to remote office platform 34 is limited to a traditional telephone set (that is, the mobility number is a conventional cell phone with no data connection), the “virtual PBX station” attributes can be provided by using various DTMF tones to determine call control.
While the present invention has been described in connection with the illustrated embodiments, it will be appreciated and understood that modifications may be made without departing from the true spirit and scope of the invention. It is to be understood that the particular embodiments shown and described are by way of illustration and in no way intended to be considered limiting. Therefore, references to details of a particular embodiment are not intended to limit the scope of the claims, which in themselves recite only those features regarded as essential to the invention.
This application is a continuation of U.S. application Ser. No. 10/833,479, filed Apr. 27, 2004 now U.S. Pat. No. 7,174,189, and allowed on Sep. 25, 2006, which is a continuation of U.S. application Ser. No. 09/805,292, filed Mar. 13, 2001, now U.S. Pat. No. 6,823,197, issued on Nov. 23, 2004.
Number | Name | Date | Kind |
---|---|---|---|
5742596 | Baratz et al. | Apr 1998 | A |
5841854 | Schumacher et al. | Nov 1998 | A |
6014377 | Gillespie | Jan 2000 | A |
6198932 | Nakanishi | Mar 2001 | B1 |
6301339 | Staples et al. | Oct 2001 | B1 |
6314303 | Phipps | Nov 2001 | B1 |
6324410 | Giacopelli et al. | Nov 2001 | B1 |
6356554 | Pickett et al. | Mar 2002 | B1 |
6434169 | Verreault | Aug 2002 | B1 |
6453035 | Psarras et al. | Sep 2002 | B1 |
6496694 | Menon et al. | Dec 2002 | B1 |
6542475 | Bala et al. | Apr 2003 | B1 |
6553102 | Fogg et al. | Apr 2003 | B1 |
6560222 | Pounds et al. | May 2003 | B1 |
6567514 | Fleischer et al. | May 2003 | B2 |
6633636 | McConnell et al. | Oct 2003 | B1 |
6668176 | Koski et al. | Dec 2003 | B1 |
6711401 | Chow et al. | Mar 2004 | B1 |
6816583 | Roeder | Nov 2004 | B2 |
6823197 | Chen et al. | Nov 2004 | B1 |
6882862 | Chia et al. | Apr 2005 | B1 |
6915437 | Swander et al. | Jul 2005 | B2 |
6937704 | Meijer et al. | Aug 2005 | B1 |
6970719 | McConnell et al. | Nov 2005 | B1 |
6985723 | Kil | Jan 2006 | B2 |
7136475 | Rogers et al. | Nov 2006 | B1 |
7171199 | Rahman | Jan 2007 | B1 |
7200218 | Lindley et al. | Apr 2007 | B1 |
7260078 | Ledsham et al. | Aug 2007 | B1 |
7319693 | Chen | Jan 2008 | B2 |
7386452 | Bates et al. | Jun 2008 | B1 |
7466978 | Chapman et al. | Dec 2008 | B1 |
20010041594 | Arazi et al. | Nov 2001 | A1 |
20010046860 | Lee | Nov 2001 | A1 |
20020001301 | Sarkissian et al. | Jan 2002 | A1 |
20020009991 | Lu et al. | Jan 2002 | A1 |
20020021465 | Moore et al. | Feb 2002 | A1 |
20020034168 | Swartz et al. | Mar 2002 | A1 |
20020049768 | Peek et al. | Apr 2002 | A1 |
20020065758 | Henley | May 2002 | A1 |
20020069278 | Forslow | Jun 2002 | A1 |
20020076031 | Falcon et al. | Jun 2002 | A1 |
20020098855 | Hartmaier et al. | Jul 2002 | A1 |
20020107014 | Kosuri | Aug 2002 | A1 |
20020181398 | Szlam | Dec 2002 | A1 |
20030235284 | Fleischer et al. | Dec 2003 | A1 |
20060013240 | Ma et al. | Jan 2006 | A1 |
20060019688 | Kil | Jan 2006 | A1 |
20070259688 | Forte | Nov 2007 | A1 |
20080025295 | Elliott et al. | Jan 2008 | A1 |
Number | Date | Country | |
---|---|---|---|
Parent | 10833479 | Apr 2004 | US |
Child | 11641161 | US | |
Parent | 09805292 | Mar 2001 | US |
Child | 10833479 | US |