WO2012054012A1

WO2012054012A1 - VoIP MULTIMEDIA TERMINAL ADAPTER SYSTEMS AND METHODS

Info

Publication number: WO2012054012A1
Application number: PCT/US2010/002803
Authority: WO
Inventors: Steven Lee Cooper
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2010-10-20
Filing date: 2010-10-20
Publication date: 2012-04-26
Anticipated expiration: 2013-04-20

Abstract

Multimedia terminal adapter (MTA) systems and methods in accordance with Voice over Internet Protocol are described. MTAs can be configured to enable handsets to utilize a prompt login feature that permits users to log the handset on to multiple profiles simultaneously, thereby allowing a user to quickly answer a call from an initially unauthorized handset. In addition, at least a portion of call logs stored at the MTA for each profile can be accessed between profiles to enable the handset to perform various functions, such as call transferring. Moreover, the system can be configured such that only a device allocated to a particular line/profile can ring and answer a call received on the line/profile.

Description

VoIP MULTIMEDIA TERMINAL ADAPTER SYSTEMS AND METHODS

BACKGROUND

In recent years, alternatives to traditional telephone services have become

commercially viable and popular due to the ability to provide these alternatives at a relatively low cost. A Voice over Internet Protocol (VoIP) system is one such example. VoIP enables cable service providers to use their existing networks and much of their existing equipment to provide a telephone service of acceptable quality to their customers. In particular, voice communications are transmitted over internet protocol (IP) networks, such as the internet or other packet switched networks, in lieu of or in combination with a public switched telephone network. Typically, a VoIP telephone call is implemented by converting an analog voice signal from a telephone to a digital format and compressing or translating the signal into IP packets for transmission over an IP network. Conversely, received voice

communication signals are decompressed or translated from IP packets and converted into analog voice signals that are provided to a user's telephone. The conversion between IP packets and analog voice signals are performed by a multimedia terminal adapter (MTA) of the VoIP system. Currently available MTAs are capable of providing several lines to a user's premises, each of which can be associated with a different profile. SUMMARY

Management of operations in currently available MTAs and associated handsets on a user's premises are limited in several respects. For example, users currently cannot log a handset into multiple telephones lines/profiles provided by the MTA. Another limitation of currently available MTAs is that they prevent a user of one profile from accessing call logs of a different profile. In addition, such systems fail to record calls made to lines/profiles in certain scenarios. For example, in current MTA systems, when a handset that is allocated to one profile is used to answer a call directed to a different profile, the MTA systems fail to log the call in the call log of the profile to which the call was originally directed. Further, current MTA systems are configured to ring all handsets when a call is received on a particular line/profile, thereby permitting all users to access all calls, which can be undesirable in many situations.

The present principles provide several solutions to address various problems associated with currently available MTA systems. For example, an aspect of the present principles includes a prompt login feature that can be implemented through a handset to enable the handset to logon to multiple lines/profiles. This aspect permits a user to quickly logon an unauthorized handset to a line/profile as a call is received on the line/profile to enable the user to answer the call. In addition, an MTA in accordance with one embodiment can be configured to enable flexible access of at least a portion of call logs between different profiles.

One exemplary embodiment is directed to a method. In the method, an incoming call can be received in accordance with VoIP. In addition, a user can be prompted to log a handset on to a profile on which the call is being received. Further, login information can be received from the user and the handset can be allocated to the profile on which the call is being received to permit the user to answer the call.

Another exemplary embodiment is drawn toward a system. The system can include a plurality of VoIP telephone handsets and an MTA. The MTA can be configured to logon at least a first handset of the plurality of handsets to one or more profiles in response to receiving login information from the first handset.

An alternative exemplary embodiment is directed to a system. The system can include a plurality of VoIP telephone handsets and an MTA. Here, the MTA can be configured to store a respective call log for each profile associated with respective telephone lines provided through the MTA such that at least a portion of a call log for a first profile is accessible by a handset that is not logged on to the first profile.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:

FIG. 1 is a block diagram of a VoIP communication system.

FIG. 2 is a block diagram of an MTA system and corresponding devices serviced by the MTA.

FIG. 3 is a block/flow diagram of a method for allocating a VoIP handset to a line/profile in accordance with a prompt login feature.

FIG. 4 is a block/flow diagram of a method for performing an outgoing call in accordance with a prompt login feature.

FIG. 5 is a block/flow diagram of a method for transferring a call by employing call logs.

