1. Field of the Invention
The present invention relates to the field of telecommunications. More particularly, the present invention relates to Find-Me-Follow-Me features provided in a telephone system.
2. Background Information
Presently, a number of public switched telephone networks (PSTN) and advanced intelligent networks (AIN) enable dynamic interaction between their customers and their respective service accounts. Servers, databases, intelligent peripherals and other external data network elements interface with the PSTN/AIN to process and store information created during routine handling of telephone calls.
For example, U.S. Pat. No. 6,603,973 B 1 entitled Call Redirection System by Foladare et al. describes a telephone network arranged to give a telephone call placed to a called party's personal telephone number a particular call treatment. The call treatment is selected as a function of the particular one of a plurality of predefined areas in which the called party is determined to be located. Each of the plurality of predefined areas has at least two telephone stations with different telephone numbers located therein. The location of the called party is determined from the location of a two-way pager associated with the called party as detected by a paging antenna, e.g., tower, of a conventional two-way paging system that was not necessarily installed for use in completing telephone calls. For each personal telephone number, a table is stored associating a call treatment with one or more of the areas. The particular call treatment associated with an area is applied to calls to the personal telephone number when he is within that area.
Known Follow-Me-Find-Me (FMFM) systems allow a calling party to select an FMFM option when a subscriber does not answer the telephone. When selected FMFM calls a series of contact numbers, designated by a subscriber, to locate the subscriber when he/she does not answer the telephone. FMFM is typically associated with a single subscriber and does not support multiple users at a single telephone number.
The present invention provides a method and apparatus for a shared line Find-Me-Follow-Me (FMFM) function in a voicemail enabled telephone system. The FMFM function (referred to as “FMFM”) runs as an application for a VoIP telephone system or directly implemented in the voice network switching infrastructure of a telephone system. A plurality of mailboxes, referred as sub mailboxes are created and assigned to a single subscriber telephone number. Each person sharing a telephone number is provided a sub mailbox with FMFM contact numbers individually configured for each user sub mailbox. The present invention further provides a method and apparatus for dynamic out dial determination that dynamically removes numbers from the FMFM contact number list that match numbers in the inbound call path to avoid looping. The present invention further provides a method and apparatus for FMFM call path duplication of the inbound call path onto the out dial call information to provide caller identification for the original calling party after the call is forwarded or processed using FMFM.
Call path duplication copies the original calling party's telephone number (when available) to the out-dialed line so that the called party and the called switching equipment see the original calling number even after the call has been forwarded. A subscriber can identify a calling party from a forwarded call without answering the telephone using caller identification. Thus, it is an aspect of the present invention to provide multiple FMFM sub mailboxes associated with a single subscriber telephone number to accommodate multiple end users at the subscriber telephone line. It is another aspect of the present invention to avoid looping and unnecessary dialing in the implementation of FMFM style services in a telephone system. It is another aspect of the invention to provide caller identification on forwarded calls to an end user of FMFM services. These and other aspects of the invention will be described in the following description and figures.
Examples of certain features of the invention have been summarized here rather broadly in order that the detailed description thereof that follows may be better understood and in order that the contributions they represent to the art may be appreciated. There are, of course, additional features of the invention that will be described hereinafter and which will form the subject of the claims appended hereto.
For detailed understanding of the present invention, references should be made to the following detailed description of an exemplary embodiment, taken in conjunction with the accompanying drawings, in which like elements have been given like numerals.
In view of the above, the present invention through one or more of its various aspects and/or embodiments is presented to accomplish one or more objectives and advantages, such as those noted below.
The Find-Me-Follow-Me function (FMFM) is a feature added to voicemail and IVR systems as well as directly implemented in the voice network switching infrastructure such as an FMFM or Single Number Reach (SNR) application in a PSTN, VoIP or AIN telephone system. When a caller calls an FMFM subscriber's telephone number and the number is busy or is not answered, the call is forwarded to a Unified Communication (UC) platform where the FMFM features of the present invention are implemented. The telephony portions of the FMFM reside in a Telephone User Interface (TUI) and the subscriber interface and screen functions reside in the Web Server. Assuming that the subscriber has FMFM activated, the caller will be given the opportunity to go straight to voicemail to leave a message or wait while the FMFM system at the UC platform calls subscriber designated contact telephone numbers in an attempt to find the subscriber.
The present example of the invention provides enhanced FMFM features such as sub mailbox determination, call path duplication, and dynamic out dial as improvements to an FMFM service. In the past, services such as FMFM and Single Number Reach (SNR) have been associated with a single end-user (subscriber) at a single telephone number. That is, in the past, multiple end-users per telephone number were not supported by FMFM or SNR. SNR is similar to FMFM in terms of what the caller hears once the service is activated. The difference is, FMFM is tied to the subscriber's voicemail service and SNR has a special telephone number for callers to call. An SNR customer will give out their SNR number instead of the home number or wireless number. FMFM customers provide telephone numbers where they might answer the telephone such as their home, office, or wireless telephone numbers. The improvements described herein are applicable to all call forwarding applications, including but not limited to FMFM and SNR. The present example discusses the improvements provided by the present invention in the context of an FMFM service. The present invention, however, is not limited to FMFM, voice mail or Unified Messaging Service applications.
Prior FMFM and SNR implementations generally worked as follows: A caller called an FMFM subscriber. FMFM asked the caller to speak their name after a beep or hit 1 for FMFM or otherwise go to voicemail. If requested by the caller, FMFM called the FMFM contact number(s). When a party at a contact number answered, FMFM asked the called party if they wished to accept a call from a “calling party name.” The called party either accepted the call or allowed it to go voicemail without being accepted. This prior FMFM and SNR scheme worked well when there is only one person associated with the dialed telephone number. However, FMFM and SNR did not work for more than one person at the telephone number.
Thus, prior FMFM systems had an inherent disadvantage. Taken in the context of families, individual family members could not fully utilize FMFM as a feature on their voicemail. There was no way to provide individual FMFM contact numbers for each family member. For example, mom and dad probably had different wireless numbers they wanted to designate as a contact number. They could not use separate contact numbers using a prior FMFM system.
The present example of the invention provides an improvement over prior FMFM systems by providing separate mailboxes (sub mailboxes) containing individual contact numbers for each family member at a single home telephone number. A plurality of mailboxes, referred to as a group mailbox is assigned to the family telephone number. Each of the mailboxes, referred to as sub mailboxes is assigned to an individual family member, with associated contact numbers. The FMFM service provided in the present example of the invention allows each family member to have their own mailbox with their own FMFM contact number(s) and FMFM settings configured within their sub mail box. Each family member can configure their own FMFM settings, such as FMFM enable, Key Contact List (KCL), contact phone numbers and number of rings. Selection, editing, utilization and storage of the FMFM settings is discussed below.
For example, a typical family household contains two parents and two children. A caller dialing the family home telephone number would expect to get one of the four family members. Configuring an FMFM service with a group mailbox and sub mailboxes directs all calls through an individualized FMFM sequence design by the user for whom the call was intended.
In an FMFM sub mailbox scenario, in the present example of the invention, a caller calls the family home number. The home number is busy or rings without answering. The caller is forwarded to FMFM. In the context of the present example, FMFM refers to an FMFM enabled service or system. The caller will hear a special greeting: “To leave a message for <person #1>, press 1. To leave a message for <person #2>, press 2. To leave a message for <person #3>, press 3. To leave a message for <person #4>, press 4.” Thus, each FMFM user has their individually configured FMFM service with individual contact numbers and voice mail greetings associated with the user's sub mailbox. The user sub mailbox is determined by a caller selection process, before the FMFM out dial service is accessed. Thus one aspect of the present invention is the provision of sub mailboxes for use by multiple FMFM users at a single telephone number.
Another aspect of the present invention is call path duplication. Call path duplication preserves the original calling party telephone number after the call has been forwarded to subsequent telephones. The original calling party is identified in the inbound call path as the caller in the initial call to the FMFM subscriber. That is, the telephone number from which the call initiated is preserved and passed along with the call as the call is forwarded to the UC and subsequent contact numbers. The subsequent forwarding telephones are listed as redirecting numbers in subsequent calls while the original calling party number is inserted the calling party number in subsequent calls. Call path duplication enables a called party to identify the caller through caller identification before answering the telephone.
The present example of the invention provides call path duplication as an improvement to prior FMFM and SNR services which have relied on a challenge response system to determine and communicate the caller's identity to a subscriber. This provides an improvement over the challenge response method of caller identification where a caller is asked to speak their name, which is repeated to a called party when answering the telephone. At a high level, prior FMFM and SNR implementations performed the following challenge response functions: Ask a calling party to speak their name after a beep or hit 1 to go directly to voicemail. When the caller speaks their name, the system recorded it for playback to the FMFM subscriber. The system then called each contact number in order. When one of the FMFM contact numbers was answered by the subscriber, the system asked the called party if they wished to accept a call from “calling party name.” The recording of the caller's name was then played back for the called party. The called party then either hit a 1 to accept the call or sent it to voicemail without accepting it.
Thus, the prior challenge response FMFM implementation could give the caller the feeling they were being screened and also forced the called party to answer the phone to see who was calling and decide if they wanted to take the call. The present example of invention provides call path duplication, which eliminates the experience of recording, replaying and approving a calling party name.
In another aspect of the invention call path duplication copies the inbound call path (or portions of it) into the outbound call path information for a outbound call. That is, on forwarding a call or for each out dial call that FMFM makes to contact a subscriber, the original call initiating telephone number (when available) and each Redirecting Number (RDN) from which the call was forwarded, are duplicated and inserted on the out dialed calling information line. Thus the called party and the called party's switching equipment see the same calling party calling information that the FMFM service saw on the original call, except that the called number has changed. This keeps the original calling party's telephone number available for caller identification by the FMFM subscriber.
The call path duplication aspect of the present invention improves prior systems. Call path duplication speeds up the approval and connection time between a calling party and a called party. Also, a subscriber can identify an incoming call by glancing at a caller identification number and name when available, without answering the telephone and listening to a recorded name announcement. Thus, call path duplication provides a better experience for both the subscriber called party and the calling party in a call forwarding and FMFM scenario.
Another aspect of the present invention provides a dynamic out dial feature. Dynamic out dial skips telephone numbers appearing on an FMFM or SNR out dial contact number list that have already been tried. Dynamic out dial provides a better caller and subscriber experience by providing quicker connection time by eliminating looping and futile retries of FMFM contact numbers Dynamic out dial skips contact numbers that appear in an inbound calling path as an RDN or as a calling party number (CN).
The dynamic out dial FMFM feature also lowers service provider costs by lowering the number of out dials made on system equipment. Dynamic out dial speeds up the connection time between the caller and called party by skipping contact numbers which have been tried or are known to be busy. Dynamic out dial also results in fewer calls being abandoned because caller wait times are reduced, thereby providing a better subscriber experience. The dynamic out dial feature of the present invention dynamically adapts to each call scenario to provide the best out dial choice possible.
Dynamic out dial also minimizes the potential for looping with-in FMFM and call forwarding services, thereby lowering the potential for adverse feature interaction. The looping problem occurred in prior FMFM systems as follows. Prior FMFM systems called a list of one or more out dial contact numbers to reach a called party on behalf of a calling party. When FMFM was tied into call forwarding arrangements, call-looping problems could occur between phone numbers using each other as an FMFM contact number or call forwarding number (CFN). The following loop example illustrates the problem. A caller calls “Bob” at work. Bob is out of the office and has all of his work calls forwarded to his wireless telephone number. Bob is busy talking on his wireless phone so the wireless network forwards the call to a network voicemail system that supports FMFM. Bob has configured his FMFM service to call him at the following FMFM contact telephone numbers, in the following order: Wireless Phone; Office Phone; and Home Phone.
The FMFM service will dial Bob's wireless phone number first. The wireless phone will not be answered because Bob is busy talking on it. The FMFM system will forward the call from the wireless number to voicemail where it will activate (again) the FMFM service. The FMFM system will then try the next contact number, Bob's office phone. Bob's office phone is forwarded to the wireless phone. After forwarding, the call will end up back into the wireless phone's voicemail where it will reactivate the FMFM service. Next the system will try the home phone.
In this example, the caller's telephone number, Bob's office number, and Bob's wireless number are in the inbound call path for the voice mailbox. Numerous FMFM and SNR implementations avoid the looping problem outlined above by not allowing the voice mailbox number to be one of the numbers used to find the subscriber. However, given that integrated wireless and wire line voice mailboxes have become available in the past few years, the solution of disallowing mailbox numbers from the FMFM dialed number list potentially reduces value of the FMFM service.
Looping, as described above, is eliminated by the dynamic out dial feature provided by the present invention. Dynamic out dial removes numbers from the out dial list that match numbers that are in the inbound call path. Numbers that appear in the inbound call path have already been tried and not answered or are known to be busy. Notice the inbound call path in the above example contained looping problem numbers.
The dynamic out dialing feature of the present invention eliminates the looping problem by removing the inbound call path numbers from the list of FMFM contact numbers, which removes looping from the prior example to the following scenario: A caller calls “Bob” at work. Bob is out of the office and has all of his calls forwarded to a call forwarding number (CFN), his wireless number. Bob is busy talking on his wireless phone so the wireless network forwards the call to a voicemail system that supports dynamic out dial FMFM.
Bob has configured his FMFM service having dynamic out dial to try him at the following contact numbers telephones in order: Wireless Phone; Office Phone; and Home Phone. In the prior example, without dynamic out dial, the FMFM service would have dialed Bob's wireless phone number first. However, Bob's wireless phone is the last RDN and therefore appears in the inbound call path. When a number appears in the inbound call path, there is no reason to try it again as it has already been tried and was not be answered or is the calling party so the line is occupied. Thus, the dynamic out dial skips the wireless number as it is in the inbound call path.
FMFM without dynamic out dial would have tried Bob's office phone next. Since the office phone is the first RDN, it appears in the inbound call path. Dynamic out dial determines, since the office phone is in the inbound call path as an RDN, that the system has already tried the office phone number and found that Bob did not answer. The dynamic out dial feature uses this information and skips the office phone number and goes on to the next number in the out dial list. Next dynamic out dial will try the home phone, since the home phone is not in the inbound call path.
In the above dynamic out dial scenario, the calling number and any of the redirecting numbers are in the call path. If we change the dynamic out dial FMFM example above to where Bob's wife is calling Bob from their home number, then all possible contact numbers will be in the inbound call path. The dynamic out dial feature determines that all of the contact numbers are in the inbound call path, have already been tried or are in use and will send the calling party call directly to voicemail.
Another FMFM option is to connect the calling and called party connected together when the called party answered the call, so that the called party does not have to listen to a message, i.e. caller's name, or press a digit to accept the call. This option may not be desirable as there is a significant chance, however, that the called number will end up terminating on an answering machine or call answering service such as voicemail. When the call terminates on an answering service, the FMFM service should continue trying the next number in the contact number list or send the caller (if at the end of the list) to voicemail. Thus, pressing a digit to accept a call is an available option, even with the provision of call path duplication.
The call path duplication FMFM feature of the present invention preserves the initiating calling party's Caller identification information on the out dialed call. The called party can accept or reject the call based on the Caller identification information. FMFM with call path duplication activates after the subscriber sub mailbox has been identified. This makes the call path duplication FMFM feature compatible with Group Mailboxes. That is, if the mailbox is a group mailbox, the caller selects the individual mailbox they wish to contact or leave a message. Once the caller has selected a sub mailbox, if FMFM is activated, FMFM will call the contact numbers associated with that specific sub mailbox.
Another aspect of the present invention provides a system for implementing an FMFM service that includes a unified communication (UC) platform, which processes telephone calls from a public switched telecommunications network (PSTN), an interactive voice response (IVR) system provided by a Telephone User Interface (TUI) and a graphic user interface (GUI). The UC platform includes a database of FMFM settings that corresponds to the subscriber telephone number. The IVR system is accessible by the subscriber from any dual tone multi-frequency telephone through a PSTN.
The subscriber receives the FMFM settings for review via GUI or TUI and adjusts the FMFM settings to control the FMFM service using either the Dual Tone Multiple Frequency (DTMF) telephone and IVR or the GUI. The UC platform receives the FMFM settings from the subscriber, from either the dual tone multi-frequency telephone or the graphical user interface, and communicates the FMFM service to a Master Directory Sever (MDS), which updates the FMFM settings. The UC platform then processes calls to the telephone number of the subscriber in accordance with the updated FMFM settings. A separate set of FMFM settings are associated with each sub mailbox associated with the subscriber telephone number.
Another aspect of the invention provides a system for implementing an FMFM that includes a UC platform, which processes telephone calls in a Voice Over Internet Protocol (VoIP) telephone network. The UC platform provides the MDS, an LDAP Server for storage of FMFM settings for sub mailboxes corresponding to a subscriber's telephone number.
The UC platform also includes a Web server, through which the FMFM subscriber receives at a GUI the FMFM settings and updates FMFM settings through a packet switched data network. There is also an TUI implementation of an IVR through which the subscriber receives at a dual tone multi-frequency telephone the FMFM settings to update the FMFM service through the public switched telecommunications network.
The FMFM settings updates can include but are not limited to FMFM contact numbers, assigning sub mailboxes, setting ring counts and setting greetings for each sub mailbox. FMFM updates the subscriber's FMFM settings in accordance with the user's input. FMFM running at the UC platform then processes incoming calls to the subscriber's telephone number in accordance with the updated FMFM settings.
In another aspect of the present invention, the FMFM settings also include a Key Contact List (KCL), which contains at least one telephone number. A subscriber or user can create and edit the KCL. The address book of incoming and outgoing telephone numbers can also be added to the KCL. If the KCL only option is turned on, whenever a call is placed from a telephone number which appears on the KCL to the subscriber's telephone number, the call is selectively processed by the FMFM. The selective processing includes forwarding the KCL call to a contact number, while a call from a telephone number not on the KCL is not forwarded. Alternatively, a non-KCL call may be forwarded to a contact number, if all calls active is selected to activate the FMFM service.
The subscriber receives the FMFM settings and sends KCL instructions to control the KCL from the graphical user interface by way of the Web server. The KCL control instructions can include adding a new telephone number to the KCL and removing one of the KCL telephone numbers from the priority screening list. The FMFM platform then updates the KCL in accordance with the KCL instructions and processes calls to the subscriber's telephone number of the subscriber in accordance with the updated FMFM settings.
Another aspect of the present invention provides for a method of implementing a dynamic out dialing service. The method includes removing numbers from an FMFM out dial list of contact numbers that appear in an inbound call path as a calling party number or as a redirecting number.
Another aspect of the present invention provides for a method of implementing call path duplication. The method includes receiving a call from a first telephone at a second telephone, the call having a calling party number associated with the first telephone and forwarding the call to a third telephone number. The call forwarded has the calling party number for the first telephone inserted as the calling party telephone number in the call from the second telephone to the third telephone.
The following is a brief discussion of a Public Switched Telephone Network (PSTN) and a Voice over Internet Protocol Telephone System which will aid an understanding the invention.
There are four major tasks performed by the PSTN to connect a call. While the PSTN is capable of providing other services beyond point-to-point voice calls such services are predicated upon the following basic tasks: (1) signaling; (2) database services; (3) call set-up and tear-down; and (4) analog voice to digital data conversion.
Phones calls are inherently connection oriented. That is, a connection to the called entity must be established ahead of time before a conversation can occur. Switches, the central components in the PSTN, are responsible for creating this connection. Between the circuit switches are connections (trunk lines) that carry the voice traffic. These links vary in data communication speed from T-1 and E-1 to OC-192/STM-64, with individual channels (DS-Os) in each link type representing one voice channel. Switches are also responsible for converting the analog voice signal into a digital data format that may be transported across the network.
Signaling notifies both the network and its users of important events. Examples of signaling range from telephone ringer activation to the dialing of digits used to identify a called entity. Network elements also use signaling to create connections through the network. The Signaling System Seven (SS7) is a standard, packet-based network that transports signaling traffic between the switches involved in the call.
A call begins when a user dials a destination phone number using call origination equipment. A local switch typically analyses the destination number to determine if the call is a local one. If the call is local, the local switch may directly connect the call. More typically, the dialed telephone number results in a query to one or more service control points (SCP). SCPs are databases that execute queries and translate the dialed telephone phone numbers into a set of circuit switching commands. SCPs also allow such common telephone features as 800 number support, 911 service, and caller identification. Signaling switch points (SSP) are the interface between switches and the SS7 network. It is here that SS7 messages are translated into the connection details required by the switches to physically connect the call origination point to the call destination point.
The SS7 control network is “out of band,” that is, it is not transmitted within the same links used to carry the actual voice channels. Specialized equipment called Signal Transfer Points (STPs) transport the SS7 signaling messages. As will be seen hereafter, these STPs are analogous to IP routers in that the messages are carried in data packets called message transfer parts.
Like the PSTN, components forming a VoIP network must perform four basic functions: (1) signaling; (2) database services; (3) call connection and disconnection (bearer control); and (4) Coder/decoder (CODEC) operations. An IP backbone provides connectivity amongst a great number of distributed elements. The IP Backbone can be viewed as one logical switch. The logical switch is, however, a distributed system. Depending on the VoIP protocols used, this system as a whole is sometimes referred to as a soft switch architecture.
Signaling in a VoIP network is just as critical as it is in the legacy phone system. The signaling in a VoIP network activates and coordinates the various components to complete a call. Although the underlying nature of the signaling is the same, there are some technical and architectural differences.
Signaling in a VoIP network is accomplished by the exchange of IP datagram messages between network components. The format for these messages is covered by a number of standards, or protocols. Regardless of the protocol or hardware components used, the messages are critical to the function of a voice-enabled IP network and need special treatment to guarantee their delivery across the IP backbone.
Among other functions, database services are a way of locating an endpoint and translating an address communicated between two (usually heterogenous) networks linked by the VoIP backbone. For example, the PSTN uses phone numbers to identify endpoints, while a VoIP network might use a Universal Resource Locator (URL) or an IP address with port numbers to identify an endpoint. A call control database contains the necessary mappings and translations to identify endpoints. Functionally similar to call state and call control in the PSTN, “session state” in a VoIP network defines the nature of the call and controls the activities of components in the network.
The connection of a call in a VoIP network is made by two endpoints opening a communication session between each other. In the PSTN, the public (or private) switch connects logical DS-0 channels through the network to complete a call. In a VoIP implementation, this connection can be a multimedia stream (audio, video, or both) transported in real time between endpoints. This connection is referred to as the bearer (or payload) channel and represents the voice or video content being delivered. When communication is complete, the IP session is ended and network resources are released.
As already noted, voice communication is analog, while data networking requires digital data. The process of converting analog voice into digital data is done by a coder-decoder (CODEC). There are many well known ways to convert analog voice into digital data. The processes used to convert, compress, and otherwise manipulate voice data in digital form are numerous and complex. Most are governed by publicly available standards.
The major components of a VoIP network are similar in functionality to the components forming a circuit-switched network. VoIP networks must perform all of the same tasks performed by the PSTN, in addition to providing a gateway between the VoIP network and the existing PSTN. Although using different technologies and approaches, some of the same component concepts that make up the PSTN are found in VoIP networks. There are three general components forming a VoIP network: (1) gateways; (2) gateway controllers or gate keepers; and (3) the IP backbone.
Gateways are responsible for call origination, call detection, and CODEC functions, including at least analog-to-digital conversion and voice packet creation. In addition, gateways have optional features, such as data compression, echo cancellation, silence suppression, and statistics gathering. Gateways form the interface allowing voice data to be transported across the IP network. In other words, gateways are the source of bearer traffic. Typically, each call is a single IP session transported by a Real Time Transport Protocol (RTP) that runs over a User Datagram Protocol (UDP). Media gateways exist in several forms, ranging from a dedicated telecommunication equipment chassis to a generic PC running VoIP software.
Gateway controllers or gate keepers house the signaling and control services that coordinate the gateway functions. Gateway controllers are responsible for call signaling coordination, phone number translations, host lookup, resources management, and signaling gateway services to the PSTN.
The IP infrastructure must ensure smooth delivery of the voice and signaling packets to the VoIP components. Due to their dissimilarities, the IP network must treat voice and data traffic differently. That is, voice and data traffic require different transport handling consideration and prioritization.
While there is correlation between VoIP and circuit-switching components, there are also many significant differences. One difference is found in the transport of voice traffic. Circuit-switching telecommunications can best be described as a Time-Division-Multiplexing (TDM) network that dedicates channels or reserves bandwidth as it is needed out of the trunk lines interconnecting an array of switches. For example, each phone call reserves a single DS-0 channel, and an associated end-to-end connection is formed to enable the call.
SS7 has been previously referenced in the discussion of the PSTN. The SS7 signaling protocol is implemented as a packet-switched network. SS7 is both a protocol and a network designed to signal voice services. SS7 is a unified interface for the establishment of circuit-switching, translation, and billing services.
SS7 is not built on top of other protocols. Rather, it is completely its own protocol suite from physical layer to application layer. For networks transporting SS7, it is important that these services be either translated or tunneled through the IP network reliably. Given the importance of SS7 signaling, it is necessary to ensure that these messages are given priority in the network. VoIP networks often require access to the SS7 facilities in order to bridge calls onto the PSTN.
ITU recommendation H.323 specifies a packet-based multimedia communication system. The specification defines various signaling functions, as well as media formats related to packetized audio and video services. H.323 standards were generally the first to classify and solve multimedia delivery issues over Local Area Networks (LAN) technologies. However, as IP networking and the Internet became prevalent, many Internet RFC standard protocols and technologies were developed and sometimes based on H.323 ideas. H.323 networks consist of media gateways and gatekeepers. Gateways serve as both H.323 termination endpoints and interfaces with non-H.323 networks, such as the PSTN. Gatekeepers function as a central unit for call admission control, bandwidth management, and call signaling. A gatekeeper and all its managed gateways form a H.323 “zone.” Although the gatekeeper is not a required element in H.323, it can help H.323 networks to scale to a larger size by separating call control and management functions from the gateways.
With each call initiated, a first TCP session is created using a first protocol defining a set of messages. A TCP connection is maintained throughout the duration of the call. A second session is established using another protocol. This TCP-based process allows an exchange of capabilities, master-slave determination, and the establishment and release of media streams. The H.323 quality of service (QoS) delivery mechanism is the Resources Reservation Protocol (RSVP).
The Real-Time Transport Protocol (RTP) protocol provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video. Services include payload type identification, sequence numbering, time stamping, and delivery monitoring. Further, the RTP protocol provides features for real-time applications, including timing reconstruction, loss detection, content delivery, and identification of encoding schemes. Many gateways that digitize voice applications use RTP to deliver the voice traffic. For each session participant, a particular pair of destination IP addresses defines the session in order to facilitate a single RTP session for each call.
RTP is an application service built on UDP, so it is connectionless with best-effort delivery. Although RTP is connectionless, it does have a sequencing system that allows for the detection of missing packets. As part of its specification, the RTP identifies the encoding scheme used by the media gateway to digitize voice content. With different types of encoding schemes and packet creation rates, RTP packets can vary in size and interval. The combined parameters of a RTP session dictate how much bandwidth is consumed by the voice bearer traffic. RTP transporting voice traffic is the single biggest data contributor to conventional VoIP traffic.
The Media Gateway Control Protocol (MGCP) (like its predecessor SGCP) largely defines the contemporary soft switch architecture. It is a master-slave control protocol the coordinates the action of media gateways. In effect, the MGCP divides the functional role of traditional voice switches between the media gateway and the media gateway controller.
In MGCP nomenclature, the media gateway controller is often referred to as a “call agent.” The call agent manages the call-related signaling control intelligence, while the media gateway informs the call agent of service events. The call agent instructs the media gateway to setup and tear-down connections when calls are generated. In most cases, the call agent informs the media gateway to start an RTP session between two endpoints.
A number of routine MGCP functions are executed during a call. A call begins when a user picks up the origination phone and dials a destination number. The gateway then notifies the gateway controller (call agent) that a call is incoming. The gateway controller looks up the dialed phone number and directs the media gateways to create a RTP connection (i.e., it identifies an IP address and port number). The gateway controller also informs the destination media gateway of the incoming call, and the destination phone rings. Thereafter, media gateways and open an RTP session across the IP network when destination phone is answered.
The following discussion will provide further description of an exemplary embodiment of the invention.
Turning now to
A calling party telephone 60 and a called party subscriber telephone 61 are shown associated with the PSTN 66 of the architectural schematic of
The Gatekeeper (GK) 51 determines where calls coming from the Voice over IP Gateway 52 should be routed. The Voice over IP Gateway (VoIP GW) 52 provides the bridge between the PSTN and the VoIP systems. A Telephone User Interface (TUI) is provided for the FMFM inside of the TUI Application Server 80. The TUI runs as a Logica CMG uOne application and is implemented on a Sun/Solaris or PC/Linux platform. The TUI provides a Text-To-Speech Server that converts text provided by the TUI into speech that is played over the telephone. The Web Server 55 provides web pages formulated from MDS 54 content for user input for configuration of the FMFM settings described below. Subscribers use a browser, such as Internet Explorer (IE) or Netscape browser to access mail services over the web. The web server also provides subscribers with administrative capabilities such as setting up and configuring their FMFM account or changing their password in the FMFM settings. The software is provided by DCL and implemented on a Sun/Solaris or PC/Linux platform.
The Master Directory Server (MDS) 54 implemented as a Lightweight Directory Access Protocol (LDAP) Server provides storage for FMFM settings such as service class, password, preferences, address book, configuration, phone numbers, contact numbers, FMFM enabled/disabled, number of rings, sub mailboxes, key contact list, etc. which are all stored in the MDS. Other components that use the MDS are “directory enabled.” FMFM, the Gate Server (TUI Application Server) and Web Server components all use the MDS.
A mail server 71 is provided comprising Access Unit 74, Message Transfer Agent 75 and Message Store 73. The Web Server and the TUI App Servers use the AU to retrieve message inventories and messages from the Message Store. The software for the AU is provided by Data Connections Limited (DCL) running on a Sun/Solaris or PC/Linux platform. Internet mail servers including the Web Server 55 and the TUI Server 80 use the MTA to send mail. If the mail is to be delivered to the UC platform, the MTA uses the Message Store to store the message in the subscriber's mailbox. The MTA also manages inbound and outbound mail to the Internet. The Storage Area Network (SAN) 76 provides reliable disk storage for use by the MDS and Message Store. The SAN is implemented on EMC hardware and software.
The MS 73 provides storage for the UC platform 86. The Mail Server through the AU and the MTA provides Web Servers and the TUI APP Servers with storage to store or retrieve messages. The Message Store holds voice messages, emails, facsimiles, voicemail greetings and voicemail name announcements. Software for the MS is provided by DCL running on a Sun/Solaris and EMC platform.
The following FMFM function features provide an enhanced end-user experience. The end user experience description that follows, as provided by the present invention contains: a Graphic User Interface (GUI) setup pages; Telephone User Interface (TUI) setup call flows; and FMFM network call flows as implemented by functions executed on the UC platform in the TUI Application Server and Web Server by the embedded FMFM function in the present example of the invention.
An underlying telephone system, such as a PSTN incorporates Advanced Intelligent Network (AIN) architecture that uses data bases stored in SCPs to facilitate call processing, call routing, and network management, thus allowing carriers to change the routing of both inbound and outbound calls from moment to moment. Call processing is that sequence of operations performed by the switches in the PSTN for acceptance of an incoming call through the final disposition of the call. Call routing is the process of determining and prescribing the path within the PSTN for establishing telephone connections or forwarding messages within the PSTN.
The PSTN/AIN launches a trigger from an SSP to an SCP when a telephone call is detected. By way of example, the SCP may be implemented with the Bellcore Integrated Service Control Point, loaded with ISCP software Version 4.4 (or higher), available from Telecordia, Murray Hill, N.J.
In the present example of the invention, an SSP in an originating Central Office (CO) for the caller telephone 60 sends caller information to an SSP in a terminating CO for the subscriber telephone 61. However, the terminating CO and the originating CO may be the same, or there may be any number of intervening switches routing the connection between the caller telephone 60 and the called party subscriber telephone 61. The SSP includes, for example, 1AESS or 5ESS switches manufactured by Lucent Technologies, Inc., or DMS-100 switches manufactured by Nortel Networks Corporation (Nortel), or AXE-10 switches manufactured by Telefonaktiebolaget LM Ericsson.
The 1AESS switches may use an AIN Release 0.1 protocol and should be equipped with Generic 1AE13.01 (or higher) software and associated AIN SSP features. The 5ESS switches may utilize an AIN Release 0.1 protocol and should be equipped with Generic 5E12 (or higher) software and associated AIN SSP features. The DMS-100 switches (release NA009) may utilize an AIN Release 0.1 protocol and associated AIN SSP features. The AXE-10 switches may utilize an AIN Release 0.1 protocol and should be equipped with Generic 8.07 (or higher) software and associated AIN SSP features. The call service logic of the present invention may be upgraded to accommodate future AIN releases and protocols and future trigger types. Specifications of AIN Release 0.1 SSPs may be found in Bellcore TR-NWT-001285, Switch-Service Control Point Application Protocol Interface Generic Requirements, the disclosure of which is expressly incorporated by reference herein in its entirety.
In the present example of the invention, an incoming call, from a calling party to the subscriber's telephone number, is received at a terminating SSP. The SSP forwards the call to the UC platform. The SSP switch forwards the call using a “Call Forward Busy/Don't Answer” function in the SSP.
By way of example, the SCP 68 is implemented with the Bellcore Integrated Service Control Point, loaded with ISCP software Version 4.4 (or higher), available from Telecordia, Murray Hill, N.J. In an alternative embodiment of the invention, the SCP 68 may be a Lucent Advantage SCP, with software release 94, available from Lucent Technologies, Inc. In the present invention an IVR is provided by the TUI Application Server. An exemplary IVR is available under the trademark CONVERSANT System for IVR, Version 6.0, Update 1, provided by Lucent Technologies, Inc. The network alternatively incorporates any compatible stand-alone IVR or advanced intelligence network-intelligent peripheral (AIN-IP or intelligent peripheral) providing an IVR.
The SSP 89 in the terminating central office (CO) (SSP) for the subscriber phone 61 and the SSP 69 is the originating CO(SSP) for the calling party 60. However, the terminating CO(SSP) and the originating CO(SSP) may be the same SSP.
A data network of the invention includes a Web Client 70, and a Web server 55, and Master Directory Server (MDS) 54 accessible through the Internet 57. The MDS is an LDAP server in the present example of the invention. The Web Client 70 includes a personal computer (PC), i.e., a graphical user interface (GUI) 59, operating client software 58, an example of which is ICW Client, available from Southwestern Bell Telephone Company. Alternatively, the client software 58 can be run at the Web server 55. The TUI Application Server 80 provides the subscriber interface to the subscriber phone 61 (or other DTMF telephone) and the Web Client 70 (or other Internet compatible GUI) through the Web server 55, via the Internet 57. The MDS also maintains FMFM settings for the TUI Application Server.
The Web Client 70 incorporates a Web browser, such as Microsoft Internet Explorer, available from Microsoft Corporation, or Netscape Navigator, available from Netscape Communications Corporation. In one embodiment, the Web Client 70 is implemented with an IBM Pentium based PC, running the Linux operating system, available from, for example, Free Software Foundation, Inc., or the Microsoft Windows operating system, and running the Microsoft Internet Explorer, Netscape Navigator (available from Netscape/AOL) or HotJava (available from Sun Microsystems, Inc.) Web browser software. An exemplary embodiment of the invention includes the Web server 54 running the Linux or Microsoft Windows operating system and the Apache Web server software, available from the Apache Software Foundation, or the Jigsaw Web server software, available from World Wide Web Consortium (W3C).
A subscriber can modify the FMFM settings via two methods. First, from any DTMF telephone, the subscriber dials a UC platform access for their area number, to access the TUI Application Server 80. The subscriber is prompted to enter an account number, along with a personal identification number (PIN), further discussed below. The subscriber then has the ability to change the PIN, change the FMFM contact numbers, or toggle the FMFM service on and off. Second, the subscriber has the option to access the FMFM settings using a GUI via the Internet 57. Over the Web connection, the subscriber is able to implement all of the IVR functions identified above, as well as build the priority screening list and design the weekly scheduler.
The key contacts list (KCL) is available for use at the subscriber's option. The KCL contains the names and telephone numbers of KCL callers, as designated by the subscriber. In an example of the present invention, if the KCL has been activated, the FMFM will only activate for calls originating from phone numbers included in the KCL. All other calls are terminated at the subscriber's phone 61 voicemail. The KCL is implemented through a screening table, which is stored in the MDS 54 and is accessible by the subscriber via the Internet 57 as discussed below.
A subscriber's exemplary interaction with FMFM settings stored in the MDS is depicted in the call flow diagram of
As shown in
Once connected to the Web server, the Web Server uses the information stored in the MDS to decide what to show the end-user. The user provides authentication information to access the corresponding account. The Web Server performs the authentication at step 104. The Web Server queries the subscriber for an account name and associated password, which confirms the user's identity. The Web Server then retrieves the account name or an account identifier and associated password information the MDS to confirm that the subscriber is an authorized user. After successful authentication, the Web Server retrieves the FMFM settings from the MDS at step 106. The Web server 55 retrieves the FMFM settings from the MDS 54 at step 107. The Web Server then forwards the FMFM settings to Web client 70 via the Internet 57 at step 108 render web screens at the Web client. The FMFM settings input by the subscriber in are entered and are sent from the Web client 70 to the Web server 55 at step 109. The subscriber input is stored in the MDS 54, indicated respectively at steps 109 and 110 of
Exemplary steps through which the subscriber can alternatively interact with FMFM settings using the TUI 80 are now described. The subscriber can access all of the FMFM settings, including but not limited to toggling the FMFM service ON or OFF, contact numbers, KCL, sub mailboxes, number of rings, sub mailboxes creation, and greetings.
After verification, the system operates in much the same way as described above with respect to a GUI and the Internet. The TUI Application Server 80 retrieves at step 126 the current FMFM settings which includes the call forwarding data specific to the subscriber at step 128. The TUI Application Server 80 then verbally recites a menu of options to the subscriber at step 130 based on the information received from the MDS 54. For example, if the subscriber has previously built a priority screening list, activation of this list will be included among the options provided to the user over the telephone. The subscriber listens to the options and inputs various choices at step 132 via the telephone touch tone key pad, including, for example turning on FMFM or assigning greetings and contact numbers to sub mailboxes associated with a subscriber telephone number. The subscriber FMFM parameter information is then sent to MDS 54 for storage and later use by FMFM.
Returning now to
Voice data for the telephone call is transmitted from PSTN 66 or a voice over Internet protocol (VoIP) network including PSTN 66 and VoIP Gateway (GW) 52 and Gatekeeper (GK) 51. The gatekeeper determines where calls coming from the VoIP GW 52 should be routed. Normally calls are routed to TUI Application Servers implemented on a Sun/Solaris or PC/Linux platform. The VoIP GW provides a bridge between the PSTN and the Internet enabling PSTN telephone calls to be converted into VoIP calls.
A calling party telephone 60 is connected to a local SSP 69 whenever the caller telephone 60 goes “off-hook,” (i.e., the handset is removed from the cradle or is otherwise activated to receive a dial tone). The SSP launches an OHD trigger each time the calling party goes off-hook and dials a series of digits adhering to the switch's dial plan is dialed. The OHD trigger activated by the SSP 69 (SSP 1703 in the example of
The subscriber may selectively activate and deactivate the service as desired, using the web client 70 via the Internet 57, as discussed below, or using conventional dual tone multi-frequency (DTMF) telephone via the TUI Application Server. Announcements to a subscriber interacting with the system are made using the TUI Application Server. Alternative embodiments of the invention combine the various server and database functions described above into any practical combination of PSTN and data network systems. According to the invention, the subscriber is able to access his or her incoming and outgoing call log through a data network, independently of PSTN involvement.
Referring now to
The Gatekeeper responds with a specific Gateway and port to use for the out dial. The TUI Application Server 80 connects a VoIP session in the Gateway and requests that the Gateway dial the first FMFM contact number. The Gateway dials the first FMFM contact number. Call status events including call answering are passed to the TUI Application Server 80 from the PSTN. When the call is answered, it is assumed they are the subscriber. FMFM provides call path duplication, which provides caller identification to the called party to eliminate the need to record and announce the calling party's name. Dynamic out dialing eliminates calling contact numbers unnecessarily, thereby speeding up the process of finding the subscriber. At the end of the call, the TUI Application Server 80 signals the Gateway to end the call to the contact number. After the call is finished, the FMFM VoIP session is disconnected. The caller is then disconnected.
Turning now to
Turning now to
If the user/subscribers chooses to create a new mailbox by entering a 2 515, the FMFM assigns an additional new mailbox to the subscriber places default FMFM settings associated with the mailbox in the MDS. Default settings comprise FMFM enabled and All Calls Enabled for FMFM. TUI Application Server then prompts 511 the subscriber or user to enter FMFM settings for the new mailbox.
The subscriber can either elect to have all calls activate the FMFM service or can limit FMFM to be activated only for callers who are in the Key Contacts List (KCL) 204. Selection of All callers or KCL is accomplished by clicking on one of the two radio buttons 207, 209 labeled “All Calls Activate FMFM” 202 or “Only Callers In Key Contacts List Activate FMFM” 204. The number of rings 206 and contact telephone numbers 203, 208 and 210 are entered via FMFM screen 200. In the present example, long distance numbers are not supported, however, the option of supporting long distance contact numbers can be provided.
Subscriber information such including FMFM settings, FMFM configuration, FMFM contact numbers, FMFM contact number of rings, Key Contacts List, Address book, server class, password, preferences, contact phone numbers, number of rings etc. are stored in the Master Directory Server (MDS) as shown in
When only callers in the KCL activate the FMFM service by calling a subscriber, the caller's telephone number is compared to each of the phone numbers in a subscriber's MDS address book of entries or a KCL created by the sub mailbox owner. All telephone numbers listed in the KCL or MDS Address Book will be used as key contact numbers to determine if an inbound caller's telephone number matches entries in the KCL. Turning now to
In the present example of the invention, the end-user can set up to three contact numbers 203, 208 and 210. Additional numbers can be added if desired. The contact numbers are displayed and input in the same order or sequence that the FMFM feature of the system will try calling the contact numbers. Additionally, the end-user can set the number of rings 206 for each FMFM contact number that is tried before moving on to the next number or directing the incoming call to voicemail.
A similar GUI screen or TUI menu of announcements is provided to assign sub mailboxes, FMFM contact numbers and sub mailbox greetings associated with a group mailbox assigned to an FMFM subscriber telephone number. These sub mailbox assignments, sub mailbox greetings and FMFM contact numbers are stored in the MDS.
The FMFM contact telephone number input by the subscriber should result in a fully formed 10-digit telephone number. If the telephone number is malformed, an appropriate error message will be displayed for the end-user (not shown). In the present example of the invention, the number of rings can be set between 2 and 20. The default value is 3. An edit check is performed when the end-user clicks on the “Save & Close” function to enforce the ring range. If the number of rings is outside the ring range, an appropriate error message is displayed for the end-user (not shown).
In the present example of the invention, a subscriber can only set contact numbers that are in the same Local Access Transport Area (LATA) as their landline Working Telephone Number (WTN) that the FMFM service is associated with. An edit check is performed when the end-user clicks on the “Save & Close” 211 to enforce the Intra-LATA rule. If calling the contact number from the WTN would result in an Inter-LATA call, an appropriate error message is displayed for the end-user (not shown). In an alternative embodiment of the invention, the intra-LATA restriction is not enforced.
A subscriber can access FMFM settings via the TUI/IVR using a telephone DTMF input as shown in
If the subscriber DMTF input is 1 616, FMFM sets the index ${i} to 1 620, and proceeds to edit the contact number 1. If the subscriber DMTF input is 2 617, FMFM sets the index ${i} to 2 and proceeds to edit the contact number 2 621. If the subscriber DTMF input is 3 618, FMFM sets the index ${i} to 3, and proceeds to edit the contact number 3 622. If the subscriber DTMF input is 4 and the number of contact numbers is less than 3 619, FMFM sets the index ${i} to 1 plus the number of contact numbers, and proceeds to add a contact number 602. Note that the menu for announcements is dynamically created based on the current contact number settings for the mailbox.
The following FMFM call flows describe the user experience when the FMFM service is active on a mailbox. The call flows illustrate how Group Mailboxes and sub mailboxes are handled. At a high level, FMFM is activated after the system has determined specifically for which mailbox a given inbound call is destined. When dealing with Group Mailboxes, that is when a plurality of sub mailboxes are defined for a single telephone number, the individual sub mailbox is determined before FMFM is activated.
As shown in
MDS FMFM settings includes but is not limited to group mail information, sub mail boxes associated with a group mail box, greetings for group mailboxes and sub mailboxes, FMFM contact numbers and number of rings for each contact number. At block 1005 FMFM determines if there is a group mailbox associated with the subscriber telephone number by fetching the number of mailboxes, N associated with the subscriber telephone number or subscriber name from the MDS. If there is more than 1 mailbox associated with the subscriber then the mailbox is a group mailbox with sub mailboxes. The number of sub mailboxes associated with the telephone number is N. If there is a group mailbox associated with the subscriber's group mailbox, FMFM asks the caller “Who do you want to leave a message for” at 1007 and sets a sub-mail box index to 1. At 1008 FMFM then goes through each sub mail box 1009 owner name greeting and asks the caller to enter a number corresponding to the desired sub mailbox owner. 1010, 1011 FMFM uses the sub mailbox owner name associated with the sub mailbox index in the MDS. FMFM then accepts DTMF input from the caller to select a sub mail box at 1012. FMFM sets the active mailbox to the sub-mail box selected by the caller at 1014. If there are no sub mailboxes associated with the group mailbox, FMFM sets the active mailbox to the group mailbox associated with the subscriber at 1006. FMFM then proceeds to FMFM-CE-Greeting1 at 1013.
The active mailbox determined in the call flow above (“Greeting”) is used to determine the FMFM settings. If FMFM is active, and the inbound call matches the selection criteria (all callers or just callers in the Key Contacts List), the caller is routed to FMFM. Otherwise, the caller is routed to the mailbox greeting where the caller can leave a message for the end-user.
One of the checks before FMFM is activated is to look to see that the neither the calling party number nor the Redirecting Number (RDN) is the only contact number. RDNs are the telephone numbers from which calls were forwarded. Typically, this would include either the subscriber's home, wireless or both numbers. If the RDN or the calling party number is the only contact number, it doesn't make sense to attempt that number again since the calling party called from the calling party number or originally called the RDN and it was not answered. The check is performed for all RDNs and the calling party number (CN). In the case of some product functionality, when the wireless phone is dialed by the caller and when active, the functionality sends the call on to the subscriber's home telephone number. In this case, if the home telephone number isn't answered, the call would forward on to the FMFM service. At that point, the call has two RDNs. The first RDN is the wireless telephone. The second RDN is the home phone number. Again, it would not make sense to expect the subscriber to answer at either of these telephone numbers since they were already tried and not answered. Moreover, if a subscriber called the home phone from the cell phone, it would not make sense to try to reach the subscriber at the home phone (RDN) nor the cell phone (CN) as the home phone was not answered and the subscriber is calling from the cell phone (CN).
Also, a calling party should be able to opt out of FMFM and go straight to voicemail. The caller is given 5 seconds to opt out before FMFM starts the FMFM out dial process.
If the contact number is not the calling party number or an RDN 1303 FMFM announces that it is ringing contact number associated with the index 1304 and initiates the outbound call to the contact number 1306. FMFM counts the rings 1308, 1310 and 1311 and once the number of rings exceeds the number of rings in the FMFM parameter number of rings for the current contact number 1311, FMFM increments the contact number index 1315 and proceeds to dial the next contact number 1302 or to FMFM-CE-Greeting21313.
When one of the contact numbers is also one of the RDNs or the CN appearing in the inbound calling path calling information, FMFM dynamic out dial skips this contact number and tries the next contact number in the contact number list or goes directly to voicemail if the contact number list is exhausted.
As a result of FMFM selection actions on the calling party side, discussed above, a separate call leg or thread is created to call the called party. This thread attempts to reach the called party at each of the FMFM contact numbers listed in the subscriber's contact number list from MDS (subject to skipping of RDN/CN considerations described above). When each out dial is initiated, the calling information supplied to the PSTN network SSP matches the Caller identification (original calling party number and name if available) information supplied on the inbound leg of the call. That is, calling party number and name information from the SSP on the out dialed call is made to match the Caller identification information from the SSP of the calling leg of the original call. Thus the original initiating caller identification information is inserted into each out dialed call as the calling party number in the SS7 link or VoIP gateway instructions. This allows the called party to effectively visually screen calls forwarded by using Caller identification. Additionally, the RDN in the outbound calling information is set to the last RDN for the inbound call.
Turning now to
Turning now to
In order to clarify the use of call information, context, and sequencing, the following high level call flows are presented in
Turning now to
Turning now to
FMFM uses the inbound call's information to determine which mailbox or sub mailbox with which to associate the call and whether or not the call context is to leave a message. There are cases where a customer has per line blocking enabled. PRI lines are configurable to pass the RDN number even when the RDN line has per line blocking enabled. In this case, FMFM would look at a privacy indicator for the calling party number or RDN on inbound calls and not present private numbers as a calling party number to system users.
Turning now to
If the caller doesn't elect to go to voicemail, FMFM proceeds as shown in
Turning now to
There are two methods to use to connect the called party to the calling party. The first method shown in the
The second method shown in
Although the invention has been described with reference to several exemplary embodiments, it is understood that the words that have been used are words of description and illustration, rather than words of limitation. Changes may be made within the purview of the appended claims, as presently stated and as amended, without departing from the scope and spirit of the invention in its aspects. Although the invention has been described with reference to particular means, materials and embodiments, the invention is not intended to be limited to the particulars disclosed; rather, the invention extends to all functionally equivalent structures, methods and uses such as are within the scope of the appended claims.
In accordance with various embodiments of the present invention, the methods described herein are intended for operation as software programs running on a computer processor. Dedicated hardware implementations including, but not limited to, application specific integrated circuits, programmable logic arrays and other hardware devices can likewise be constructed to implement the methods described herein. Furthermore, alternative software implementations including, but not limited to, distributed processing or component/object distributed processing, parallel processing, or virtual machine processing can also be constructed to implement the methods described herein.
It should also be noted that the software implementations of the present invention as described herein are optionally stored on a computer readable medium, a tangible storage medium, such as: a magnetic medium such as a disk or tape; a magneto-optical or optical medium such as a disk; or a solid state medium such as a memory card or other package that houses one or more read-only (non-volatile) memories, random access memories, or other re-writable (volatile) memories. A digital file attachment to email or other self-contained information archive or set of archives is considered a distribution medium equivalent to a tangible storage medium. Accordingly, the invention is considered to include a tangible storage medium or distribution medium, as listed herein and including art-recognized equivalents and successor media, in which the software implementations herein are stored.
Although the present specification describes components and functions implemented in the embodiments with reference to particular standards and protocols, the invention is not limited to such standards and protocols. Each of the standards for Internet and other packet switched network transmission and public telephone networks represent examples of the state of the art. Such standards are periodically superseded by faster or more efficient equivalents having essentially the same functions. Accordingly, replacement standards and protocols having the same functions are considered equivalents.