As used herein, the term “telecommunication” is generally defined as the transmission and reception of signals over a distance for the purpose of communication. A “telephony device” (or “telephony terminal” or “telephone”) is generally defined as a telecommunications device which is used to transmit and receive sound (most commonly voice and speech) across distance. A “communications device” (or “communications terminal”) is a device that transmits and receives signals for the purpose of communication.
Turning now to
Fixed or mobile communication terminals 12 communicate over communication links to the IP access network(s)/Internet 17 as is well known. Such communication can be carried out by a cable modem coupled to a hybrid fiber coax data network, a DSL modem coupled to a DSL access network, or a radio interface coupled to a Wi-Fi or Wi-Max access network. The fixed or mobile communication terminals 12 can be any of a number of communication devices including personal computers, laptop computers, personal digital assistants, networked kiosks, VOIP phones, traditional phones connected to VOIP gateways, and the like.
The mobile access network 16 interfaces to a packet switched core network 19 and to a circuit switched core network 21. Packet switched traffic (e.g., IP packet data) that originates from (or is destined to) the mobile telephony devices 11 is routed over the packet switched core network 19. Circuit switched traffic (e.g., voice calls, SMS messages) that originates from (or is destined to) the mobile telephony devices 11 is routed over the circuit switched core network 21.
The packet switched core network 19 connects to the Internet 27 and includes functionality for data session management of the mobile telephony devices 11 and for routing packet switched traffic into and out of the packet switched core network 19. In this manner, the packet switched core network enables the mobile telephony devices 11 to connect to Internet-connected devices (e.g., a web server, a VOIP communication terminal, etc.) as needed.
The circuit switched core network 21 includes a mobile switching center (MSC) 23 and an SMS center (SMS-C) 25. Generally, the MSC 23 connects the circuit switched core network 21 to the public switched telephone network 18 and manages and routes circuit switched voice traffic into and out of the circuit switched core network 21. In this manner, the MSC 23 enables the mobile telephony devices 11 to connect to POTS telephony devices that interface to the PSTN 18 as needed.
The SMS-C 25 functions as a centralized store-and-forward device that accepts SMS messages and buffers the received SMS messages until a suitable delivery time (e.g., the destination mobile telephony device 11 is powered on and the location known). The SMS-C 25 also provides an interface in accordance with a communication protocol (e.g., UCP, SMPP, Sema OIS, CIMD2) that allows for communication of SMS messages to and from other cell networks and to and from other external SMS processing devices (e.g., the SMS gateway 27). Preferably, the external SMS processing device(s) is (are) connected to the SMS-C 25 over a wide area network such as the Internet.
Numerous technologies, such as GSM, CDMA, EDGE and W-CDMA technology, can be used to implement the mobile access network 16 and the supporting core networks 19 and 21. GSM technologies provide GPRS services which can be used for packet switched applications. 3G CDMA technologies provide code division multiplexing technology for packet switched applications. EDGE technology provides enhanced GPRS services. High-speed data applications such as video services and other multimedia services benefit from the increased data capacity provided by the enhanced GPRS services. W-CDMA technology employs wideband code division multiplexing technology to provide high speed packet switched data rates that is suitable for high-speed data applications such as video services and other multimedia services.
The communication system of
The SMS messaging format, which is specified by the ETSI organization (documents GSM 03.40 and GSM 03.38), can be up to 160 characters long, where each character is 7 bits according to the 7-bit default alphabet. An eight-bit message format (max 140 characters) can also be used, but this format is usually not viewable by the phones as text messages; instead it is used for data in smart messaging (images and ringing tones) and OTA provisioning of WAP settings. A 16-bit message format (max 70 characters) can also be used for Unicode (UCS2) text messages and is viewable by most phones. There are two ways of sending and receiving SMS messages: by a protocol description unit (PDU) mode or by a text mode. The PDU mode contains not only the text of the message, but also a lot of meta-information about the sender (e.g., the sender's SMS service center, the time stamp, etc). The text mode is just an encoding of the bit stream represented by the PDU mode. Alphabets may differ and there are several encoding alternatives when displaying an SMS message. The most common options are “PCCP437”, “PCDN”, “8859-1”, “IRA” and “GSM”. These options are set by the at-command AT+CSCS. An application capable of reading incoming SMS messages, can thus use text mode or PDU mode. If text mode is used, the application is bound to (or limited by) the set of preset encoding options. If PDU mode is used, any encoding can be implemented.
Instant messages are generated by applications for carrying out text conversations that are to happen in real-time. Instant message service providers (e.g., AOL Instant Messenger, Yahoo! Messenger, Skype, Google Talk, Windows Messenger, ICQ, etc.) typically maintain a facility 26 that includes a database storing a list of contacts for each subscriber and presence information. The presence information indicates the availability of the contacts. Most instant messaging service providers allow users to set and update their presence information so that peers get notified whenever the user is available, busy, or away. The facility 26 also includes logic that establishes communication sessions between subscribers (or between a subscriber and a user of another provider). The facility 26 typically employs proprietary protocols for maintaining presence information and receiving notifications related thereto (for example, a notification when a user logs-in or comes back from lunch), for managing a session of real-time messages between two or more participants, and for communicating such real time messages between the two or more participants of a given session. The message format for the real-time messages communicated between the participants of a given session is typically proprietary in nature and thus can vary between service providers. Standards-based protocols for instant messaging, such as XMPP and Jingle (defined at http://www.xmpp.org/extensions/xep-0166.html) can also be used.
Subscribers of the service access a database 29. Each subscriber can have the following information associated therewith in the database 29:
the user name of the subscriber;
a password and possibly other information for authentication of the subscriber;
at least one phone number for the subscriber, which can the number assigned to the subscriber's traditional POTS telephony device for home or business purposes, a number assigned to the subscriber's mobile telephony device, an identifier assigned to the subscriber's IP telephony device, or other identifier that is used to establish a voice connection to the subscriber;
at least one IM screen name/IM Service Provider for the subscriber, which is used to route IM messages and possibly for establishing a voice connection to the subscriber;
at least one email address for the subscriber;
a home address for the subscriber; and
a business address for the subscriber.
Subscribers can add and modify a list of contacts for the subscriber. The list is stored in the database 29. The following information can be associated with a given contact in the subscriber's contact list:
a short name for the contact;
at least one phone number for the contact, which can the number assigned to the contact's traditional POTS telephony device for home or business purposes, a number assigned to the contact's mobile telephony device, an identifier assigned to the contact's IP telephony device, or other identifier that is used to establish a voice connection to the contact;
at least one IM screen name/IM Service Provider for the contact, which is used to route IM messages and possibly for establishing a voice connection to the contact;
at least one email address for the contact;
a home address for the contact; and
a business address for the contact.
Subscriber's access to the database 29 can be accomplished over the Internet with a web server (or application server) 31 that provides an interface therebetween. This configuration allows users to access and update the database 29 (and possibly manage other information) via user interaction with a web browser in communication with the web server (or application server) 31 over the Internet. The web browser can be executing on one of the Internet-connect fixed or mobile communication terminals 12. Alternatively, it can be a micro-browser executing on one of the mobile telephony devices 11. In other embodiments, subscriber access to the database 29 can be realized by other communication means, such as messages directed to the service over any one of the diverse messaging formats supported by the service, interaction with an IVR system managed by the service, and/or other means.
A voice call is established in response to receiving a message conforming to one of the diverse messaging formats supported by the service. The message (which is referred to below as a call request message) is communicated from a subscriber-operated communication device, which can be one of the mobile telephony devices 11 or one of the fixed or mobile communication terminals 12. The call request message encapsulates plain text with a predetermined command syntax that includes the following:
i) text that identifies the message as a particular command for requesting establishment of a voice call by the service;
ii) text that identifies one or more participants of the voice call to be established by the service; and
iii) optional text that specifies the date and/or time of the voice call to be established by the service.
The call request message that is formatted in accordance with an SMS message format is referred to below as an SMS-type call request message. The call request message that is formatted in accordance with an IM message format is referred to below as an IM-type call request message. The call request message that is formatted in accordance with a proprietary IP message format is referred to below as a proprietary-IP-type call request message.
The subscriber that generated the call request message (who is referred to below as the “originating subscriber”), is identified from data that is communicated as part of the call request message. Such data can include the ANI of the mobile telephony device that originated the SMS-type call request message, the IM screen name/IM Service Provider of the IM-type call request message, or the source IP address of the proprietary-IP-type call request message.
The text of ii) as described above, which identifies a given participant for the voice call, can refer to the short name for a contact stored in the subscriber's contact list as part of the database 29. Alternatively, the text can represent a phone number for the given participant.
In the preferred embodiment, the call request message encapsulates plain text with a command syntax as follows:
The service includes logic 33 that receives call request messages over the diverse messaging formats and parses the text embedded in the call request messages to extract the text pertaining to the participants of a voice call. In the event that the extracted text is not a telephone number (i.e., it represents the short name of a participant), the logic 33 accesses the database 29 to retrieve from the originating subscriber's contact list the phone number for the short name represented by the extracted text. The logic 33 also accesses the database 29 to identify the appropriate telephone number for originating subscriber. The logic 33 also parses the text embedded in the call request message to identify the date and time for the voice call as specified therein, if any. The logic 33 then carries out processing that establishes the voice call to the phone number for the originating subscriber and to the phone number(s) of the other participant(s) of the voice call (which is(are) returned from the contact database if specified by short name). Such call establishment is carried out at the particular date and time specified by the text of the call request message, or possibly immediately in the event that the call request message does not specify a date and time. In the preferred embodiment, the call establishment is carried out by a conference bridge 35 that sets up and connects together the originating subscriber and the other participant(s) for full duplex voice conversations therebetween. The conference bridge 35 drops the originating subscriber and/or other participant(s) of the voice call upon receiving signaling that indicates such participant has “hung up” the participant's respective telephony devices.
In the illustrative embodiment of the invention, the logic 33 includes an SMS gateway 27 for receiving (and possibly sending) SMS messages in accordance with one or more SMS messaging formats, an IM gateway 41 for receiving (and possibly sending) IM messages in accordance with one or more IM messaging formats, and an IP Message monitor 43 for receiving (and possibly sending) IP messages in accordance with one or more proprietary IP messaging formats.
The SMS Gateway 27 receives incoming SMS messages that are addressed to a reserved telephone number (or reserved short code) for the service and sends outgoing SMS from the reserved telephone number (or reserved short code) of the service. The SMS gateway 27 interfaces to the SMS-C 25 preferably using a communication protocol such as UCP, SMPP, Sema OIS, or CIMD2 that allows for the communication of SMS messages therebetween. The SMS gateway 27 interfaces to an SMS Message Processing block 45 that processes each given incoming SMS message received at the SMS Gateway 27 to extract the text data encapsulated in the given SMS message and passes the extracted text data to a text parsing engine 51.
The IM Gateway 41 receives incoming IM messages that are addressed to one or more reserved IM user names for the service. The IM messages can also specify corresponding IM service providers. For example kadoink@gmail.com can be used to identify the reserved IM user name “kaDoink” for the service on the Google Talk IM Service. The IM Gateway 41 also sends outgoing IM messages addressed from such reserved IM user name(s) and service provider(s) if need be. The IM Gateway 41 interfaces to one or more IM Service Provider facilities 26 (e.g., facilities for AOL Instant Messenger, Yahoo! Messenger, Skype, Google Talk, Windows Messenger, ICQ, etc.) to maintain presence information as well as for session establishment for sending/receiving messages to/from subscribers of the one or more facilities 26. Such communication can employ proprietary protocols and/or standardized protocols such as XMPP and Jingle as discussed above. The IM Gateway 41 can carry out protocol translation to allow for interoperability between different IM messaging formats and platforms, if need be. The IM Gateway 41 interfaces to an IM Message Processing block 47 that processes each given incoming IM message received at the IM Gateway 41 to extract the text data encapsulated in the given IM message and pass the extracted text data to the text parsing engine 51.
The IP Message Monitor 43 receives incoming IP messages that routed to a predetermined IP address and port, and can also send outgoing IP messages that are routed to a predetermined IP address and port. The IP messages can use TCP or UDP packets as a transport mechanism. The message format for the incoming and outgoing IP messages can be proprietary in nature and known only by the two end points. The IP Message Monitor 43 interfaces to an IP Message Processing block 49 that processes each given IP message received at the IP Message Monitor 43 to extract the text data encapsulated in the given IP message and passes the extracted text data to the text parsing engine 51.
The text parsing engine 51 analyzes the text data to confirm that it begins with text that identifies the message as a particular type for requesting establishment of a voice call by the service. For the preferred command syntax described above, the text parsing engine 51 confirms that the text data begins with “CALL”. Upon such confirmation, the text parsing engine 51 analyzes the text data to identify the text that identifies the participant(s) of the voice call (e.g., target field(s) of the command syntax described above) as well as the text that identifies the date and time of the voice call (e.g., the date and time fields of the command syntax described above), if any. The text parsing engine 49 outputs this text along with data identifying the originating subscriber of the voice call request message to Call Request Processing block 53.
The Call Request Processing block 53 includes block 55 that accesses the database 29 to identify the telephone number for each participant of the voice call (if the participant is not identified by a telephone number within the call request message). More than one phone number can be stored for a given contact in the originating subscriber's contact list as part of the database 29. In this case, the originating subscriber might possibly specify one of these telephone numbers for use with the service (or more particularly for use in conjunction with call request messages communicated to the service). Alternatively, presence information for the participant may be used to identify the appropriate telephone number for the participant. In yet another alternative, a rule-based approach that specifies a sequential order amongst the multiple telephone numbers can be used. The processing is then adapted to sequence through the ordered list of telephone numbers for joining the participant to the voice call.
Block 55 can also identify the telephone number of the originating subscriber, which can be derived from the ANI of the originating subscriber for SMS-type messages or possibly by accessing the database 29 to identify the telephone number for the originating subscriber. More than one phone number can be stored for the originating subscriber as part of the database 29. In this case, the originating subscriber might possibly specify one of these telephone numbers for use with the service (or more particularly for use in conjunction with call request messages communicated to the service). Alternatively, presence information for the originating subscriber may be used to identify the appropriate telephone number for the originating subscriber. In yet another alternative, a rule-based approach that specifies a sequential order amongst the multiple telephone numbers can be used. The processing is then adapted to sequence through the ordered list of telephone numbers for joining the originating subscriber to the voice call.
Block 55 outputs to block 57 the telephone number(s) of the participants as well as the telephone number of the originating subscriber as well as the date and time of the voice call, if any. Block 57 generates a Call Object that specifies the telephone number for the originating subscriber, the telephone number(s) for the other participants, and date and time for the voice call, and adds this object to the Call Object Queue 59. If no date and time is specified, then the date and time for the call (or a flag corresponding thereto) is set to initiate immediate call setup.
The Call Object Queue 59 is a queue of Call Objects that is processed at regular intervals (e.g., every minute) to determine if the current date/time matches the date/time for any Call Object in the queue (or that the call should be set up immediately). If so, the telephone number for originating subscriber and the telephone number for the other participant(s) is passed to Call Management Processing block 61, which cooperates with the conference bridge 35 to set up, carry out, and tear down (when complete) a voice call between the telephone numbers of the originating subscriber and the other participant(s) as dictated by the Call Object, and preferably bills the originating subscriber's account for the voice call. The telephone number for the originating subscriber as well as the telephone number for the other participant(s) of the voice call can be for a mobile telephony device, a POTS telephony device, a VOIP communication terminal, or other communication device. It is also possible that the call request processing can restrict the voice call to certain telephone numbers based on geographical scope (i.e., not allow international calls) or other constraints.
Block 57 can also cooperate with the SMS Gateway 27 to generate and send an SMS message that is addressed to the originating subscriber and possibly the other participant(s) of the voice call, whereby the SMS message announces the upcoming voice call. If the voice call is to take place at a future date/time, more than one such SMS message can be generated and sent for voice call reminders and call announcement. Block 57 can also cooperate with the IM Gateway 41 to generate and send IM messages for call announcement and call reminders. Block 57 can also cooperate with the IP Message Monitor 43 to generate and send IP messages for call announcement and call reminders.
Block 57 can also cooperate with the SMS Gateway 27 to exchange one or more SMS messages/replies with the originating subscriber such that the originating subscriber can confirm the particulars of the voice call. If confirmation is successful, the Call Object is added to the Call Object Queue 59; otherwise, the Call Object is not added to the Call Object Queue 59. Block 57 can also cooperate with the IM Gateway 41 to exchange one or more IM messages/replies with the originating subscriber such that the originating subscriber can confirm the particulars of the voice call as described above. Block 57 can also cooperate with the IP Message Monitor 43 to exchange one or more IP messages/replies with the originating subscriber such that the originating subscriber can confirm the particulars of the voice call as described above.
In the event that an error occurs in the processing of a given call request message (for example, the text does not conform to the predetermined syntax, or the text does not match any contact in the originating subscriber's contact list), the generation of a Call Object for the voice call (and subsequent processing of the Call Object) are avoided such the voice call is not established for the given call request message. In this case, block 57 (or the other elements of the processing logic 33) can cooperate with the SMS Gateway 27 to generate and send one or more SMS messages to the originating subscriber that provides an indication of the error. Block 57 (or the other elements of the processing logic 33) can also cooperate with the IM Gateway 41 to generate and send one or more IM messages to the originating subscriber that provides an indication of the error. Block 57 (or the other elements of the processing logic 33) can also cooperate with the IP Message Monitor 43 to generate and send one or more IP messages to the originating subscriber that provides an indication of the error.
As described above, call request messages can be communicated from a number of different subscriber-operated communication devices which can support a variety of diverse messaging formats and platforms.
For example,
In another example,
In another example,
In another example,
In order to provide a better understanding of the operation of the telecommunication system of the present invention and parts thereof, the call message request processing will be illustrated below for examples of the diverse messaging formats described herein. The examples utilize the preferred command syntax “CALL <TARGET1><TARGET2>. . . <DATE><TIME>”. It is assumed that the service has reserved short code “29999” for SMS messaging, kadoink@gmail.com for user name “kaDoink” on the Google Talk IM Service, and IP address “64.147.172.15” and port “51101” for IP messaging. It is also assumed that the originating subscriber has accessed the database 29 to include at least the following information:
Subscriber Name: “William Waytena”
ANI of Mobile Telephone for “William Waytena”: 415-555-1213
IM User Name/Service Provider: WillyWay111@gmail.com
Short Name for Contact: HOME
Telephone Number for Contact “HOME”: 415-555-1212
Short Name for Contact: JOHN
Telephone Number for Contact “JOHN”: 203-555-5555
The originating subscriber, “William Waytena” , utilizes an SMS Application operating on a communication terminal (for example, his mobile telephony device with an ANI of 415-555-1213) to generate and send an SMS message to the reserved short code “29999” for the service. The SMS message encapsulates the following plain text: “CALL HOME”. This SMS message is forwarded to the SMS Gateway 27 for the service (which is adapted to receive SMS messages addressed to the reserved short code “29999” of the service). The SMS Gateway 27 forwards the received SMS message to the SMS Message Processing block 45. The SMS Message Processing block 45 extracts the ANI of the originating mobile subscriber terminal and the text data of the SMS message, and passes this data to the text parsing engine 51. The text parsing engine 51 analyzes the text data to confirm that it starts with “CALL”. This confirmation is successful and the text parsing engine 51 continues to analyze the text data to identify “HOME” as a target field. The target field “HOME” along with the ANI of the originating mobile subscriber terminal is passed to the Call Command Processing block 53. The Call Command Processing block 53 includes block 55 which accesses the Database 29 to identify the telephone number “415-555-1212” for the target field “HOME”. The operations of block 55 preferably performs the following:
i) identifies the subscriber “William Waytena” (or an identifier corresponding thereto) for the ANI “415-555-1213” of the originating mobile subscriber terminal; and
ii) accesses the contact list for the originating subscriber “William Waytena” to identify the phone number “415-555-1212” for the contact “HOME” that matches the target field “HOME”.
Block 55 passes the ANI “415-555-1213” of the originating mobile subscriber and the phone number “415-555-1212” for the contact corresponding to the target field “HOME” to block 57.
In alternate embodiments, it is possible that the ANI of the originating mobile subscriber that is passed to block 57 can be substituted with another telephone number. For example, the originating subscriber might possibly specify another telephone numbers for use with the service (or more particularly for use in conjunction with call request messages communicated to the service) as part of the information stored in the database 29. Alternatively, presence information for the originating subscriber may be used to identify the appropriate telephone number for the originating subscriber. In yet another alternative, a rule-based approach that specifies a sequential order amongst the multiple telephone numbers can be used. The processing is then adapted to sequence through the ordered list of telephone numbers for joining the originating subscriber to the voice call.
Block 57 generates a Call Object that specifies the telephone number “415-555-1213” for the originating subscriber, the telephone number “415-555-1212” for the other participant, and the date and time for the voice call, and adds this object to the Call Object Queue 59. Because the call request message did not specify a date and time, the date and time for the voice call (or a flag corresponding thereto) is set to initiate immediate call setup.
The Call Object Queue 59 is processed at regular intervals (e.g., every minute) to determine if the current date/time matches the date/time for any Call Object in the Call Object Queue 59 (or that the voice call should be set up immediately). If so, the telephone number for originating subscriber and the telephone number for the other participant(s) is passed to Call Management Processing block 61. This processing identifies the Call Object for telephone numbers “415-555-1213” and “415-555-1212” for immediate call setup and immediately passes the telephone numbers “415-555-1213” and “415-555-1212” to the Call Management Processing block 61.
The Call Management Processing block 61 cooperates with the conference bridge 35 to set up, carry out, and tear down (when complete) a voice call between the telephone numbers “415-555-1213” and “415-555-1212” as dictated by the Call Object, and preferably bills the originating subscriber's account for the voice call.
Block 57 can also cooperate with the SMS Gateway 27 to generate and send an SMS message that is addressed to the originating subscriber and possibly the other participant(s) of the voice call, whereby the SMS message announces the upcoming voice call. Block 57 can also cooperate with the SMS Gateway 27 to exchange one or more SMS messages/replies with the originating subscriber such that the originating subscriber can confirm the particulars of the voice call. If confirmation is successful, the Call Object is added to the Call Object Queue 59; otherwise, the Call Object is not added to the Call Object Queue 59.
The originating subscriber, “William Waytena”, utilizes an IM Application operating on a communication terminal (for example, on his mobile telephony device with an ANI of 415-555-1213) to login in as IM user WillyWay111@gmail.com on a Sunday night, and to generate and send an IM message to the reserved short name for the service (kadoink@gmail.com). The IM message encapsulates the following plain text: “CALL HOME JOHN TUESDAY 2 PM”. This IM message is forwarded to the IM Gateway 41 for the service (which is adapted to receive IM messages addressed to the reserved short name “kadoink@gmail.com 29999”. The IM Gateway 41 forwards the received IM message to the IM Message Processing block 47. The IM Message Processing block 47 extracts the IM user name and possibly IM service provider of the originating subscriber and the text data of the SMS message, and passes this data to the text parsing engine 51. The text parsing engine 51 analyzes the text data to confirm that it starts with “CALL”. This confirmation is successful and the text parsing engine 51 continues to analyze the text data to identify “HOME” AND “JOHN” as target fields. It also analyzes the text data to identify a particular date and time that corresponds to the date and time fields “TUESDAY” and “2 PM”. The target fields “HOME” and “JOHN”, the particular date and date corresponding to the date and time fields “TUESDAY” and “2 PM” along with the IM user name and possibly IM service provider of the originating subscriber are passed to the Call Command Processing block 53. The Call Command Processing block 53 includes block 55 which accesses the Database 29 to identify the telephone number “415-555-1212” for the target field “HOME” and the telephone number “203-555-5555” for the target field “JOHN”. The operations of block 55 preferably performs the following:
i) identifies the subscriber “William Waytena” (or an identifier corresponding thereto) for the IM user WillyWay111@gmail.com of the originating subscriber;
ii) accesses the contact list for the originating subscriber “William Waytena” to identify the phone number “415-555-1212” for the contact “HOME” that matches the target field “HOME”;
iii) accesses the contact list for the originating subscriber “William Waytena” to identify the phone number “203-555-5555” for the contact “JOHN” that matches the target field “JOHN”; and
iv) identifies a phone number (e.g., “415-555-1213”) for the originating subscriber “William Waytena”.
Block 55 passes the phone number “415-555-1213” of the originating mobile subscriber and the phone numbers “415-555-1212” and “203-555-5555” for the contacts corresponding to the target fields “HOME” and “JOHN”, respectively, and the date and time for the voice call to block 57.
In alternate embodiments, it is possible that the ANI of the originating mobile subscriber that is passed to block 57 can be substituted with another telephone number. For example, the originating subscriber might possibly specify another telephone numbers for use with the service (or more particularly for use in conjunction with call request messages communicated to the service) as part of the information stored in the database 29. Alternatively, presence information for the originating subscriber may be used to identify the appropriate telephone number for the originating subscriber. In yet another alternative, a rule-based approach that specifies a sequential order amongst the multiple telephone numbers can be used. The processing is then adapted to sequence through the ordered list of telephone numbers for joining the originating subscriber to the voice call.
Block 57 generates a Call Object that specifies the telephone number “415-555-1213” for the originating subscriber, the telephone numbers “415-555-1212” and “203-555-5555” for the other participants, and the date and time for the voice call, and adds this object to the Call Object Queue 59. In this example, the date and time fields in the call request message (i.e., “TUESDAY” and “2 PM”) are specified in a format relative to the current date and time. In this case, the processing of block 57 derives the date and time for the voice call based upon the current date and time (which can be derived by synchronizing a system date and time to a time server or another time tracking scheme well known in the art) and the offset between the current date and time and the future date and time as specified in the call request message.
The Call Object Queue 59 is processed at regular intervals (e.g., every minute) to determine if the current date/time matches the date/time for any Call Object in the Call Object Queue 59 (or that the call should be set up immediately). If so, the telephone number for originating subscriber and the telephone number for the other participant(s) is passed to Call Management Processing block 61. This processing identifies the Call Object for telephone numbers “415-555-1213”, “415-555-1212” and “203-555-5555” at the date and time for the voice call and passes the telephone numbers “415-555-1213”, “415-555-1212”, “203-555-5555” to the Call Management Processing block 61.
The Call Management Processing block 61 cooperates with the conference bridge 35 to set up, carry out, and tear down (when complete) a voice call between the telephone numbers “415-555-1213”, “415-555-1212”, “203-555-5555” as dictated by the Call Object, and preferably bills the originating subscriber's account for the voice call.
Block 57 can also cooperate with the IM Gateway 41 to generate and send an IM message that is addressed to the originating subscriber (WillyWay111@gmail.com) and possibly the other participant(s) of the voice call, whereby the IM message announces the upcoming voice call. Block 57 can also cooperate with the IM Gateway 41 to exchange one or more IM messages/replies with the originating subscriber such that the originating subscriber can confirm the particulars of the voice call. If confirmation is successful, the Call Object is added to the Call Object Queue 59; otherwise, the Call Object is not added to the Call Object Queue 59.
The originating subscriber, “William Waytena”, utilizes a Command Line IP messaging application operating on a communication terminal (for example, on a communication terminal 12B) to generate and send an IP message to the reserved IP address “64.147.172.15” and port “51101” for the service. The IP message encapsulates the following plain text: “CALL HOME 212-555-1212 TODAY 2 PM” and includes data that identifies the originating subscriber. This IP message is forwarded to the IP Message Monitor 43 for the service (which is adapted to receive IP messages addressed to the reserved IP address “64.147.172.15” and port “51101”. The IP Message Monitor 43 forwards the received IP message to the IP Message Processing block 49. The IP Message Processing block 49 extracts the data that identifies the originating subscriber and the text data of the IP message, and passes this data to the text parsing engine 51. The text parsing engine 51 analyzes the text data to confirm that it starts with “CALL”. This confirmation is successful and the text parsing engine 51 continues to analyze the text data to identify “HOME” AND “212-555-5555” as target fields. It also analyzes the text data to identify a particular date and time that corresponds to the date and time fields “TODAY” and “2 PM”. The target fields “HOME” and “212-555-5555”, the particular date and date corresponding to the date and time fields “TODAY” and “2 PM” along with the data identifying the originating subscriber are passed to the Call Command Processing block 53. The Call Command Processing block 53 includes block 55 which accesses the Database 29 to identify the telephone number “415-555-1212” for the target field “HOME”. It need not perform any look-up operations for the telephone number “203-555-5555”. The operations of block 55 preferably performs the following:
i) identifies the subscriber “William Waytena” (or an identifier corresponding thereto) for the data identifying the originating subscriber;
ii) accesses the contact list for the originating subscriber “William Waytena” to identify the phone number “415-555-1212” for the contact “HOME” that matches the target field “HOME”; and
iv) identifies a phone number (e.g., “415-555-1213”) for the originating subscriber “William Waytena”.
Block 55 passes the phone number “415-555-1213” of the originating mobile subscriber, the phone numbers “415-555-1212” and “203-555-5555” corresponding to the target fields of the IP message, and the date and time for the voice call to block 57.
In alternate embodiments, it is possible that the ANI of the originating mobile subscriber that is passed to block 57 can be substituted with another telephone number. For example, the originating subscriber might possibly specify another telephone numbers for use with the service (or more particularly for use in conjunction with call request messages communicated to the service) as part of the information stored in the database 29. Alternatively, presence information for the originating subscriber may be used to identify the appropriate telephone number for the originating subscriber. In yet another alternative, a rule-based approach that specifies a sequential order amongst the multiple telephone numbers can be used. The processing is then adapted to sequence through the ordered list of telephone numbers for joining the originating subscriber to the voice call.
Block 57 generates a Call Object that specifies the telephone number “415-555-1213” for the originating subscriber, the telephone numbers “415-555-1212” and “203-555-5555” for the other participants, and the date and time for the voice call, and adds this object to the Call Object Queue 59. In this example, the date and time fields in the call request message (i.e., “TODAY” and “2 PM”) are specified in a format relative to the current date and time. In this case, the processing of block 57 derives the date and time for the voice call based upon the current date and time (which can be derived by synchronizing a system date and time to a time server or another time tracking scheme well known in the art) and the offset between the current date and time and the future date and time as specified in the call request message.
The Call Object Queue 59 is processed at regular intervals (e.g., every minute) to determine if the current date/time matches the date/time for any Call Object in the Call Object Queue 59 (or that the call should be set up immediately). If so, the telephone number for originating subscriber and the telephone number for the other participant(s) is passed to Call Management Processing block 61. This processing identifies the Call Object for telephone numbers “415-555-1213”, “415-555-1212” and “203-555-5555” at the date and time for the voice call and passes the telephone numbers “415-555-1213”, “415-555-1212”, “203-555-5555” to the Call Management Processing block 61.
The Call Management Processing block 61 cooperates with the conference bridge 35 to set up, carry out, and tear down (when complete) a voice call between the telephone numbers “415-555-1213”, “415-555-1212”, “203-555-5555” as dictated by the Call Object, and preferably bills the originating subscriber's account for the voice call.
Block 57 can also cooperate with the IP Message Monitor 43 to generate and return an IP message that is addressed to the originating subscriber and possibly the other participant(s) of the voice call, whereby the IP message announces the upcoming voice call. Block 57 can also cooperate with the IP Message Monitor 43 to exchange one or more IM messages/replies with the originating subscriber such that the originating subscriber can confirm the particulars of the voice call. If confirmation is successful, the Call Object is added to the Call Object Queue 59; otherwise, the Call Object is not added to the Call Object Queue 59.
In alternate embodiments, the date and time fields of the call request message can have different alpha-numeric such as “9/1/06 9 am”, “9/1/06 9 a”, “9 am 9/1/06”, “9 a 9/1/06”, “9 a 9/1” where 2006 as the current year is implied, “9/1 9 a” where 2006 as the current year is implied, “9 am” for the current date, “9 am Sat”, “Sat 9 am”, “9 a Sat”, “Sat 9 a”, “15 m” or “15 m” or “15 minutes” for 15 minutes later than the current date and time, or “2 hours” or “2 h” or “2 h” for 2 hours later than the current date and time. In these cases, the processing logic 33 is adapted to interpret these text fields to generate data for the date and time that corresponds thereto and associate such data with the corresponding Call Object or other data structure for initiating the voice call to the appropriate participants at the date and time specified by the call request message.
In other alternate embodiments, a subscriber can assign one or more contacts to a group with a specified group name. One or more target fields of the call request message can include text corresponding to a group name. In this case, the call request message processing joins (or attempts to join) to the voice call all of the members of the group that matches the group name specified by the target field.
The database 29 (or other data storage means) can maintain a list (or other data structure) of scheduled voice calls pertaining to a given subscriber, wherein the given subscriber is the originating subscriber for each scheduled voice call on the list. The given subscriber can access this list and update any scheduled voice call therein. Such updates can include, for example, adding one or more participants, removing one or more participants, changing the date and/or time of the voice call, and canceling the voice call. The list (or other data structure) of calls can also include scheduled voice calls pertaining to a given subscriber wherein the given subscriber is a participant of the scheduled voice call. For these calls, it is contemplated that the subscriber will be able to view the calls and possibly remove himself/herself as a participant of the voice call, but cannot add participants to the voice call or cancel the voice call (unless the subscriber is the only other participant of the call other than the originating subscriber).
It is also contemplated that the call processing and database functionality as described herein (or parts thereof) can be integrated with other parts of the communication network, such as the IM Service Provider facility 26. It is also contemplated that the call processing functionality and/or the database functionality as described herein can be part of other systems or separate systems and joined by messaging technology or other distributed processing technology.
The telecommunication system described herein is advantageous because it allows users to utilizing text-based messages of diverse messaging formats to schedule or initiate a voice call. The text-based messages can refer to short names for participants of the voice call. Such short names are pre-assigned and centrally stored in a contact database. Generating and sending such text-based messages is quick, easy and convenient. Moreover, centralized connection of the participants of the voice call can provide cost benefits to the originator of the voice call.
There have been described and illustrated herein several embodiments of a telecommunication system for initiating voice calls using text-based messages of diverse formats. While particular embodiments of the invention have been described, it is not intended that the invention be limited thereto, as it is intended that the invention be as broad in scope as the art will allow and that the specification be read likewise. It will therefore be appreciated by those skilled in the art that yet other modifications could be made to the provided invention without deviating from its spirit and scope as claimed.