FIG. 6 is a block/flow diagram of a method for logging a telephone call. FIG. 7 is a block/flow diagram of a method for restricting ringing of devices in accordance with line/profile allocations that can be implemented at an MTA.

FIG. 8 is a block/flow diagram of a method for restricting ringing of devices in accordance with line/profile allocations that can be implemented at a telephone handset.

It should be understood that the drawings are for purposes of illustrating the concepts and are not necessarily the only possible configuration for illustrating the embodiments. To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. DETAILED DESCRIPTION

Referring now in specific detail to the drawings in which like reference numerals identify similar or identical elements throughout the several views, and initially to FIG. 1, an exemplary system 100 for implementing embodiments is illustrated. The system 100 can include one or more Voice over Internet Protocol (VoIP) telephone handsets 101-103 that are connected to and are in signal communication with a Multimedia Terminal Adapter (MTA) 105 of a VoIP system on a user's premises 107. It should be understood that three handsets are shown as an example; the MTA can service any number of handsets in accordance with design choice. Further, the MTA 105 can also service one or more other devices 104, such as a fax machine. The MTA 105 can be connected to and can be in signal communication with a cable modem (CM) 106 to enable the devices 101-104 to access a cable network 108 using VoIP. It should be noted that the MTA 105 and the cable modem 106 can be separate units or can be integrated in a single unit. The system 100 can further include a Cable Modem Termination System (CMTS) 1 10 (commonly referred to as a cable head-end) that can be in the local cable network 108 and can be configured to act as an interface between the local cable network 108 of a service provider and an IP network 112, such as the internet. In tum, the CMTS 110 can be connected to a telephony gateway 1 14 on the IP network 1 12 to provide access to a Plain Old Telephone Service (POTS) network 1 16, such as a Public Switch Telephone Network (PSTN). Here, the MTA 105 can, for example, be configured to convert between analog voice signals and IP packetized voice signals while the telephony gateway 1 14 can, for example, be configured to convert between IP packetized voice and standard pulse code modulated signals for the POTS network.

It should be understood that the functions of the various elements shown in the figures can be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions can be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which can be shared. Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and can implicitly include, without limitation, digital signal processor ("DSP") hardware, read-only memory ("ROM") for storing software, random access memory ("RAM") and non-volatile storage. Moreover, all statements herein reciting principles, aspects, and embodiments, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure).

Thus, for example, it will be appreciated by those skilled in the art that the block diagrams presented herein represent conceptual views of illustrative system components and/or circuitry embodying the principles of the embodiments. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudocode and the like represent various processes which can be substantially represented in computer readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

Referring now to FIG. 2, with continuing reference to FIG. 1, a VoIP system 200 including the MTA 105, the telephone handsets 101-103 and the other device(s) 104 on a user's premises 107 is illustrated. As depicted in FIG. 2, the MTA 105 can include a controller 202, which can be configured to manage operations of the MTA 105 and to manage communication with the handsets 101-103 and the other device(s) 104, such as a fax machine, using novel methods described in more detail below. The user-interface 204 of the MTA 105 can include a display and a keypad to permit a user to configure and communicate with the MTA 105 as an alternative to using the handsets 101-103 and the other device(s) 104. The controller 202 can employ the cable modem interface 206 to connect the MTA system 105 to the cable network 108 via the modem 106. In addition, the MTA 105 can also include a telephone handset interface(s) 208 and a device interface 210 to permit the MTA 105 to communicate with handsets 101-103 and other device(s) 104, respectively, as shown. It should be understood that the interfaces 208 and 210 can be wired, wireless or can include both wired and wireless components. The MTA 105 can further comprise a storage medium 212, on which a reference table 214 and call logs 216-222 can be stored. The table 214 can include information that relates the handsets 101-103, and also the other device(s) 104, to one or more lines/profiles, which can be referenced by the controller 202 to keep track of the line/profile allocations and determine to which devices 101-104 calls should be forwarded, as discussed in more detail below. Additionally, call logs 216-222 can record a listing of calls answered and made on each line/profile and each device 101-104. In the example illustrated here, the MTA 105 services four lines/profiles, denoted as P.1-P.4. It should be noted that, in accordance with exemplary embodiments described herein, each profile is assigned and associated with a different line/telephone number.

