RELATED APPLICATIONUnited States Utility Patent Application by Hong Thi Nguyen et al. 36968.262343(BS01261), filed on the same date as this application and entitled “CONFERENCE CALL SET-UP AUTOMATION,” is hereby incorporated by reference.
COPYRIGHT NOTICEA portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the United States Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
FIELD OF THE INVENTIONThe present invention relates generally to the field of telecommunications. The present invention relates specifically to systems and methods for placing an automated conference call from a call-log.
BACKGROUNDAs telecommunications systems advance, demand increases for subscriber features in both wireless and wire line networks. One example of a subscriber feature that is commonly used is conference calling. Private parties and corporations frequently encounter situations in which a meeting between geographically separated parties would be appropriate, but there are difficulties associated with bringing the parties together at a specific meeting place at a specific date and time. Conference calling provides a convenient solution by allowing individuals from various geographic locations to have a conference over the telephone.
Conventional three-way conference calling enables one party already established in a telephone call with a second party to place a telephone call to a third party, and then to conference the two separate telephone calls together into a single, three-way telephone-call. To enable parties having only one telephone line to initiate a three-way conference call, the two separate telephone calls are conventionally conferenced at a telephone switch, either at the subscriber's premises or at the central office of the telephone company, and then transmitted to the initiating party on the single telephone line. Typically, at least one of the parties involved in the conference call subscribes to three-way calling service.
Conventionally, such a call is accomplished by the first party flashing the telephone line to indicate to the switch that the current party (second party) is to be put on hold, and a dial tone is to be presented to the first party. The first party then dials out to or calls a third party, and establishes a call between them. The first party then flashes the telephone line again to indicate to the switch to conference together the telephone call to the second party with the call to the third party, and to present the same to the first party as a single telephone call. Thus, a three-way call is established. This conventional technique of three-way calling is sometimes inconvenient to establish and is limited to three party participation.
An additional conventional system for establishing conference calls, usually used by businesses, involves a caller contacting a conference call operator in advance of a meeting to set-up a conference bridge. After the conference bridge is set-up, the call organizer is given a contact number, which the conference parties have to use to call in to the bridge. The call organizer then needs to communicate the contact numbers and the conference call date and time to all invitees. Each invitee is then required to dial the contact number at the specified time to join the conference call, which may already be in progress. This system has several disadvantages such as individual participants having to remember the specific date, time, and number to call in to connect to the conference call. This system also involves the conference organizer having to call an operator in advance of the conference call to set-up a conference bridge.
Sometimes, a conventional conferencing user either forgets to call at the appropriate time or forgets the conference telephone number or passcode. Such a forgetful user is penalized by being precluded from attending a conference session. A conventional conference participant may compensate by writing the conference telephone number and passcode down and posting that information near a telephone. This, however, defeats the security aspect of requiring knowledge of a telephone number and confidential passcode to access a teleconference.
Another disadvantage of conventional teleconference methods is that conference participants must initiate the conference connection. With the exception of three-way calling, conferencing requires each party to place a call to a conferencing facility that houses a conference switch. The switch is then set-up at the conferencing facility to enable the conference participants to talk among themselves.
Yet another disadvantage of certain conventional teleconference systems, particularly those in which participants are called by another participant, is that many such systems require a conference participant to be associated with one particular telephone number. Workers of today operate in a very mobile society. They may be at the office one day, and telecommuting from home the next day. Therefore, being tied to one telephone number can be very restrictive for today's worker.
What is needed are methods and systems that overcome the disadvantages of conventional systems. Such methods and systems should provide additional advantages, including cost effectiveness, flexibility, and ease of implementation.
BRIEF SUMMARYIn a preferred embodiment, the present invention provides for the automated establishment of a conference call in which conference participants are connected to the conference call by accessing and selecting participant directory numbers associated with a call-log of a subscribers' communication device. Implementations of the present invention comprise at least one of a method, a process, a system, an apparatus, a computer readable medium, and a data stream.
An embodiment of the present invention provides a method of automatically establishing a conference, comprising the steps of selecting desired conference call participants from a call-log associated with a communication device, activating a key operable for initiating the automatic service, receiving conference logistics, receiving participant profile data, allocating a conference bridge port in accordance with the received conference logistics, and connecting a communications switch port to the allocated conference bridge port. Conference logistics may include a conference start date and connect time, which may be utilized in establishing a conference. Establishing a conference includes allocating bridge ports and connecting communications switch ports with allocated bridge ports.
Embodiments of the present invention provide a teleconference participant with the flexibility to be connected at the participant's listed call-log number. The present invention is able to locate the current situs of a participant via a profile record based on the recorded call-log directory number, which includes a telephone number for the current location of the conference participant. Such a mechanism, that makes use of a participant profile, may also be used to provide other methods of connecting to a participant (such as via the Internet or company Intranet, using an internet protocol (IP) address as the current location of the conference participant) or back up connection mechanisms (i.e., connect using a secondary location telephone number or other address, if the first location telephone number is busy or otherwise unavailable).
Embodiments allow a subscriber to provision the present invention using various techniques including, but not limited to, inputting conference logistics in response to a dual tone multiple frequency (DTMF) menu, forwarding a formatted file comprising labeled conference provisioning information to the present invention, and inputting conference logistics into a form associated with a subscriber communication device, and wherein the communication device may include mobile telephones, portable telephones, personal digital assistants (PDAs), wireline telephones, and Internet based phones accessed using a personal computer (PC).
Embodiments of the present invention offer many advantages over conventional conferencing systems. First of all, since a conference is established automatically, a conference participant need not remember numbers and codes for accessing a conference. Additionally, these conferences may be provisioned to be automatically established at periodic intervals (i.e., the monthly budget meeting).
The requirements for prior scheduling, operator interaction, and attendee interaction imposed by conventional approaches are eliminated, thus providing the subscriber and conference attendees with a completely automated interface.
Additional objects, advantages, and novel features of the invention will be set forth in part in the description which follows, and in part will become more apparent to those skilled in the art upon examination of the following, or may be learned by practice of the invention.
BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 is a functional block diagram illustrating an exemplary hardware environment for establishing an automatic conference call, according to an embodiment of the present invention;
FIG. 2 is a functional block diagram illustrating an exemplary message flow among software modules, and between software modules and data repositories in an embodiment of the present invention;
FIG. 3 is a flow chart illustrating an overall process for implementing an embodiment of the present invention;
FIG. 4 is an illustration of an exemplary format for a conference record;
FIG. 5 is an illustration of an exemplary format for a conference message that is forwarded from a scheduler to a conference control manager;
FIG. 6 is a flow chart illustrating an exemplary process by which a scheduler may maintain an immediate conference queue and generate an immediate conference message for each conference record contained within the queue;
FIG. 7 is a flow chart illustrating an exemplary process by which a scheduler may maintain a set-up list and generate a set-up conference message for each conference record contained within the list;
FIG. 8 is a flow chart illustrating a process by which a scheduler may maintain a connect list and generate a connect conference message for each conference record contained within the list;
FIG. 9 is a flow chart illustrating a process by which a conference control manager directs the establishment of a conference session; and
FIG. 10 is a schematic diagram illustrating a mobile communication device comprising a call-log feature.
DETAILED DESCRIPTION OF THE INVENTIONAs required, detailed embodiments of the present invention are disclosed herein, however, it is to be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. Specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims as a representative basis for teaching one skilled in the art to variously employ the present invention. The present invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.
Referring now to the drawings, in which like numerals indicate like elements throughout the several figures,FIG. 1 illustrates an exemplary hardware environment for establishing an automatic conference call, according to an embodiment of the present invention. In one embodiment, a conference call is automatically established using a call-log. The term “communication” is used herein to include all calls that may be exchanged between a caller and a called party in the system illustrated inFIG. 1. A subscribingparty105, who has subscribed to an automatic conference call service, is in communication with afirst attendee106, asecond attendee107, athird attendee108, and afourth attendee125. The subscribingparty105, andattendees106,107, and108, are communicating with each other using communication devices, such as landline telephones.Attendee125 is also participating in the conference call using a mobile phone, which is connected to a cellular network126. A device, such as acaller ID box110, may be installed on the subscriber's line, such as that shown forsubscriber105, which is operable for inputting caller information into a call-log displayed on the subscriber's105 communications device.
The system ofFIG. 1 comprises a telephone network environment for making a conference call, including a Public Switched Telephone Network (PSTN)100 and acellular network116. ThePSTN100 may be viewed as the aggregate of all lines and equipment serving to connect telephone users, but excludes private networks formed from leased telephone lines, wireless systems, and public data networks like the Internet.
As is shown, thesubscriber party105 andattendee parties106,107,108, and115, are connected to thePSTN100. The subscribingparty105 initiates a conference call, which is created and administered automatically under the control of aconference service node120, which is coupled to the telecommunications network. Theconference service node120 is capable of controlling and performing certain communications processing and switching functions.
Attendees106,107,108, and115 are selected by a subscribingparty105, and connected to a conference call automatically by theservice node120. In one embodiment,attendees106,107,108, and115 may be invited to join the conference. Theattendees106,107,108, and115 are first called by theservice node120, which may play a recorded message when an attendee (106,107,108, or115) answers the call from theservice node120. Each attendee (106,107,108, and115) who answers such a call is presented with an option to accept or refuse a connection to the conference by responding with a DTMF (Dual Tone Multiple Frequency) “1” or “0”, respectively, from the attendee's (106,107,108, or115) touch tone telephone, in an embodiment.
In one embodiment, a conference call is automatically established when the subscribing party initiates the conference call using a call-log feature contained within their communication device. Theservice node120 generates a reference identifier for each attendee, based on the subscribing parties call-log display. Theservice node120 generates and maintains control over all of the personal references and manages the conference call. The personal call-log reference comprises a telephone number which is used to identify an attendee. In one embodiment,attendees106,107,108, and115 answer their communication device and connect to and join the conference call from the location in which their caller identification information was originally provided from.
In an embodiment, theservice node120 is in communication with aconference database135. Aservice node120 comprises an Integrated Services Digital Network (ISDN)interface122, aconference bridge130, and a service node (SN)control computer125, while aconference database135 comprises provisioned conference information (i.e., conference logistics). AnISDN interface122 provides PRI (Primary Rate Interface) and BRI (Basic Rate Interface) interfaces for voice and data channels between theservice node120 and thePSTN100. Aconference bridge130 comprises a switch for “bridging” or connecting conference participants. ASN control computer125 is a computer which executes software for automatically setting up and connecting conference calls without requiring the participants to dial into a conference service. In the embodiment shown, theSN control computer125 communicates with theconference database135 via a local area network (LAN)132 and anapplication server134. Additionally, as shown, theSN control computer125 may be accessed for provisioning and maintenance purposes, inter alia, via theInternet100 and afirewall145.
In a preferred embodiment, theservice node120 is in communication with aprofile database140. In the embodiment shown, theSN control computer125 communicates with theprofile database140 via aLAN132 and anapplication server134. Aprofile database140 stores provisioned participant profile data. Participant profile data comprises a participant identifier, a participant address, a current or preferred address of a conference participant, a home address, a wireless address, and a computer address. An address may be a telephone number, an Internet protocol (IP) address, or another address which identifies a device that may connect to a conference. In the embodiment described, an address comprises a telephone number.
Conference logistics and participant profile data may be provisioned or input by a subscriber into theconference database135 using various techniques. These techniques include a menu-based dual tone multiple frequency (DTMF) entry system, in which asubscriber105, dials into a provisioning system which guides thesubscriber105 through a menu of provisioning options. Thesubscriber105 uses the subscriber's touch tone phone to respond to the menu. Provisioning software captures the subscriber's105 responses and formulates these responses into a conference information record, which may then be stored in aconference database135. Additionally, theservice node120 can provide a variety of voice, Automatic Speech recognition (ASR), FAX, Text to Speech-based provisioning services using off-the-shell voice circuit boards from vendors such as Dialogic and Antares Audio Technologies. Such provisioning techniques may be implemented via hardware within theservice node120 and/or via software executing on theSN control computer125 in various embodiments.
Other provisioning techniques available to subscribers with Internet access include the use of a web-based form, a formatted file, and a formatted email message. When using a web-based form, a subscriber having a browser running on acomputer160 with anInternet150 connection accesses a provisioning form by supplying a uniform resource locator (URL) for such a form. The subscriber may enter provisioning information (such as a conference name, conference participants' names, conference participants' phone numbers, and the date and time of the teleconference) into the form and send the form entries as a CGI string, in one embodiment, to a provisioning software interface.
Other subscriber-provisioning mechanisms include sending a formatted email or a formatted file from asubscriber computer160 to theservice node120. An exemplary formatted email message may have a subject line of “CONFERENCE”, and contain labeled lines within the body of the email. Such labeled lines may take the form of: “NUMBER=4045551234”, “NUMBER=4045559876”, “NUMBER=2025554567”, “NUMBER=7035551357”, “DATE=120101”, and “TIME=090000”. When aservice node120 receives an email with a CONFERENCE subject line and containing the above six labeled lines, aprovisioning module200 running on theservice node120 will extract the values to the right of the “=” for each labeled line. These extracted values may then be used to populate aconference information record400, which is then stored in adata store210 and/orconference database135. Theconference information record400 will subsequently be used by a conference establishment subsystem to establish a teleconference session at the provisioned start date (Dec. 01, 2001) and start time (09:00:00), and among conference participants having telephone numbers (404) 555-1234, (404) 555-9876, (202) 555-4567, and (703) 555-1357.
A similar mechanism may be employed using formatted files. Such files may also contain labeled lines, and are electronically transferred via file transfer protocol (FTP) or another file transfer utility.
Provisioning techniques employing web-based forms, formatted files, and formatted email messages may be implemented on anapplication server134. A conference call initiator or subscriber using theInternet150 may forward provisioning information to theapplication server134 through afirewall145, in an embodiment.
Additionally, such mechanisms may be readily adapted for provisioning participant profile data. For instance, a subject line of “PROFILE” may indicate that the email is to be processed by aprovisioning module200 as containing labeled lines indicating a participant identifier or telephone number (“PARTICIPANT=”), a current or preferred address or usual telephone number (“CURRENT=”), office number (“OFFICE=”), home number (“HOME=”), cellular or wireless number (“CELL=”), and/or Internet address (“IP=”). In the case of participant profile data, however, theprovisioning module200 would construct a profile record, and forward the profile record to aprofile database140 for permanent storage.
Similar provisioning techniques, as those previously discussed, may also be used for client devices, includingcellular phones115 and other thin client devices. However, access to theservice node120 is available through thePSTN100 by way of acellular network116, in the case of provisioning via acell phone115.
Provisioning software is a component of an interface subsystem for an embodiment of the present invention, and provides provisioning (or subscriber-inputting) capabilities for conference provisioning information (or conference logistics) and participant profile data. This provisioning software is also responsible for formulating conference records, which are stored in adata store210 and aconference database135, and profile records, which are stored in aprofile database140, from conference provisioning information and participant profile data, respectively. As previously discussed, provisioning software may execute on aSN control computer125 and/or anapplication server134 in other embodiments. The software components of an embodiment of the present invention are further presented in the discussion ofFIG. 2.
FIG. 2 comprises software modules and database interfaces for an embodiment of the present invention. Conceptually, the embodiment illustrated inFIG. 2 describes two software subsystems: a subscriber or provisioning interface subsystem; and, a conference establishment subsystem. The subscriber interface subsystem is responsible for receiving subscriber provisioning inputs, formulating conference and profile records, and storing such records, whereas the conference establishment subsystem automatically establishes a conference among the conference participants based upon the information contained in those stored records. Functions implemented by the conference establishment subsystem include conference set up (or bridge port allocation) and conference participant connection. A system configurable time interval (i.e., a delay) may occur between the performance of these functions in an embodiment of the present invention.
There are six main software components shown in the exemplary embodiment ofFIG. 2. In an exemplary embodiment, these software components execute on theSN control computer225 and include aprovisioning module200, ascheduler225, a conference control manager (CCM)230, abridge port allocator235, an auto-dialer240, and aconference connector250.
A subscriber to an automatic conferencing service interacts with aprovisioning module200 to create conference records comprised of data that instructs the present invention as to how and when automatic conference call connections are to be made. Conference records may be stored in aconference database135 or aconference data store210 or both. Adata store210 may be implemented as shared memory (or a shared file or directory) resident on theservice node120, or as a service node peripheral device. Theprovisioning module200 stores conference records of future conferences in theconference database135. Such conference records will be extracted from theconference database135 by ascheduler225, which will be discussed later. Theprovisioning module200 stores conference records of conferences that are to be started immediately (or within twenty-four hours) in theconference data store210.
A subscriber may also interact with theprovisioning module200 to create profile records, which are stored in aprofile database140. Profile records are comprised of called party (i.e., a participant who is automatically called in order to establish a conference) information such as a called party identifier, a work telephone number, a home telephone number, a cellular telephone number, and a current telephone number. An embodiment of the present invention will automatically connect to the current telephone number found in a profile record for a called party, thereby overriding that participant's telephone number which was provided in a conference record. If a profile record for the called party does not exist in theprofile database140, then the conference record information is used to connect the called party to the conference.
Another software component of an embodiment of the present invention is known as ascheduler225. Ascheduler225 determines when a conference should be set up and connected. Thescheduler225 maintains conference containers (queues, lists, etc.) that contain conference records. The container in which a record is stored is indicative of how the record will be processed. For instance, in an exemplary embodiment, an immediate conference queue contains conference records of teleconferences that are to be established immediately. Records of conferences that are merely to be set up (i.e., only the bridge ports are to be allocated) are maintained in a set up conference list. Records of conferences that are to be connected (i.e., the bridge ports have been previously allocated, but the conference participants have yet to be connected) are maintained in a connect conference list.
Thescheduler225 creates a conference message for each conference record stored in a conference container at the time of a record is processed. Three types of conference messages are created. Type one indicates that a conference is to be immediately established (i.e., with no delay between set up and connection). Type two indicates that a conference is to be set up (i.e., only allocate conference bridge ports). Type three indicates that a previously set up conference is to be connected (i.e., connect all conference participants) to the conference session.
In an exemplary embodiment, ascheduler225 receives an interrupt signaling that a conference record has been added to thedata store210. Thescheduler225 then reads the conference record from thedata store210 and places the record within one of two conference containers. The first conference container comprises conference records for conferences that are to be started immediately. The second conference container comprises conference records for conferences that are to be set up in advance, then connected at a later time. Note that a third container is subsequently created and maintained by thescheduler225. This third container comprises processed conference records from the second container and represents conferences that have been set up, but not yet connected. The first container is implemented as a queue, and the second and third containers are implemented as linked lists, in the exemplary embodiment.
Thescheduler225 processes a record and creates a conference message based upon the subscriber-provisioned set up and start times of a conference, as reflected in a conference record. After a conference message is created, thescheduler225 forwards the message to a conference control manager (CCM)230.
TheCCM230 operates as a hub for the software components implemented in an embodiment of the present invention. After receiving a conference message from thescheduler225, theCCM230 interacts with the appropriate components to set up and connect the conference.
In order to set up a conference (i.e., allocate bridge ports), theCCM230 extracts the number of conference participants (N) from a (type 1 or type 2) conference message received from thescheduler225. TheCCM230 forwards the value of N to abridge port allocator235. Thebridge port allocator235 comprises software to interface with a teleconference bridge and to allocate N bridge ports. Thebridge port allocator235 returns a list of N allocated bridge port numbers to theCCM230. At this point a conference has been “set up.”
ACCM230 also directs the process of connecting teleconference participants. TheCCM230 extracts the telephone numbers of all conference participants contained in a (type 1 or type 3) conference message. TheCCM230 updates the extracted telephone numbers with a current telephone number for the participant (which is obtained from a profile database140), if such a current telephone number exists in theprofile database140. If no entry for the participant exists in theprofile database140, then the participant's telephone number, as it appears in the conference record is used to connect the participant to the conference.
TheCCM230 then instructs anauto dialer240 component to dial (i.e., call) each participant's telephone number. Theauto dialer240 returns a switch port (or call port) number for each conference participant successfully called. TheCCM230 then forwards a message to aconference connector250. This forwarded message comprises a switch port number (received by theCCM230 from the auto dialer240) and an allocated bridge port number (received by theCCM230 from the bridge port allocator235) for each conference participant. Theconference connector250 then connects the switch port to the allocated bridge port for each participant, thereby connecting each participant to the teleconference.
The software components shown inFIG. 2 implement the two major subsystems of an embodiment of the present invention. Theprovisioning module200 implements a provisioning subsystem. Thescheduler225, theCCM230, thebridge port allocator235, theauto dialer240, and theconference connector250 interoperate to implement a conference establishment subsystem. The provisioning and conference establishment subsystems are shown inFIG. 3.
A flow chart of an embodiment of an overall conference call set up automation process is shown inFIG. 3. The steps enumerated in the flow chart ofFIG. 3 are executed on aSN control computer125 by the software components described inFIG. 2. In another embodiment, these steps may be executed on more than one hardware platform. For example, in the flow chart shown inFIG. 3, a provisioning subsystem is implemented bysteps300 and310, and may be carried out on one hardware device, whereas a conference establishment subsystem that is implemented bysteps320,330 and340 may be executed on another hardware device in communication with the first hardware device.
Referring toFIG. 3, an exemplary conference call set up automation process provided by an embodiment of the present invention begins with aprovisioning module200 receiving conferencesubscriber provisioning information300. A subscriber provisions an embodiment of the present invention as previously described in the discussion ofFIG. 1. Conference provisioning information (or conference logistics) may include a start date and time, the number of conference participants, and a telephone number for each participant. Additionally, participant profile provisioning data may comprise a participant's name or other identifier, usual telephone number, current telephone number, office telephone number, home telephone number, and a cellular telephone number.
Next, the provisioned conference information is stored by theprovisioning module200 instep310. As discussed previously, conference information (in the form of a conference record, in one embodiment) is stored in aconference database135 and/or adata store210. Once conference logistics or conference provisioning information has been provided by a subscriber, a conference may be automatically established without subsequent user intervention. Participant profile data may be stored as profile records in aprofile database140, in one embodiment.
The stored conference information (in the form of a conference record) is then read by thescheduler225 instep320. After receiving atype 1 ortype 2 conference message, theCCM230, via thebridge port allocator235, sets up a teleconference bridge instep330. Finally instep340, after receiving atype 1 ortype 3 conference message theCCM230, operating in conjunction with theauto dialer240 and the conference connector245, connects the conference participants to a conference session instep340.
A conference record provides a mechanism in which theprovisioning module200 communicates with thescheduler225 in the exemplary embodiment. A conference message provides a mechanism in which thescheduler225 communicates with theCCM230. An exemplary conference record is shown inFIG. 4, and an exemplary conference message is shown inFIG. 5.
FIG. 4 illustrates anexemplary conference record400. Aconference record400 is created by aprovisioning module200 when a conference subscriber inputs conference provisioning information. Conference provisioning information may include such parameters as a conference name, a conference start date and time, the number of conference participants, and contact information (such as a telephone number) for each conference participant.
Field405 ofconference record400 comprises a conference name. A conference name is a subscriber-provided alphanumeric value, and may be used by a subscriber to recall a stored conference record from aconference database135 for editing or to invoke an automated conference session immediately or at a future date and time.
Field410 comprises a conference identifier. This field is a unique value that is provided by aprovisioning module200 in one embodiment. The present invention uses this value for accounting purposes to correlate allocated bridge ports with conferences that are set up but not yet connected, for example.
A start date (field420) and start time (field440) are subscriber-provided fields that reflect the day and time the subscriber desires to hold the teleconference. A set up time field (field430) is comprised of a time in advance of the start time offield440 in which bridge ports are allocated for the conference identified by the conference identifier offield410. In alternative embodiments, the set up time may be subscriber-provided or may be calculated by theprovisioning module200. Calculation of the set up time may take place by theprovisioning module200 receiving or reading a system administrator-supplied global configuration parameter and offsetting the start time offield440 with that configuration parameter. For example, a configuration parameter of “2” may indicate that all conferences should be set up two hours in advance. In such a case, astart time field440 containing a value of 8:00:00 would result in a set uptime field430 value of 6:00:00.
A “number of participants (N)”field450 contains an integer value representing the number of conference participants. In alternative embodiments, this value may be subscriber-supplied during a provisioning process or derived by theprovisioning module200 from the number of telephone numbers provisioned by a subscriber.Field460 is comprised of a series of subfields (P1through PN), in which each subfield contains a telephone number of a conference participant.
Conference records400 may be stored locally (i.e., local to a service node130) within aconference data store210, and also in secondary storage, such as aconference database135. The fields of aconference record400 are used to create conference messages that are subsequently sent from ascheduler225 to aCCM230. These messages instruct theCCM230 as to the level of teleconference establishment that is necessary at the time the conference message is received by theCCM230. In an exemplary embodiment, the three types of conference messages employed are of a format as illustrated inFIG. 5.
FIG. 5 illustrates an example format for aconference message500, which is forwarded from thescheduler225 to theCCM230 in the exemplary embodiment of the present invention. Aconference message500 comprises fields for a message type, a conference identifier, the number of participants (N), and the telephone numbers of each conference participant (P1through PN).
Field510 contains a message type value. In an example embodiment, a message type may have a value of 1, 2 or 3. A conference message type of 1 indicates to theCCM230 that the conference (identified by the value found in field520) should be established immediately. A conference message oftype 2 indicates to theCCM230 that the conference (identified by the value found in field520) should be merely set up. In such a case, conference bridge ports would be allocated for the conference identified by the value found infield520, but the conference participants would not be connected (i.e., teleconferenced) until a later time. Note that this later time is the time reflected in thestart time field440 of aconference record400 for that particular conference.
Continuing with the discussion of field510, a message type value of 3 indicates to theCCM230 that the conference (identified by the value found in field520) should be connected. Onetype 3 conference message will be subsequently processed for eachtype 2 message processed by theCCM230. Thus, when amessage type 3 is received by theCCM230, the conference participants are connected to a conference session via the previously allocated conference bridge ports, which were allocated as a result of the processing of aprior type 2 message.
As previously discussed withFIG. 2, eachconference record400 in an exemplary embodiment is placed into one of three conference containers, which are maintained by thescheduler225. Eachconference record400 is converted into aconference message500 by thescheduler225 and forwarded to theCCM230 for appropriate action, based upon the message type field510 of theconference message500. Thescheduler225 processes for converting aconference record400 into aconference message500 oftype 1, 2 or 3 are illustrated inFIG. 6,FIG. 7, andFIG. 8, respectively.
FIG. 6 illustrates a flow chart of an exemplary method executed by ascheduler225 for processing immediate conference requests. Such requests indicate subscribers' intentions to have teleconferences set up and the participants of each teleconference connected to the teleconference immediately after the bridge ports are allocated (e.g., immediately after a conference is set up).
Instep600, thescheduler225 receives or reads an immediate conference queue (or other such data structure). The immediate conference queue is a container that holds immediate conference records400. Immediate conference records represent subscriber requests to immediately establish a teleconference.
Atstep610, thescheduler225 begins a process for looping over all conferences in an immediate conference queue by determining if there are anyconference records400 in the immediate conference queue. If there are noimmediate conference records400 in the immediate conference queue, thescheduler225 method for handling immediate conference requests goes into a wait state atstep615. The wait duration may be set by a system administrator as a configuration parameter. Alternatively, the wait duration may end when an interrupt occurs signaling the arrival of animmediate conference record400 in the immediate conference queue. When the wait duration terminates, thescheduler225 resumes executing atstep600.
If there areimmediate conference records400 in the immediate conference queue, as determined instep610, then instep620 thescheduler225 receives or reads thefirst conference record400 in the queue. Thescheduler225 creates an immediate (or type 3)conference message500 instep630 from the receivedconference record400.
The immediate (or type 1)conference message500 is then forwarded instep640 by thescheduler225 to aCCM230, and theconference record400 is removed from the immediate conference queue instep650 by thescheduler225. Processing of the immediate conference queue then loops back tostep610. The establishment of an immediate teleconference from the perspective of aCCM230 process is further explained in the discussion ofFIG. 9.
FIG. 7 illustrates a flow chart of an exemplary method executed by ascheduler225 for processing set up conference requests. Such requests indicate subscribers' intentions to have teleconferences set up (e.g., the conference bridge ports allocated) at a set up time as specified infield430 of aconference record400, and have each conference's participants connected to the teleconference at a later time, as specified infield440 of a conference record.
Instep700, thescheduler225 receives or reads a set up conference list (or other such data structure). The set up conference list is a container that storesconference records400 that have yet to be set up. That is, the set uptime field430 of aconference record400 contains a valid value, and that set up time has not yet occurred.
Atstep710, thescheduler225 begins to loop over all conferences in the set up conference list by determining if there are anyconference records400 in the set up conference list. If there are nosuch records400, thescheduler225 method for handling set up conference requests goes into a wait state atstep715. The wait duration is set by a system administrator as a configuration parameter. When the wait duration lapses, thescheduler225 begins executing atstep700 again.
If there are set upconference records400 in the set up conference list, then instep720 thescheduler225 receives or reads thefirst conference record400 in the list. Thescheduler225 next determines if the time has arrived to set up the conference instep730 by comparing the set up time (as reflected infield430 of a conference record400) to the current time instep720. The current time may determined by a system call to the Service Node's130 operating system.
If the set up time is earlier than the current time, then a wait state is entered into atstep735. In an embodiment, a set up list is maintained as a linked list in which an earlier position in the list is occupied by aconference record400 having an earlier set up time, as reflected infield430 of aconference record400. In other words, conferences appearing in a set up list may be arranged in ascending chronological order, based upon the conference set up time offield430 of theconference record400. When the wait duration ofstep735 lapses, thescheduler225 begins executing atstep710 again. The wait duration ofstep735 may be based upon a different configuration parameter than the wait duration ofstep715.
If the set up time equals (or is greater than) the current system time, then thescheduler225 creates a set up (or type 2)conference message500 instep740. The set up (or type 2)conference message500 is then forwarded instep750 by thescheduler225 to aCCM230, and theconference record400 is removed from the set up conference list and inserted into a connect conference list (in ascending chronological order, based upon the value of the conference start time as reflected infield440 of the conference record400) by thescheduler225 instep760. Processing of the set up conference list then loops back tostep710. The set up of a conference is further explained from the perspective of aCCM230 in the discussion ofFIG. 9.
FIG. 8 illustrates a flow chart of an exemplary method executed by ascheduler225 for processing connect conference requests. Such requests indicate that the time has arrived to connect participants to a teleconference that has been set up (i.e., the conference bridge switch ports have been previously allocated).
Instep800, thescheduler225 receives or reads a connect conference list (or other data structure). The connect conference list is a container that holdsconference records400 for conferences that have been set up, but not yet connected. That is, the set up time as reflected in a set uptime field430 of aconference record400 has arrived, but the start time of a start time field has not yet been reached.
Atstep810, thescheduler225 begins to loop over all conferences in the connect conference list by determining if there are anyconference records400 in the connect conference list. If there are nosuch records400, thescheduler225 method for handling connect conference requests goes into a wait state atstep815. The wait duration is set by a system administrator as a configuration parameter. When the wait duration lapses, thescheduler225 begins executing atstep800 again.
If there areconnect conference records400 in the connect conference list, then instep820 thescheduler225 receives or reads thefirst conference record400 in the list. Thescheduler225 next determines if it is time to connect the conference instep830 by comparing the start time (as reflected infield440 of a conference record400) of theconference record400 received instep820 to the current system time. The current time may be determined by a system call to the Service Node's130 operating system.
If the start time is later than the current time, then a wait state is entered into atstep835. In an embodiment, a connect list is maintained as a linked list in which an earlier position in the list is occupied by aconference record400 having an earlier start time, as reflected infield440 of aconference record400. In other words, conferences appearing in a connect list may be arranged in ascending chronological order, based upon the conference start time offield440 of theconference record400. When the wait duration ofstep835 lapses, thescheduler225 begins executing atstep810 again. The wait duration ofstep835 may be based upon a different configuration parameter than the wait duration ofstep815.
If the start time of the conference equals (or is greater than) the current time, then thescheduler225 creates a connect (or type 3)conference message500 instep840. The connect (or type 3)conference message500 is then forwarded instep850 by thescheduler225 to theCCM230, and theconference record400 is removed from the connect conference list instep860 by thescheduler225. Processing of the connect conference list then loops back tostep810. The connecting of participants to a conference session is further explained from the perspective of aCCM230 in the discussion ofFIG. 9.
FIG. 9 illustrates steps taken by an embodiment of the present invention to automatically set up and/or establish a teleconference session. The Conference Control Manager (CCM)230 ofFIG. 2 executes these steps in an exemplary embodiment.
Instep900 ofFIG. 9, aCCM230 receives aconference message500. Next, theCCM230 determines whether the message received is of eithertype 1 ortype 2 instep905 by extracting the message type field510 of the receivedconference message500 and performing a simple comparison. If the conference message type value is not 1 or 2, then instep935, theCCM230 determines whether the message type value is 3. If the conference message is not oftype 3, then an error condition has occurred and an error routine is executed by the CCM instep937. Such a routine may merely log the error event, and discard theerroneous conference message500, in one embodiment. If the conference message type value is 3, then processing continues atstep940, which is discussed later.
Continuing with the discussion ofstep905, if theconference message500 is either oftype 1 or 2, then instep910 theCCM230 extracts the value from the Number of Participants (N)field530 of the receivedconference message500. TheCCM230 then forwards N (i.e., the number of conference participants) to abridge port allocator235 instep915. TheCCM230 subsequently receives a list (or array) of N unused bridge ports that have been allocated by the conference bridge switch for this particular conference instep920. Note that this conference session is uniquely identified by the value of theConference Identifier field520 of the receivedconference message500. In an embodiment, theCCM230 maintains a bridge port allocation list comprising conference identifiers (fromfield520 of a conference message500) and the allocated bridge port numbers (received from thebridge port allocator235 in step920) associated with each conference identifier.
At this point in the processing of a conference message500 (i.e., at step925), theCCM230 distinguishes betweentype 1 andtype 2messages500 by determining if the receivedconference message500 is atype 1message500. If theconference message500 is not atype 1conference message500, then it is oftype 2 and processing exits atstep930. Upon exiting atstep930, a conference has been set up. In other words, conference bridge ports have been allocated for the conference identified by aconference identifier field520 of the receivedconference message500. These allocated bridge ports are correlated with this particular conference via a bridge port allocation list maintained by theCCM230, as previously discussed.
Continuing withstep925, if the receivedconference message500 is oftype 1, then thatconference message500 is an immediate conference message. Processing continues atstep940.
Whenstep940 is reached, a conference has been set up but not yet connected. In other words, conference bridge ports have been allocated for the conference associated with the conferenceidentifier value field530 of theconference message500. Processing of atype 1 orimmediate conference message500 arrives atstep940 viastep925. Processing of atype 3 or connectconference message500 arrives atstep940 viastep935.
Instep940, theCCM230 extracts a telephone number for each participant from subfields P1through PNoffield540 within theconference message500. The extracted telephone numbers are used to query aprofile database140 instep942. Each extracted participant telephone number may be used as a search key to locate a participant profile in theprofile database140. If a match for the search key is found (i.e., a profile record is found which contains a participant identifier or usual telephone number field that equals the participant telephone number), then a current telephone number is extracted from the matching profile record by theprofile database140 and returned within an acknowledgement message (ACK) to theCCM230. If no such match is found, a NAK (negative acknowledge message) comprising the participant's telephone number from the conference message500 (which was used as the search key) is returned to theCCM230, in one embodiment. In such a case, the participant's telephone (as it appears in the conference message500) will be used to connect the participant to the conference.
Instep943, theCCM230 receives the query response from theprofile database140. This response comprises each conference participant's current telephone number within either an ACK or a NAK response message, as explained above. The current telephone numbers for each participant are then forwarded by theCCM230 to anauto dialer240 instep945.
Theauto dialer240 proceeds to dial the current telephone number for each conference participant. In one embodiment, when the participant's telephone goes off-hook (i.e., the participant answers the telephone), theauto dialer240 plays a message such as “A conference call is being established. Would you like to be connected? Please respond 1 for YES or 2 for NO.” If a called party (i.e., a potential participant) responds in the negative, the auto dialer disconnects the called party and returns a NAK, comprising the disconnected party's telephone number. A NAK that is received instep950 alerts theCCM230 that a bridge port for this conference may be deallocated. TheCCM230 maintains a list of all conferences that have been set up. This list correlates a conference identifier (extracted by theCCM230 from aconference identifier field520 of a conference message500) to the bridge port numbers of ports allocated by thebridge port allocator235. If any entities listed as conference participants do not join the conference session, then theCCM230 will inform thebridge port allocator235 of the number of ports that may be released back to the unallocated pool of conference bridge ports.
Returning to step945, if a called party answers affirmatively, then the called party will be connected to the conference as a conference participant. This process begins with theauto dialer240 returning an ACK, comprising a telephone switch port number of the called party who responded affirmatively. An ACK is received by theCCM235 instep950. TheCCM230 stores a list of received acknowledgements, and proceeds to connect each participant represented by a telephone switch port number in the acknowledgement list.
In another embodiment, atstep945 theauto dialer240 dials a participant telephone number, and forwards an ACK immediately when the called party's (i.e., the participant's) telephone goes off-hook. A NAK is only returned if the participant's telephone does not go off-hook after a time period set by a system administrator. Again, an ACK/NAK for each participant is received by theCCM230 instep950.
In an alternative embodiment, anauto dialer240 connects to each participant's address via a communications switch. The returned ACK message will then contain a communications switch port number associated with the participant's current address.
Instep955 theCCM230 determines whether there are any acknowledged participants in the acknowledgement list. If so, then instep960 theCCM230 forwards the participant's telephone switch port number and an unused bridge port number (that was allocated for the conference) to aconference connector250. If the participant is connected by theconference connector250, then theconference connector250 returns an ACK, which is received by theCCM230 instep965. Instep970, theCCM230 removes the acknowledged participant from the acknowledgement list.
Processing loops back to step955 and will continue withsteps960,965 and970, until there are no further acknowledged participants in the acknowledgement list. When there are no further participants to connect to the conference session, as determined by theCCM230 instep955, processing exits atstep995. At this point, the conference is established (i.e., the conference is set up and the participants are connected to the conference session).
As stated above, anAIN service node130 retrieves selected invitee directory numbers from the subscriber's call-log through theprovisioning module200, places calls to those invitees automatically, and connects those invitees to the already established conference bridge. Theservice node130 is programmed to receive the selected invitee numbers selected by the subscriber, and to establish connections to the invitees. Theservice node130 provides the communication with the subscriber and all selected invitees by ringing the invitees using the displayed call-log directory numbers. If the invitee's directory number is a wireless number, theservice node130 routes the call to a wireless network so as to reach the wireless unit in a manner well known to those skilled in the art. After theservice node130 makes the calls to all numbers involved, theservice node130 then bridges or connects these calls to the already established bridge, so as to set-up a conference call.
Each piece of terminating equipment in the AIN is assigned a directory number. In the description of the present invention, the term “directory number” is used in its generally understood meaning to be the number which is dialed or input by a caller or source and used by the network to route the communication so as to reach a piece of terminating equipment associated with the dialed directory number. A directory number is commonly referred to as the telephone number. It should be noted that a piece of terminating equipment's directory number is not necessarily unique, but may be shared by a group of pieces of terminating equipment, such as telephone extensions.
As stated above, inFIG. 1, the preferred environment of the present invention includes a telecommunications system that includes aPSTN100, and may in some cases include a wireless network126. The terminating equipment in a wireless network is “wireless” in the sense that the equipment is not connected by any lines or wires to network elements. The terminating equipment in a wireless network receives communications through radio signals rather than through wires or optics. A cellular telephone network is an example of a wireless network. Thus, a conference call participant's communication means may include a cellular telephone, a mobile telephone, a mobile station, a portable telephone, and other devices that receive communications through radio signals.
As is well known to those skilled in the art, thePSTN100 is connected to the wireless network126 through an access tandem. The connection of thePSTN100 to the wireless network126 through an access tandem (or similar network element) allows for the interconnection of these two communication systems. Such interconnection is necessary so that a call from a wireline unit such as telephone may be connected to a wireless unit such as mobile telephone. The wireless network includes a geographic radio service area divided into cells, with each cell being generally serviced by a broadcast antenna which permits communications between a wireless unit operating within the area of the cell and a cell control. The cell control, in turn, is connected to a wireless network switch, which is also referred to as the mobile switching center. The wireless network switch communicates with the cell control either through dedicated telephone facilities, or, through a cell-to-mobile switching center data link. The wireless network switch tracks the location of wireless units associated with that switch, and is able to provide information with respect to the location and/or availability of any particular communication device.
A subscriber interface module is an interface containing the automatic conference call feature available to the subscriber.FIG. 10 illustrates one embodiment of a subscriber interface module of the present invention. The interface may be included in a Personal Information Manager (PIM), such as a landline telephone, mobile phone, caller identification (ID) module connected to a telephone, personal computer, cordless phone, personal digital assistant (PDA), or any other interface module capable of displaying a call-log. As an example, amobile telephone1000 comprises anLCD display1001, a set offeature keys1002, a set ofdialpad keys1003, aselection key1004, and a set ofarrow keys1005 for scrolling through features displayed on theLCD display1001. In a preferred embodiment of the present invention, the feature keys include a <conference key>1006.
The features of theinterface module1000 include a call-log feature. As is known in the art, in a call-log, summaries are maintained of all incoming and outgoing calls in an interactive, real-time, user-accessible “call-log” portion of a call management database. The call-log allows a subscriber to know who called, when they called, which calls were missed even if no voice mail or other form of message was left, and to return calls automatically through simple buttons. Personal Identifier (PI) records are automatically updated every time a call is placed or received. The call-log database may be maintained by any of the numerous PIMs listed above. The call-log database is used to maintain a contact list. Each record in the contact list has a PI number, usually the party telephone number, associated with it that can be used to initiate a conference call by selecting the desired PIs and conferencing. Caller identification (ID), as is commonly known in the art, is used to identify outside callers and this information is recorded in the call-log database. Caller ID is a subscriber service which typically provides the telephone number and household name information about a calling party to a called party before the call is answered. Basic call related information is transmitted from the local telephone company to the called party while the called party's telephone is in a hung-up or on-hook state, e.g., between the first and second rings. The caller ID information is stored in a call-log database which may be accessed using thefeature1002 andselection keys1004 of the PIM.
Referring again toFIG. 10, themobile phone1000 displays the call-log on theLCD display1001. The user of the phone activates the telephone keys to control the operation of themobile phone1000. For example, the user activates thedialpad keys1003 to dial a telephone number for an outgoing telephone call. The user may scroll through the call-log and select desired conference call participants. In one embodiment, when a subscriber selects a conference participant, the <select key>1004 is activated which stores the selected party's directory information. When all parties to the conference call have been selected, the user activates the <conference key>1006, from above, to initiate a conference call. In an alternative embodiment, the conference call feature of the present invention is selected using a feature key, which may perform multiple functions on the telephone. Any key on a PIM may be programmed to carry out a <select key>1004 and/or <conference key>1006 function. The subscriber interface detects the activation of the conference feature, and reports selected key activations to thePSTN100 or PBX126. In addition, the user interface generates messages to theLCD display1001, such as a message indicating that a conference call is in progress and indicating the number and personal identification information of the parties involved in the call. A further feature may include a time quantity displayed, indicating a real-time measurement of the time involved in a conference call.
In summary, the present invention provides an easy to use method to automatically establish a conference call using the call-log feature of a communication device. When a conference call is desired by a subscriber, using a communication device, the subscriber simply selects the call-log feature and views it on the devices LCD display. The subscriber then scrolls through the call-log and selects desired invitees. When selected, the subscriber next initiates the automatic conference call feature by actuating the <conference key>, or like activating key. As stated above, the <conference key> may comprise a key designated solely with a conference function, or, the conference function may be one of multiple features activated by a single key
The selected call-log directory information is sent to and received by theProvisioning module200. The Provisioning module captures the conference participant phone numbers selected on the call-log display, and creates theConference Record400, which is stored inData store210 in an “immediate conference queue”. TheScheduler225 then reads the queue and forwards animmediate Conference Message500 to theCCM230, and processing continues according toFIG. 9 (for a message type 3 [immediate]Conference Message500.
In response to the ringing of their communication device, the invitees then have the option of either answering the call and joining the conference call, or, ignoring the call and opting not to join. There is a generation and transmission of ringing signals to the attendee units associated with the call-log directory numbers of the list accessed by the subscriber'sdevice105, which provides indications to attendees positioned at the attendee devices to take their respective communication devices off-hook. When taken off-hook, the present invention automatically conferences the selected attendee devices together with the initiatingsubscriber device105. In one embodiment, the present invention includes a signal to all invitees, which may be displayed on their communication device, that they are invited to participate in a conference call. The embodiment may further include the ability to display to the invitee all parties invited to participate, and, which parties are currently participating in the conference call. Once a party is participating in a call, the connection to their device is terminated when that party disconnects. The disconnection may be made by the subscribing party or by the answering party.
Various embodiments of the present invention have been described in fulfillment of the various objects of the invention. It should be recognized that these embodiments are merely illustrative of the principles of the present invention. Numerous modifications and adaptations thereof will be apparent to those skilled in the art without departing from the spirit and scope of the present invention.