In the embodiment illustrated in FIG. 2, each handset 101-103 can include a display 224, standard keys 226 and shortcut keys 228. The standard keys 226 can include keys denoting digits, a "power on" button, a speaker phone button and a menu key. The shortcut keys 228 can facilitate user-navigation to access certain information. For example, currently available VoIP systems require a user to navigate through a number of menus to access certain information, such as call logs. The shortcut keys 228 can permit users to quickly access such information. For example, a user can select a "down arrow" to automatically display a contact list for a profile to which the handset is logged on and connected. Other keys within the shortcut keys 228, such as a "right arrow" key, can be employed to automatically display a call log list for a profile to which the handset is logged on and connected upon user-selection of the key. Shortcut keys 228 can further include additional keys, such as a dedicated key for automatically redialing the last-dialed telephone number.

In accordance with one exemplary aspect, the MTA 105 can facilitate prompt modification of line/profile assignments to handsets using a login feature. In particular, the MTA 105 can permit each telephone handset 101-103 to be logged into multiple

profiles/lines and to answer calls received on those different lines/profiles. Further, any one or more of the handsets 101 -103 can be configured to display a menu in response to user- selection of a key 226. The menu can provide an option for a user to log-on to one or more lines/profiles and can display a listing of lines/profiles available at the user's premises 107. In response to user-selection of an available profile, the handset can prompt a user to enter a password. Here, the password can be an administrator password that provides access to all available lines/profiles or can be specific to one or more lines/profiles. The password can be alphanumeric or can comprise biometric data, such as a thumb/fingerprint. The "password" can also correspond to data obtained through voice/command recognition, facial recognition using a built-in camera, or through other means. Thus, the user can simply press a button, which would register the print, or say their name or a pass-phrase and the MTA 105 can permit the user to answer the call for the correct profile. Even radio frequency identification (RFID) data can be used to identify the person picking up the handset.

After the user enters the password, the handset can transmit the password and an identifier for the requested line/profile to the MTA 105 via the interface 208. In turn, the controller 202 can cross-reference the received password with a password stored in the storage medium 212 for the requested line/profile. If the passwords match, then the handset from which the request was received is listed under the requested line/profile in the reference table 214. In this way, the handset can be assigned to a particular line/profile to permit the handset to receive and make calls on the line/profile.

In addition, it should also be noted that a user can de-allocate a line/profile from a handset in a similar manner. For example, the menu can provide an option for a user to deallocate one or more lines/profiles and can display a listing of lines/profiles to which the handset is allocated. Further, the user can select a line/profile to de-allocate, in response to which the handset can prompt the user to enter a password. In turn, the handset can transmit the entered password and an identifier for the line/profile to be de-allocated to the MTA 105 via the interface 208. As discussed above with respect to the login feature, the controller 202 can cross-reference the received password with a password stored in the storage medium 212 for the selected line/profile and can de-allocate the handset in the reference table 214 if the passwords match.

The prompt login feature discussed above can permit a user to conveniently access lines/profiles in a novel manner in a variety of situations. For example, in one scenario, it can be assumed that the telephone/handsets 101-103 are initially allocated to respective lines/profiles P.1-P.3, where handset 101 is allocated line/profile P.l, handset 102 is allocate line/profile P. 2, etc. It can also be assumed that handsets are restricted from accessing or receiving calls on lines/profiles to which the handsets are not logged on. If the MTA 105 receives a call on line/profile P.l, the login feature permits a user to quickly allocate a handset to the line/profile P.l. For example, if the call is received by the MTA 105 when the user is near handset 102 but away from handset 101, then the user can allocate the handset 102 to line/profile P.l to answer the call before the caller hangs up or before the call is forwarded to a voicemail server.

Here, the MTA 105 and the handsets 101-103 can be configured such that a handset which is not allocated to a line/profile that is receiving a call can ring. For example, the handset 102 in the scenario described above can ring and can display a message prompting a user to enter a password for the line/profile on which a call is received and/or can notify the _η user that the handset(s) logged on to the line/profile on which a call is received should be used, which in this case is handset 101. In turn, upon user-entry of the password, the handset 102 can be allocated the line/profile P.l as described above and can answer the call using the handset 102 before the caller hangs up or before the call is forwarded to a voicemail server.

With reference now to FIG. 3 with continuing reference to FIGS. 1 and 2, a method

300 for allocating a VoIP handset to a line/profile in accordance with a prompt login feature is illustrated. The method 300 can begin at step 302, in which the MTA 105 can receive a call in accordance with VoIP on a line/profile. For example, the MTA 105 can receive a call through the cable network 108, as discussed above with regard to FIG. 1.

At step 304, a handset 101-103 can prompt a user to log the handset onto the line/profile on which the call is received. For example, as described with respect to the scenario provided above, a telephone/handset 102 can ring when a call is received on a line/profile P.l to which the handset 102 is not logged on and the user can be prompted to enter a password to logon to the line/profile P.l . Alternatively, if the handset 102 is configured to not ring for calls received on line/profiles to which the handset 102 is not logged on, as discussed in further detail below with respect to an exemplary embodiment, the user can hear a different handset ring. For example, in the scenario described above, the user can hear handset 101 ring in a different room and can direct the handset 102 to display a menu, where the user is prompted to log-on to the profile P. 1, as discussed above with regard to FIG. 2. Here, the menu can correspond to the same menu displayed at step 404 of method 400, which is discussed in more detail herein below.

At step 306, the handset 101-103 can receive login information from the user. For example, as discussed above with regard to FIG. 2, the user can enter an administrator password or a password specific to the line/profile on which the call is received. Further, the handset can transmit the login information to the controller 202 to permit the controller 202 to verify the login information.

At step 308, the controller 202 of the MTA 105 can determine whether the login information is correct. For example, as discussed above with regard to FIG. 2, the controller 202 can cross-reference the received password with a password stored for the line/profile on which the call is received. If the passwords do not match, then the controller 202 deems the information to be incorrect and the method can proceed to step 304 and can be repeated. If the passwords do match, then the controller 202 deems the information to be correct and the method can proceed to step 310. At step 310, the controller 202 of the MTA 105 can allocate the handset 101-103 to the line/profile on which the call is received to permit the user to answer the call. For example, the controller 202 can augment the reference table 214 so that an identifier for the handset, for example, handset 102 in the scenario described above, is listed under the line/profile on which the call is received. Thereafter, the controller 202 can grant the handset access to the telephone call.

As indicated above, the prompt login feature permits a user to answer a call using an unauthorized handset before the caller hangs up or before the call is forwarded to a voicemail server. The login feature provides a significant advantage over MTA systems in which allocation of lines/profiles to handsets is relatively complex and is implemented during a system set-up.

With respect to outgoing calls, the MTA 105 can be configured to employ a default line for each handset. For example, when a handset prompts a user to enter a password to logon to a line/profile, as described above, the handset can also prompt the user to select an option to set the line/profile as the default line profile for the handset. In turn, in response to user-selection of the option and verification that the password is correct, the controller 202 can insert an identifier for the handset under the requested line/profile in the reference table 214 and can flag the identifier to indicate that the requested line/profile is the default line for the handset. Thus, when a user attempts to make an outgoing call with the handset, the controller 202 can automatically connect the handset to that handset's default line/profile to permit the user to make the outgoing call on the default line.

Alternatively, the system 200 can permit a user to select a line/profile on which to make an outgoing call. Referring to FIG. 4, with continuing reference to FIGS. 1-3, a method 400 for enabling a user to select a line/profile for an outgoing call in accordance with a login feature is illustrated. The method 400 can begin at step 402 in which a handset 101- 103 can receive an indication that a user is making an outgoing call. For example, the handset can detect when the user lifts the handset from a base or when a user selects a power- on button within the set of keys 226.

At step 404, the handset 101-103 can display a list of available profiles. For example, the handset can display the list automatically in response to receiving the indication that a user is making an outgoing call or can display the list in response to user-selection of a dedicated menu key from the set of keys 226. In addition, the list can include all available lines/profiles and can include icons to indicate to which of the available lines/profiles the handset is logged on. At step 406, the handset 101-103 can receive a line/profile selection. For example, the user can scroll through the list using a cursor and can select the line/profile using one of the keys 226, such as a "select" key. Alternatively, the list can have numbered entries for the lines/profiles and the user can select a digit among the keys 226 corresponding to the desired line/profile in the list.

Optionally, at step 408, the handset 101-103 can prompt the user to login to the selected profile. For example, the handset can perform step 408 if the handset is not logged onto the selected line/profile. In addition, as discussed above, the handset can prompt the user to enter a password to login to the selected line/profile.

Optionally, at step 410, the handset 101-103 can receive login information from the user, for example, as described above with respect to step 306.

Optionally, at step 412, the controller 202 of the MTA 105 can determine whether the login information is correct, for example, as described above with respect to step 308. If the login information is not correct, then the method can proceed to step 408 and can be repeated. If the login information is correct, then the method can proceed to step 414.

At step 414, the controller 202 can connect and log the handset on to the selected line/profile to permit the user to make an outgoing call.

It should be understood that for both incoming and outgoing calls managed in methods 300 and 400, respectively, the calls can be logged in corresponding logs 216-222 stored in the MTA 105.

In accordance with another exemplary aspect, the system 100 can be configured to permit a user to employ a handset to access at least a portion of one or more logs 216-222 for lines profiles to which the handset is not logged on in addition to the logs to which the handset is logged on. For example, the controller 202 can permit each handset 101-103 to access the last dialed telephone number and the telephone number of the last received call on each of the lines/profiles P.1-P.4 available on the user's premises 107. This feature can permit a user to receive a call on one line/profile, hang up and choose another handset logged into a different line/profile, or simply choose another line/profile from the same handset, to callback that same number. This feature can be useful if the user wishes to free up a main line so that he or she can receive other calls on the main line. Alternatively, the system can provide a user with a menu option to permit the transfer of the call to another line/profile.

In one exemplary scenario described herein below for illustrative purposes, it can be assumed that the telephone/handsets 101-103 are initially allocated to respective

lines/profiles P.1-P.3, where handset 101 is allocated line/profile P.l, handset 102 is allocate line/profile P. 2, etc., as discussed above. It can also be assumed that handsets are restricted from accessing or receiving calls on lines/profiles to which the handsets are not logged on.

With reference now to FIG. 5, with continuing reference to FIGS. 1, 2 and 4, a method 500 for transferring a call by employing call logs in accordance with an

implementation of the present principles is illustrated. The method 500 can begin at step

502, in which the system can conduct a call in accordance with VoIP. For example, the handset 101 can receive or make a call on line/profile P.l .

At step 504, the controller 202 and/or the handset 101 can store the telephone number of the current call. For example, the controller 202 can log the telephone number from which the call is received or to which the call was dialed in the log 216 for line/profile P.1.

Alternatively or additionally, the handset 101 can be configured to store the telephone number for the last call that was conducted on the handset.

At step 506, the controller 202 can terminate the call. For example, the user can direct the handset 201 to terminate the call for purposes of transferring the call to another profile/line.

Optionally, at step 508, the controller 202 can switch access to a different line/profile. For example, the user can simply hang-up handset 101 and use handset 102, which is logged into profile P.2 in the exemplary scenario described above. Alternatively, the controller 202 can change the line/profile to which the handset 101 is connected by permitting the user to select or log into another line/profile, such as P.2, by implementing the method 400 described above.

At step 510, the controller 202 can permit the user to access a log for another line/profile. For example, the user can employ handset 102, which is logged on to line/profile P.2, to access the log 216 for the line/profile P.l. Alternatively, the user can employ the handset 101 from line/profile P. 2 to access the log 216 for the line/profile P.1. Here, with either handset, the user can select a dedicated menu key from keys 226, in response to which the handset can display an option to view logs 216-222. In response to user-selection of the option to view the logs, the handset can display a list of the available logs and can permit the user to select any of the logs. In turn, the handset can transmit the log-selection, which in this case is log 216 for line/profile P.l, to the controller 202. The controller 202 can then provide the handset with a full log for the line/profile P.l, or simply the last received or last dialed telephone number, which can then be displayed to the user on the handset. It should be understood that the handset can be given the same access to any of the other logs in a similar manner. Further, any other handset can be given the same access to any of the logs in the same manner described. However, in accordance with an alternative embodiment, the controller 202 can be configured to permit unfettered access to log information of all profiles/lines only from lines/profiles that have been given administrator privileges. If the user attempts to access the call logs from another profile by using a profile without administrator privileges, an override password can be provided to permit temporary access to the call logs.

At step 512, the controller 202 and/or the handset 101/102 can receive a selection of a telephone number from previous call. For example, after displaying the call log 216, or a portion of the call log 216, the user can select the last received/last dialed call on the line/profile P.l from the handset display 224. In turn, the handset can transmit the selection to the controller 202.

Thereafter, the method can proceed to step 514, in which the controller 202 can establish call with the selected telephone number on the line/profile to which the controller 202 had switched access at step 508. For example, the controller 202 can dial the selected telephone number on the corresponding line/profile to which the handset 101/102 is logged on and connected. The line/profile can be a default line/profile or can be selected by the user, as discussed above with respect to FIG. 4.

In accordance with another exemplary aspect, after step 512, the method can proceed to step 513, in which the controller 202 can copy the telephone number, selected as described with respect to step 512, to a contact list associated with the profile on which the telephone handset 101/102 is logged on and connected. For example, in response to user-selection of the telephone number, several options can be displayed including a "transfer call" menu option, described further herein below, and a "transfer to contact list" menu option. In response to user-selection of the "transfer to contact list" option, the controller 202 can copy the telephone number to the contact list associated with the profile on which the telephone handset 101/102 is logged on and connected, which, in the example provided above, is profile P.2. The controller 202 can store a contact list for each profile in the storage medium 212, in addition to other information about the profile.

It should be noted that although steps 510-514 have been described with respect to a call transfer scenario, steps 510-514, with or without step 513, can be performed at any time by any one or more of the handsets. In particular, step 510 can be performed at any time to permit the user to access the call log of a line/profile from a handset that is different from the line/profile to which the handset is logged on and connected.

As indicated above, the method 500 can optionally permit a user to employ a "transfer call" option. For example, after step 512, the method can proceed to step 516, in which the handset 101 can display the "transfer call" option in response to user-selection of a telephone number in the call log 216 at step 512. It should be noted that in this scenario of displaying a transfer call option, step 508 can be skipped. For example, in the example provided above, the switch to a different handset/profile is not performed and the user remains on the handset 101 on line/profile P.l after completion of step 512. Alternatively, the method can proceed to step 516 after terminating the call at step 506. For example, after terminating the call at step 506, the user can select a menu option to transfer the call to another handset. For example, the user can prompt the display of a menu by selecting a menu-designated key from the set of keys 226. Further, the menu can display a "transfer call" option for user-selection.

At step 518, the controller 202 and/or the handset 101 can receive the user-selected menu option to transfer the call to another line/profile. Here, the call can correspond to the telephone number selected at step 512 or to the call terminated at step 506.

At step 520, in response to user-selection of the transfer call option in step 518, the handset 101 can simply display the listing of other available handsets 102-103 along with a listing of lines/profiles to which each of the handsets are logged on. The listing of handsets and corresponding lines/profiles can be stored at the handset 101 and updated periodically or can be received from the controller 202 each time a user selects the "transfer call" option, where the controller 202 compiles the listing of other handsets and corresponding lines/profiles from the reference table 214. Further, the user can select a corresponding handset to which the call should be transferred and a corresponding line/profile to which the selected handset is logged on.

In turn, at step 522, the controller 202 can receive an indication of the selected handset and selected line/profile from the handset 101.

Thereafter, the method can proceed to step 514, in which the call can be established on the new line/profile selected at step 522. For example, the controller 202 can dial the telephone number of the call corresponding to the call selected in accordance with step 512 or to the call terminated at step 506. The controller 202 can receive the telephone number selected in accordance with step 512 from the handset 101. Alternatively, where step 516 is performed after step 506, as indicated in FIG. 5, the handset 101 can transmit to the ₃ controller 202 a predetermined code indicating that the telephone number of the last call conducted on the handset 101 should be dialed with the indication of the handset and line/profile selected by the user for the transfer. Thereafter, in either case, the selected handset can automatically ring and, when the user turns on the selected handset, the controller 202 can dial the telephone number of the call, as stated above, to establish the call on the selected line/profile.

The MTA system 105 can also employ and configure the call logs to address other problems. For example, as mentioned above, in current VoIP systems, if a user answers a call that is intended for or made to a first profile with a handset that is on a second profile, the call is logged only on the call log for the second profile. Thus, the first profile has no record of a call that should be associated with its line/profile. In accordance with one exemplary aspect, the MTA 105 can log a call both on the call log associated with the profile to which the call is made and the call log associated with the profile on which the call is answered. This aspect can permit the user of one line/profile, such as a father in a household, to see that a call to his line was answered by another line/profile. Then, the user of the line to which the call was intended or made can inquire as to what the call was about.

For example, referring to FIG. 6 with continuing reference to FIG. 2, a method 600 for logging a telephone call in accordance with an exemplary embodiment is illustrated. The method 600 can begin at step 602, in which the MTA 105 can receive a call on a first profile in accordance with VoIP. For example, the MTA 105 can receive the call on line/profile P.l, to which the handset 101 is logged on. In addition, the MTA 105 can be configured to cause one or more of the handsets 101-103 to ring in response to receiving the call.

At step 604, the MTA 105 can connect the call to a handset logged on to a second profile. For example, the MTA 105 can cause one or more of the handsets 101-103 to ring and a user can lift or power on a handset 102, in response to which the MTA can connect the handset 102 to the first profile. Here, the handset 102 can be logged on and connected to a profile, such as profile P. 2, that is different from the profile on which the call is received.

At step 606, the MTA 105 can be configured to log the call on both the first and second profiles. For example, in the example provided above, the MTA 105 can be configured to log the call in both the log 216 for the line/profile P.1 and the log 218 for the line/profile P. 2.

As discussed above, another problem associated with currently available multimedia terminal adapters is that all handsets ring when a call is received on any given line/profile, including handsets that are not allocated to the line/profile on which a call is received. According to one exemplary feature, each handset can be configured to ring for incoming calls such that the handset rings only for calls received on lines associated with profiles to which the handset is logged on. For example, the MTA 105 can be configured to forward calls received on a line/profile to only those handsets to which a line/profile is logged on. In another example of the feature, the handset itself can be configured to determine whether a received call is intended for a line/profile to which the handset is logged on and can be configured to cause itself to ring only for those calls received on the a line/profile to which the handset is logged on.

With reference to FIG. 7, with continuing reference to FIGS. 2 and 5, a method 700 for forwarding incoming calls in accordance with an exemplary implementation is illustrated. The method 700 can correspond to the first option provided above and can begin at step 702, in which the MTA 105 can receive an incoming call on a line/profile in accordance with VoIP. At step 704, the controller 202 can determine the handset or handsets to which the call should be forwarded. For example, as discussed above, the reference table 214 can indicate to which line(s)/profile(s) each handset is logged on. Further, the controller 202 can identify the line/profile on which a call is received and can use the table 214 to cross-reference the line/profile with the handsets that are logged on to the line/profile on which the call is directed. At step 706, the controller 202 can forward the call to only those handsets that are logged on to the profile on which the call is received. In this way, the MTA 105 can restrict handsets that are not logged on to a line/profile on which a call is received from ringing when the call is received, and thereby prevent such handsets from answering the call. It should be noted that, according to one exemplary aspect, a line can be dedicated for each handset or subscriber line interface card (SLIC). For example, the reference table 214 can be configured such that only one device entry can be made for each line/ profile.

Referring to FIG. 8, with continuing reference to FIG. 2, a method 800 for restricting handsets to ring for incoming calls to which the handsets are logged on using a monitoring feature is illustrated. The method 800 can correspond to the second option provided above and can be performed by any one or more of the handsets 101-103. The method 800 can begin at step 802, in which the handset can receive an incoming call on a line/profile from the MTA 105 in accordance with VoIP. Further, the handsets can monitor the lines/profiles on which calls are received and can cause itself to ring only if it is logged on to the lines/profiles receiving the call. For example, at step 804, the handset can identify the line/profile on which call is received. For example, the controller 202 can transmit an identifier code with each call to permit the handset to determine the line/profile on which a _{] 5} call is received. At step 806, the handset can determine whether the handset is logged on to the line/profile on which the call is received. For example, as discussed above with regard to FIG. 5, each handset can keep a listing of lines/profiles to which the handsets are logged on. Thus, here, the handset can compare the identified line/profile with the listing to determine whether the handset is logged on to the identified line/profile. If the handset is not logged on to the identified line/profile, then the method can proceed to step 802 and can repeat for another call. If the handset is logged on to the line/profile on which the call is received, then the method can proceed to step 808, in which the handset can direct itself to ring to permit the user to answer the call. Accordingly, the handset can restrict itself from ringing when a call is received on a line/profile to which the handset is not logged on, and thereby prevent a user from answering a call using the handset. As described above, for example with respect to FIG. 3, the restriction, in either method 700 or method 800, can be overridden by providing an appropriate password. For example, the user can hear an incoming call on an authorized handset in another room and can employ the login feature to answer the call from a handset that is not logged on to the line/profile on which the call is received.

It should be understood that the ring restriction features can be configurable by line/profile. Furthermore, the features can prevent calls from ringing on handsets in undesirable situations. For example, the features can prevent calls received on a line/profile P.4 dedicated to a fax device 104 from ringing all handsets. The features can also prevent users, such as children, from answering a business line.

Alternatively, an SLIC line can be configured as a dedicated FAX line and the system can be configured such that a handset on any other SLIC or wireless handsets do not ring on incoming calls for the dedicated fax line. Further, to implement a dedicated line for an other device 104, the methods 700 and 800 can be modified. For example, at step 704, the controller 202 can identify the line/profile on which a call is received and can use the table 214 to cross-reference the line/profile with the devices that are logged on to the line/profile on which the call is directed. Here, if the call is directed to an other device 104, then the method can proceed to step 706, in which the controller 202 can forward the call to only the other device 104. If the call is not directed to an other device 104 (i.e., the call is directed to one of the handsets), then the controller 202 can forward the call to one or more handsets, including those that are not logged on to the profile on which the call is received. Similarly, with regard to method 800, at step 804, the handset can determine whether the line/profile on which the call is received is dedicated to an other device 104. For example, as discussed above, the handset can employ a listing of profiles and associated devices and can employ identifier codes transmitted from the controller 202 with the call. Here, if the call is directed to a line/profile dedicated to an other device 104, then the handset can restrict itself from ringing and the method can proceed to step 802 in which the handset can receive another call. Otherwise (i.e., the call is directed to one of the handsets), the handset can be configured to ring.

It should be understood that any of the capabilities described herein with respect to any one of the handsets 101-103 can be applied to the other handsets as well.

Having described preferred embodiments for MTA systems and methods (which are intended to be illustrative and not limiting), it is noted that modifications and variations can be made by persons skilled in the art in light of the above teachings. It is therefore to be understood that changes can be made in the particular embodiments disclosed which are within the scope as outlined by the appended claims. While the forgoing is directed to various embodiments, other and further embodiments can be devised without departing from the basic scope thereof.

Claims

Claims:

1. A method, comprising the steps of:

prompting a user to logon to a handset to a profile on which an incoming call is received in accordance with Voice over Internet Protocol;

receiving login information from the user; and

allocating the handset to the profile on which the call is being received to permit the user to answer the call.

2. The method of claim 1, further comprising the step of:

logging on the handset to the profile and at least one other profile after the allocating is performed.

3. The method of claim 2, wherein the login information is an administrative password permitting the user to access each of the profiles.

4. The method of claim 1 , the receiving an incoming call step further comprises the step of:

directing the handset to ring while restricting the handset from answering the call prior to allocation of the handset to the profile.

5. The method of claim 4, the step of prompting further comprises the step of: displaying a notification that identifies at least one other handset that is logged on to the profile on which the call is being received.

6. The method of claim 1, the step of receiving an incoming call further comprises the step of:

restricting the handset from ringing; and

performing the prompting in response to user-selection of an option to logon to the profile that is displayed on the handset.

7. A system comprising:

a plurality of Voice over Internet Protocol telephone handsets; and

a. multimedia terminal adapter - MTA configured to log on at least a first handset of the plurality of handsets to one or more profiles in response to receiving log in information from the first handset.

8. The system of claim 7, wherein the first handset is configured to be

simultaneously logged on to a plurality of the profiles.

9. The system of claim 7, wherein each of the handsets is logged on to at least one profile and wherein each handset is configured to ring for incoming calls such that the handset rings only for calls received on lines associated with profiles to which the handset is logged on.

10. The system of claim 7, further comprising:

at least one device other than a telephone handset, wherein the plurality of telephone handsets are restricted from ringing when a call is received by the MTA on a line to which the at least one other device is logged on.

11. The system of claim 7, wherein the first handset is further configured to display a menu of profiles associated with respective telephone lines provided through the MTA.

12. The system of claim 1 1, wherein the MTA is further configured to connect the first handset to the telephone line associated with one of the profiles selected by the user through the menu for an outgoing call.

13. The system of claim 7, wherein the MTA is further configured to log the first handset on a first profile of the one or more profiles as a call is received on a telephone line associated with the first profile in response to receiving login information for the first profile from the first handset.

14. A system comprising:

a plurality of Voice over Internet Protocol telephone handsets; and

a multimedia terminal adapter - MTA configured to store a respective call log for each profile associated with respective telephone lines provided through the MTA such that at least a portion of a call log for a first profile is accessible by a handset that is not logged on to the first profile.

15. The system of claim 14, wherein the at least a portion of the call log is the telephone number for the most recent call conducted on the first profile.

16. The system of claim 14, wherein the at least a portion of the call log is the entire call log associated with the first profile.

17. The system of claim 14, wherein the handset that is not logged on to the first profile is a first handset and wherein the MTA is configured to employ the call log for the first profile to dial a telephone number in the call log for the first profile on a line associated with a profile to which the first handset is logged on.

18. The system of claim 17, wherein the MTA is configured to automatically dial the telephone number on the line associated with a profile to which the first handset is logged on in response to user-selection of an option to transfer a call, wherein the option is displayed on a second handset that is logged onto the first profile.

19. The system of claim 14, wherein the call log associated with the first profile includes information identifying at least one of the profile or the handset on which a call is answered, wherein the call is made to the first profile and the call is answered on a profile that is different from the first profile.

20. The system of claim 19, wherein the call is logged on both the call log associated with the profile to which the call is made and the call log associated with the profile on which the call is answered.