TELEPHONY SYSTEM AND METHOD
FIELD OF INVENTION
The invention relates broadly to a telephony system and method for communicating over a telephonic network. Preferably, the method and system can provide a telephony system and method in which callers use a sequence of characters instead of dialling predefined telephone numbers. In a particular embodiment, the invention relates to a telephony system and method which allows defining of the sequence of characters by end users. The sequence of characters can be associated to a name, an alias; an ID etc. In addition to the traditional telephony environment the invention is also applicable to other telephone communication channels like SMS, USSD, Video calls etc
BACKGROUND
Traditionally each mobile/cellular/fixed line user is provided with a telephone unique number for identification. The numbers are typically defined by the offering operators according to regulatory standards & offered to the end users.
However, the existing system has a number of disadvantages. For example, it is difficulty to remember the numbers and in case of change of number, it is hard to inform everyone. In addition, users have little or no choice in deciding the choice of a number.
Also, in the existing system, a person cannot hold a common identity or username for WEB/internet as well as telephone services, i.e. there is no single global identification for WEB/internet as well as telephone services e.g. a mobile/cellular/fixed line.
Although current telephony system can allow a user to mask his/her mobile number (MSISDN) against a virtual number which can be bought off the shelf (similar to buying a number from a mobile operator), there are a number of drawbacks. Firstly, users cannot select the entire number they like.
For example, if a user wants to mask a number 92929004 to his name Mike (6453), the user can only select few digits in a number as the rest is controlled by the operator/service provider. So the user can only get a masked number e.g. 9292 6453 (MIKE). The masked number has to be the same length and syntax offered by the operator/service provider and therefore they are like virtual number with call forwarding capabilities. There is a thus a need for a telephony system and method which seek to address overcomes the above problems. SUMMARY
According to a first aspect of the invention, there is provided a method of communicating over a telephonic network comprising the steps of: receiving a pre-fix code followed by an character sequence at a service switching point; extracting, at the service switching point, the character sequence triggered by recognizing the pre-fix code; translating the character sequence into a communication address; and contacting the communication address.
The step of receiving may comprise receiving a call by dialing the pre-fix code followed by the character sequence. The extracted character sequence may be translated into a telephone number, and the contacting of the communication address comprises routing the call to the telephone number.
The translating of the character sequence may comprise checking whether a divert instruction associated with the character sequence is active, and translating the character sequence into a divert communication address.
The divert communication address may comprise a divert telephone numbef, a voicemail number, or an IVR personal assistant number.
The step of receiving may comprise receiving a sms using the pre-fix code followed by the character sequence.
The extracted character sequence may be translated into a telephone number, and the contacting of the communication address comprises routing the sms to the telephone number.
The translating of the character sequence may comprise checking whether a divert instruction associated with the character sequence is active, and translating the character sequence into a divert communication address. The divert communication address may comprise an email address, and the contacting comprises sending a content of the SMS to the email address.
The translating of the character sequence may comprise checking whether a block instruction associated with the character sequence is active.
According to a second aspect, there is provided a system of communicating over a telephonic network comprising: means for receiving a pre-fix code followed by an character sequence at a service switching point; means for extracting, at the service switching point, the character sequence triggered by recognizing the pre-fix code; means for translating the character sequence into a communication address; and means for contacting the communication address.
The means for receiving may be adapted for receiving a call by dialing the pre-fix code followed by the character sequence.
The extracted character sequence may be translated into a telephony number by the means for translating, and the means for contacting the communication address routes the call to the telephone number.
The means for translating may check whether a divert instruction associated with the character sequence is active, and the means for translating translates the character sequence into a divert communication address. The divert communication address may comprise a divert telephone number, a voicemail number, or an IVR personal assistant number.
The means for receiving may be adapted for receiving an SMS using the pre-fix code followed by the character sequence.
The extracted character sequence may be translated into a telephony number by the means for translating, and the means for contacting the communication address routes the sms to the telephone number. The means for translating of the character sequence may check whether a divert instruction associated with the character sequence is active, and translates the character sequence into a divert communication address. The divert communication address may comprise an email address, and the contacting comprises sending a content of the sms to the email address. The means for translating of the character sequence may check whether a block instruction associated with the character sequence is active.
According to a third aspect, there is provided a method of managing communication addresses for use with a telephonic network comprising the steps of: providing character sequences; associating each character sequence with at least one communication address; extracting, at a service switching point, a received character sequence triggered by recognizing a pre-fix code; and translating the character sequence into the associated communication address. Providing the character sequences may comprise a subscriber making a request for the character sequence. The request will be made via auction where users will make a bid for a combination of numbers forming a uzername.
The request may be made using SMS, WEB, WAP, IVR, USSD or Video IVR.
The request may be processed to reserve one or more character sequences upon availability, or to auction one or more character sequences.
The method may further comprise processing a check status of one or more character sequences by subscribers.
The method may further comprise processing a transfer of one or more character sequences from one subscriber to another subscriber. The method may further comprise processing a link request by subscribers to link one or more character addresses to an email address.
The method may further comprise processing block or unblock requests to block or unblock all or specific calls or SMSs directed to one or more character sequences.
The method may further comprise processing divert or undivert requests to divert or undivert all or specific calls or SMSs directed to one or more character sequences. A divert communication address may comprise a divert telephone number, a voicemail number, or an IVR personal assistant number. The method may further comprise processing retrieve requests for retrieving voicemail.
According to a fourth aspect, there is provided a system of managing communication addresses for use with a telephonic network comprising: means for providing character sequences; means for associating each character sequence with at least one communication address; means for extracting, at a service switching point, a received character sequence triggered by recognizing a pre-fix code; and means for translating the character sequence into the associated communication address.
The means for providing the character sequences may be adapted for a subscriber making a request for the character sequence.
The request may be made using SMS, WEB, WAP, IVR, USSD or Video IVR.
The request may be processed to reserve one or more character sequences upon availability, or to auction one or more character sequences.
The system may further comprise means for processing a check status of one or more character sequences by subscribers. The system may further comprise means for processing a transfer of one or more character sequences from one subscriber to another subscriber.
The system may further comprise means for processing a link request by subscribers to link one or more character addresses to an email address.
The system may further comprise means for processing block or unblock requests to block or unblock all or specific calls or SMSs directed to one or more character sequences.
The system may further comprise means for processing divert or undivert requests to divert or undivert all or specific calls or SMSs directed to one or more character sequences. A divert communication address may comprise a divert telephone number, a voicemail number, or an IVR personal assistant number.
The system may further comprise processing retrieve requests for retrieving voicemail.
According to a fifth aspect, there is provided a data storage medium having stored thereon computer code means for instructing a computer system to implement a method of communicating over a telephonic network comprising the steps of: receiving a pre-fix code followed by an character sequence at a service switching point; extracting, at the service switching point, the character sequence triggered by recognizing the pre-fix code; translating the character sequence into a communication address; and contacting the communication address.
According to a sixth aspect, there is provided data storage medium having stored thereon computer code means for instructing a computer system to implement a method of managing communication addresses for use with a telephonic network comprising: providing character sequences; associating each character sequence with at least one communication address; extracting, at a service switching point, a received character sequence triggered by recognizing a pre-fix code; and translating the character sequence into the associated communication address.
BRIEF DESCRIPTION OF THE DRAWINGS
Embodiments of the invention will be better-understood and readily apparent to one of. ordinary skill in the art from the following written description, by way of example only, and in conjunction with the drawings, in which:
Figure 1 is a schematic block diagram illustrating the steps involved when a caller dials a username using a system in accordance with an example embodiment;
Figure 2 is a schematic sequence diagram illustrating the communication sequences involved when checking a username availability via SMS using the system of Figure 1 in accordance with an example embodiment;
Figure 3 is a schematic sequence diagram illustrating the communication sequences involved when checking a username availability via WEB using the system of Figure 1 in accordance with an example embodiment; Figure 4 is a schematic sequence diagram illustrating the communication sequences involved when reserving a username via SMS using the system of Figure 1 in accordance with an example embodiment;
Figure 5 is a schematic sequence diagram illustrating the communication sequences involved when participating in a username auction via SMS using the system of Figure 1 in accordance with an example embodiment;
Figure 6 is a schematic sequence diagram illustrating the communication sequences involved when a user checks all the available username auctions via SMS using the system of Figurel in accordance with an example embodiment;
Figure 7 is a schematic sequence diagram illustrating the communication sequences involved when a user checks all the bid price of username auctions via SMS using the system of Figure 1 in accordance with an example embodiment;
Figure 8 is a schematic sequence diagram illustrating the communication sequences involved when participating in a username auction via WAP using the system of Figure 1 in accordance with an example embodiment;
Figure 9 is a schematic sequence diagram illustrating the communication sequences involved when a user checks all the available username auctions via WAP using the system of Figure 1 in accordance with an example embodiment;
Figure 10 is a schematic sequence diagram illustrating the communication sequences involved when participating in a username auction via Video call using the system of Figure 1 in accordance with an example embodiment;
Figure 11 is a schematic sequence diagram illustrating the communication sequences involved when a user wants a list of all his/her usernames via SMS using the system of Figure 1 in accordance with an example embodiment;
Figure 12 is a schematic sequence diagram illustrating the communication sequences involved when a user wants the status of the list of his/her usernames via SMS using the system of Figure 1 in accordance with an example embodiment;
Figure 13 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to set a block on all calls/SMSs of a username via SMS using a system of Figure 1 in accordance with an example embodiment;
Figure 14 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to set a block call/SMS on a specific number via SMS using a system of Figure 1 in accordance with an example embodiment; Figure 15 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to set a divert all calls/SMSs of a username via SMS using a system of Figure 1 in accordance with an example embodiment;
Figure 16 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to set a divert specific calls/SMSs of a username via SMS using a system of Figure 1 in accordance with an example embodiment;
Figure 17 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to set a divert all SMSs of a username to Email via SMS using the system of Figure 1 in accordance with an example embodiment;
Figure 18 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to set a divert all calls of a username to a personal attendant via SMS using the system of Figure 1 in accordance with an example embodiment;
Figure 19 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to retrieve a username voicemail via WEB/WAP using the system of Figure 1 in accordance with an example embodiment;
Figure 20 is a schematic sequence diagram illustrating the communication sequences involved while making a call to a username using the system of Figure 1 in accordance with an example embodiment;
Figure 21 is a schematic sequence diagram illustrating the communication sequences involved while sending SMS to a username using the system of Figure 1 in accordance with an example embodiment;
Figure 22 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to transfer a username via SMS using the system of Figure 1 in accordance with an example embodiment;
Figure 23 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to transfer a username via USSD using the system of Figure 1 in accordance with an example embodiment;
Figure 24 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to link a username to an Email account via SMS using the system of Figure 1 in accordance with an example embodiment;
Figure 25 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to link a username to an Email account via WEB/WAP using the system of Figure 1 in accordance with an example embodiment; and Figure 26 is a schematic diagram illustrating a computer system for implementation of the methods and systems in accordance with an example embodiment. DETAILED DESCRIPTION
Embodiments of the invention provide users a name, nick name, alias or an ID to their mobile/cellular or fixed line numbers.
Embodiments of the present invention provide"a system that works on standard I -based protocols for connecting a call to the system. The system can adapt with the existing system of masking (number translation) an incoming number (MSISDN) to another number defined by users which is not a pre-assigned number. The user number in the system is based on a name, a nickname, an email ID or just another number. Embodiments of the present invention provide system and method of assigning an alias, username, identifier, and an ID to a mobile/cellular/fixed line number issued by a telecom operator or MVNO. The alias can be any name or email address that the user will assign to the regular mobile/cellular/fixed line number as per the following examples: Example 1 - A name assigned by the user to a number
- 65 9929 0307 can be assigned by the user to the name or alias ASIM
- 65 9929 0307 will be masked by the system as ASIM or 2746
It is noted that a combination of number codes that are input from a key pad may stand for different letter combinations, however each combination can be assigned to a user as a code only once. For example, though "2746" can stand for different letter combinations, in case an user has already taken "ASIM" as the alias, no one else can be assigned to the code "2746" alone, even if it was intended as an alias "BRIM" by the other user. The other user must then add one or more alpha numeric elements to the alias, i.e. add one or more elements to the code, e.g. 274672 could be taken as "ASIM72", or add e.g. a surname to the alias "ASIMQURESHI", for code 274678373744".
Example 2 - An email address e.g. from gmail, hotmail etc assigned by the user to a number
- 65 9929 0307 can be assigned by the user to an email ID asim1976 - 65 9929 0307 will be masked by the system as asim1976 or 27461976
Example 3 - A username e.g. from facebook, twitter etc assigned by the user to a number - 65 9929 0307 can be assigned by the user to a username golfer3
- 65 9929 0307 will be masked by the system golfer3 or 4653373
Embodiments of the present invention provide a system and method for facilitating an auction/bidding of aliases, usernames, names and ID's. i.e. the users can bid for aliases, usernames, names and ID's through WEB interfaces, SMS, mobile portals, at the operator sales point.
Embodiments of the present invention provide a system and method for users to block incoming voice calls, video/3G calls, SMS, MMS, VSMS, Push messages from certain numbers.
Embodiments of the present invention provide a system and method for users to divert incoming voice calls, video/3G calls, SMS, MMS, VSMS, Push messages to another username or another MSISDN Embodiments of the present invention provide a system and method for users to divert incoming voice calls, video/3G calls, SMS, MMS, VSMS, Push messages to an email ID.
Embodiments of the present invention provide a system and method of selecting a sequence of e.g. 2 character to 24 character comprising alphabets A to Z, digits, special character, symbols (e.g. provided by phone manufacturers e.g. #* & supported by telecom networks), combinations thereof.
Embodiments of the present invention provide a system and method that allow users to define an alias for their mobile/phone numbers. The alias can be used to receive telephone calls, video calls, SMS, MMS, Short voice messages, short video messages, voice mails and emails. The alias can also be used to define a white list / black list of numbers who can call to the alias. Also, the alias can be used to divert telephone calls, video calls, SMS, MMS, Short voice messages, short video messages to an email account or a personal ' attendant. Furthermore, alias can also be used to divert calls to a voice mail. Embodiments of the present invention to provide a system and method that allow users to define their own alias for a mobile number or telephony number through a bidding process where users can bid for one or multiple aliases. Embodiments of the present invention provide a system and method that can be operated with the existing telecom and internet mediums, such as Short Message Service (SMS), WEB, Wireless Application Protocol (WAP), Unstructured Supplementary Service Data (USSD), Interactive Voice Response (IV ) and Video IVR for offering services such as bidding, buying and registering aliases.
It is noted that in this specification the terms name, alias, ID, email address, username such as for facebook or twitter, etc are used interchangeably, as representing the meaning associated by the user to the sequence of characters assigned to the telephone number. Furthermore, the terms telephone number, MSISDN, etc are also used interchangeably in the specification, as identifying the communication address used in existing telephony systems, mobile, cellular, fixed, etc telephony systems.
Figure 1 is a schematic block diagram illustrating the steps involved when a caller dials a username using a system 100 in accordance with an example embodiment.
At step 101, a caller 110 dials a username, e.g.: *3853. The call lands on the Operator's Service Switching Point (SSP) 120, which recognizes the call as a username call since it starts with an asterisk* (configured based on service definition), in the example embodiment.
At step 03, the SSP sends an InifialDP IN message to the application server 190, which is acting as a SCP (Service Connection Point). The application server 190 requests a username cache 130 to perform a Username-to-telephone number translation at step 107 for example to the MSISDN, often referred to as Mobile Subscriber Integrated Services Digital Network Number. If the username cache 130 does not have the requested information, the information is looked up at step 111 from the database 140. Once the username has been translated, the information is returned back to the application server 190 at step 109. The application server 190 responds to the SSP 120 with a connect message indicating the translated MSISDN at step 113. The SSP 120, based on its regular routing configuration, routes the call to the username subscriber 110 and establishes the call at 118. Now the call between the caller 110 based on the translated MSISDN and the username subscriber 00 is established.
The system 100 further comprises various user interfaces for users to access the application server 190, including in this example embodiment a WEB interface 300, and SMS interface 200, a WAP interface 400, an IVR interface 500 and a USSD gateway 600.
Figure 2 is a schematic sequence diagram illustrating the communication sequences involved when checking a username availability via SMS 200 using the system of Figure 1 in accordance with an example embodiment.
At step 201 , a user 110 sends a short code 220 e.g. CHECK followed by an alphanumeric via SMS 200 to the SMSC. At step 203, the application server 90 checks the availability of the username and replies via SMS 200. If the username is available, the user 110 is notified at step 205 and the user is prompted to reserve the username. If the username is unavailable, at step 207 the user 110 is notified and prompted to try again. If username is listed for auctioning, at step 209 the user is notified and prompted to participate in the auction. Figure 3 is a schematic sequence diagram illustrating the communication sequences involved when checking a username availability via WEB 300 using a system in accordance with an example embodiment.
At step 302, users click on the 'Check Availability' link in a WEB portal 300 and at step 304 enter username/alias they wish to check. The usernames can be digits, letters, or both. At step 301 , the entered username is sent to an application server 190. At step 303, the application server 190 checks the availability of the username and replies via the WEB portal 300. If the username is available, the user 110 is notified at step 305 and the user is prompted to reserve the username. If the username is unavailable, at step 307 the user 110 is notified and prompted to try again. If the username is listed for auctioning, at step 309 the user is notified and prompted to participate in the auction.
It will be appreciated that while user interaction via SMS and WEB have been described above with reference to Figures 2 and 3, the same services can also be implemented using WAP, USSD, IVR, and video IVR. For example, in one embodiment of using video IVR, mobile video interactive avatars may be implemented. The mobile video avatars in such an embodiment are used to run the auctioning of the username/alias, or any or all of the other services described herein. The user will dial into a number using video call (for 3G, 2.5G, 4G, iMode & next generation video networks). The system will accept the call and an avatar will be activated. The avatar will accept user inputs for checking availability and auction via two ways in an example embodiment: 1- Voice instructions
2- Inputs via pressing DTMF keys (keypad)
The mobile video avatar is a computer-controlled animation that responds to user inputs visually and vocally based on logics defined by the system in an example embodiment. Unlike avatars used on the WEB, the mobile video avatars in an embodiment use video channels to carry images and voice SS7 to carry vocals.
The users can have a choice to select a preferred mobile avatar e.g. male or female or popular figures etc, an example embodiment, from an avatar database. The avatar database is coupled to an avatar expression logics and control system, for rendering via the video call connection using a video converter/display, application, and video converter, and can be implemented using e.g. a computer system as described below with reference to Figure 26. Figure 4 is a schematic sequence diagram illustrating the communication sequences involved when reserving a username via SMS 200 using the system of Figure 1 in accordance with an example embodiment.
At step 701 , a user 1 10 sends a short code 220 e.g. RESERVE followed by an username/alias via SMS 200. At step 703, the application server 190 checks the availability of the username and replies via SMS 200. If the username is available, at step 704 a service fee is charged to the charging gateway 710 and at step 705 the user 110 is notified about the confirmation of the reservation and the service charges. If the username is unavailable, at step 707, the user 1 10 is notified and prompted to try again. If username is listed for auctioning, at step 709 the user is notified and prompted to participate in the auction.
It will be appreciated that while SMS has been described above with reference to Figure 4, the same service can also be implemented using WEB, WAP, USSD, IVR, and video IVR.
In the following description, the term BUL = Bid Upper Limit = Current Bid Price for Username x (1 + percentage defined by the operator) is used. For instance, if Current Bid = $100 and Percentage defined by operator = 20%. Therefore, BUL = $100 x (1 + 20%) = $120.
• Figure 5 is a schematic sequence diagram illustrating the communication sequences involved when participating in a username auction via SMS 200 using the system of Figure 1 in accordance with an example embodiment.
At step 1201 , users send a short code 220 e.g. AUCTION followed by the username/alias indicating a wish to participate in the auction via SMS 200. At step 1203, the application server 190 checks the auction status of the username. At step 1205, if the username is not being auctioned, the user is informed via SMS 200. If the username is being auctioned, at step 1207 the user receives an SMS with the current bid price and the BUL, and the user is requested to reply via SMS with the username followed by their bid in order to participate. The user sends a bid price at step 1209 and the application server 190 checks the current bid price at step 1211. If the user sends a bid price lower than the current bid price, at step 1213 the user receives an error SMS accordingly and the user is requested to submit a valid bid. If the user sends a bid price higher than the BUL, at step 1215 the user receives an error SMS accordingly and is requested to submit a valid bid. If the user sends a highest bid at step 1217, an SMS is received confirming that the user currently holds the highest bid. If any user is out-bid at step 1219, an SMS stating the outbid is sent to the user with the current bid price and the BUL and the user also prompted to resubmit a new bid value. Likewise, at step 1221 an SMS is also sent to the outbid user 1200 with the current bid price and the BUL and the outbid user 1200 is prompted to resubmit a new bid value Figure 6 is a schematic sequence diagram illustrating the communication sequences involved when a user checks all the available username auctions via SMS using the system of Figure 1 in accordance with an example embodiment. At any point, as in step 1301 ; users can send a short code 220 e.g. AUCTION LIST via SMS 200. At step 1303, the application server 190 obtains the auction list and at step 1305 a list of the top usernames being auctioned and their current bid price are sent to the user 1 10 via SMS 200. Figure 7 is a schematic sequence diagram illustrating the communication sequences involved when a user checks all the bid price of username auctions via SMS using the system of Figure 1 in accordance with an example embodiment.
At any point, as in step 1401 , users can send a short code 220 e.g. PRICE followed by the username/alias via SMS 200. At step 1403, the application server 190 obtains the current bid price of the username and is sent to the user 1 10 via SMS 200.
Figure 8 is a schematic sequence diagram illustrating the communication sequences involved when participating in a username auction via WAP 400 using the system of Figure 1 in accordance with an example embodiment.
At step 1702, users click on the 'Username Auction' link in a WAP portal 400 and at step 1704 enter username/alias they wish to participate in the auction. At step 1701 , the entered username is sent to an application server ^90. At step 1703, the application server 190 checks the auction status of the entered username. At step 705, if the username is not being auctioned, the user is informed via the WAP 400. If the username is being auctioned, at step 1707 the user is informed of the current bid price, the BUL, and the user is requested to reply via the WAP 400 with the username followed by their bid in order to participate. The user sends a bid price at step 1709. If the user sends a bid price lower than the current bid price, at step 1713 the user is informed via the WAP portal 400 and is requested to submit a valid bid. If the user sends a bid price higher than the BUL, at step 1715 the user receives a message accordingly and is requested to submit a valid bid. If the user sends a highest bid at step 1717, a message is received confirming that the user currently holds the highest bid. If any user is out-bid at step 1719, an SMS stating the outbid is sent to the user with the current bid price and the user is also prompted to resubmit a new bid value. Likewise, at step 1721 an SMS is also sent to the outbid user 1200 with the current bid price and the outbid user 1200 is prompted to resubmit a new bid value.
Figure 9 is a schematic sequence diagram illustrating the communication sequences involved when a user checks all the available username auctions via the WAP portal 400 using the system of Figure 1 in accordance with an example embodiment. At any point, as in step 1801 , users can click on the Top Auctioned Usernames at the WAP portal 400. At step 1803, the application server 190 obtains the status of most popular usernames and the user 110 is informed of the list at step 1805.
Figure 10 is a schematic sequence diagram illustrating the communication sequences involved when participating in a username auction via Video IVR 700 using a system in accordance with an example embodiment
At step 2302, users dial a 3G IVR number 700 and follow the video menu at step 2304; pressing a dual-tone multi-frequency (DTMF) for selecting AUCTION menu at step 2306; and entering usemame/alias (using the numeric key pad) they wish to check at step 2308. At step 2301 , the entered username is sent to an application server 190. At step 2303, the application server 190 checks the auction status of the entered username. At step 2305, if the username is not being auctioned, the user is informed. If the username is being auctioned, at step 2307, the user is informed of the current bid price, the BUL, and the user is informed to reply with the username followed by their bid in order to participate. The user sends a bid price at step 2309. If the user sends a bid price lower than the current bid price, at step 23 3 the user is informed to submit a valid bid. If the user sends a bid price higher than the BUL, at step 2315 the user is notified accordingly and is requested to submit a valid bid. If the user sends a highest bid at step 2317, a confirmation that the user currently holds the highest bid is received. If any user is out-bid at step 2319, an SMS stating the outbid is sent to the user with the current bid price and the user is also prompted to resubmit a new bid value. Likewise, at step 2321 an SMS is also sent to the outbid user 1200 with the current bid price and the outbid user 1200 is prompted to resubmit a new bid value. It is noted that while SMS, WAP, and video IVR have been described above with reference to Figures 5 to 10, the describe services can also be implemented using WEB, WAP, USSD, and IVR. Figure 1 is a schematic sequence diagram illustrating the communication sequences involved when a user wants a list of all his/her usemames via SMS 200 using the system of Figure 1 in accordance with an example embodiment.
At step 2401 , a user 110 sends a short code 220 e.g. MY via SMS 200. At step 2402, the application server 190 checks all usemames that are under that user's account and at step 2405, responds via SMS 200 with a list of all usemames together with a list of all usemames that the user is participating in an auction.
Figure 12 is a schematic sequence diagram illustrating the communication sequences involved when a user wants the status of the list of his/her usemames via SMS using the system of Figure 1 in accordance with an example embodiment.
To check the status of any of the user's usemames, at step 2407, the user 1 0 sends a short code e.g. STATUS followed by the username. At step 2409, the application server 190 checks all active diverts, blocks and transfers of the user together with auction status, if any. At step 2411 the user 110 is informed via SMS with a list of active diverts, blocks and transfers of the user together with auction status, if any.
It is noted that while SMS has been described with reference to Figures 11 and 12, the respective services can also be provided using WEB, WAP, USSD, IVR, and video IVR.
Figure 13 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to set a block on all calls/SMSs of a username via SMS 200 using the system of Figure 1 in accordance with an example embodiment.
At step 2501 , users send the short code 220 e.g. BLOCK ALL via SMS 200. At step 2507, the application server 190 responds via SMS confirming that all voice calls have been blocked together with an indication whether to block all SMSs as well. At step 2509, the user responds with YES via SMS 200. At step 2511 , the application server 190 responds, via SMS 200,. with a confirmation that all SMSs have been blocked. If the user has multiple usemames, at step 2503 the user is prompted to select the username that the user wishes to manage, and upon selecting the username at step 2505, steps 2507 to 2511 are followed accordingly. Figure 14 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to set a block call/SMS on a specific number via SMS 200 using the system of Figure 1 in accordance with an example embodiment.
At step 2701 , users send the short code 220 e.g. BLOCK followed by the number (e.g. MSDISDN) that the user wishes to block via SMS 200. At step 2709, the application server 190 responds via SMS confirming that voice calls have been blocked together with an indication whether to block SMSs as well. At step 2711 , the user responds with YES via SMS 200. At step 2715, the application server 190 responds, via SMS 200, with a confirmation that SMSs have been blocked. If the user has multiple usemames, at step 2703 the user is prompted to select the username that the user wishes to manage, and upon selecting the username at step 2705, steps 2707 to 2711 are followed accordingly.
It is noted that while SMS has been described above with reference to Figures 13 and 14, the respective services can also be provided using WEB, WAP, USSD, IVR, and video IVR. Furthermore, it is noted that corresponding un-blocking services can be provided using any or all of the respective media.
Figure 15 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to set a divert all calls/SMSs of a username via SMS 200 using the system of Figure 1 in accordance with an example embodiment.
At step 2901 , users send the short code 220 e.g. DIVERT ALL followed by the number (i.e. MSDISDN) that the user wishes to divert to via SMS 200. At step 2907, the user receives an SMS notification that the request is now pending confirmation of 'divert-to' party 2910. At step 2909, the application server 190 sends an SMS 200 to the 'divert-to' party 2910 informing him/her of the divert request and prompting to confirm. At step 2911, the 'divert- to' party confirms via SMS with 'YES' to activate divert. At steps 2913 and 2915, the application server 190 respectively informs the users 1 10 and the divert-to party via SMS 200 that all voice calls have been diverted in addition to informing the users 110 on how to undivert and prompting to send YES if all SMSs are to be diverted as well. At step 2917, if the user responds with YES via an SMS, at step 2919 the user is informed via SMS that ail SMSs have been diverted. At step 2921 , the divert-to party is also informed that all SMSs have been diverted. If the user 110 has multiple usernames, at step 2903 the user 110 is prompted to select the username that the user wishes to manage, and upon selecting the username at step 2905, steps 2909 to 2921 are followed accordingly.
Figure 16 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to set a divert specific calls/SMSs of a username via SMS 200 using the system of Figure 1 in accordance with an example embodiment.
At step 3301 , users send the short code 220 e.g. DIVERT Olxxxxxx followed by the number (i.e. MSDISDN) that the user wishes to divert to via SMS 200. At step 3307, the user receives an SMS notification that the request is now pending confirmation of 'divert-to' party 4810. At step 3309, the application server 190 sends an SMS 200 to the 'divert-to' party 4810 informing him/her of the divert request and prompting to confirm. At step 331 , the 'divert-to' party confirms via SMS with 'YES' and divert is activated. At steps 3313 and 3315, the application server 190 respectively informs the users 0 and the divert-to party via SMS 200 that voice calls have been diverted in addition to informing the users 110 on how to undivert and prompting to send YES if SMSs are to be diverted as well. At step 3317, if the user responds with YES via an SMS, at step 3319 the user is informed via SMS that SMSs have been diverted. At step 3321 , the divert-to party is also informed that all SMSs have been diverted. If the user 110 has multiple usernames, at step 3303 the user 110 is prompted to select the username that the user wishes to manage, and upon selecting the username at step 3305, steps 3309 to 3321 are followed accordingly.
.
While SMS has been described above with reference to Figures 5 and 16, the respective services can also be provided by WEB, WAP, USSD, IVR and video IVR. Furthermore, it is noted that corresponding cancel-divert services can be provided using any or all of the media.
Figure 17 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to set a divert all SMSs of a username to Email via SMS 200 using the system of Figure 1 in accordance with an example embodiment. At step 3601 , users send the short code 220 e.g. DIVERT TO EMAIL via SMS 200. At step 3613, the user 110 receives confirmation via SMS that all SMSs have been diverted to an Email. If the user 1 0 has multiple usernames, at step 3603 the user 110 is prompted to select the username that the user wishes to manage, and upon selecting the username at step 3605, step 3613 is followed accordingly.
Figure 18 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to set a divert all calls of a username to a personal attendant via SMS 200 using the system of Figure 1 in accordance with an example embodiment.
At step 3801, users send the short code 220 e.g. DIVERT ALL PA via SMS 200. At step 3813, the user 1 0 receives confirmation via SMS that all calls have been diverted to a personal attendant. If the user 110 has multiple usernames, at step 3803 the user 110 is prompted to select the username that the user wishes to manage, and upon selecting the username at step 3805, step 3813 is followed accordingly.
While SMS has been described above with reference to Figures 17 and 18, it is noted that the respective services can also be provided by WEB, WAP, USSD, IVR and video IVR. Furthermore, corresponding cancel-divert services can be provided using any or all of the media.
Figure 19 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to retrieve a username voicemail via WEB/WAP using a system in accordance with an example embodiment.
At step 4001 , users click on the voicemail menu and at step 4003, a list of available username voicemails for each username account are displayed, together with status (read, new, etc). At step 4005, users click on the play button and at step 4005 the voicemail is played.
It is noted that while WEB WAP have been described above with reference to Figure 19, the service can also be provided by SMS, USSD, IVR and video IVR. Figure 20 is a schematic sequence diagram illustrating the communication sequences involved while making a call to a username using the system of Figure 1 in accordance with an example embodiment. At step 4201 , a party A dials a service prefix (e.g. *, *99*, etc) followed by a username of a party B. At step 4203, the request is received by the application system 190 which checks the availability of the username and corresponding user settings. If the username is not active or not available, a voice prompt is played to the user at step 4205. If the username has a divert setting assigned to it, the call is forwarded to the divert number or service at step 4207. If the username has a block (all or specific) setting assigned to it, the call is forwarded to the correct prompt (not available or blocked prompts) at step 4209. If no block or divert are active, the service looks up the corresponding number and returns to the network the MSISDN that the call should be connected to at step 4211. Figure 21 is a schematic sequence diagram illustrating the communication sequences involved while sending SMS 200 to a username using the system of Figure 1 in accordance with an example embodiment.
At step 4301 , a party A sends an SMS by entering a service prefix (e.g. *, *99*, etc) followed by a username of a party B. At step 4303, the request is received by the application system 190 which checks the availability of the username and corresponding user settings. If the username is not active or not available, a voice prompt is played to the user at step 4305. If the username has a divert setting assigned to it, the call is forwarded to the divert number or service at step 4307. If the username has a block (all or specific) setting assigned to it, the call is forwarded to the correct prompt (not available or blocked prompts) at step 4309. If no block or divert are active, the service looks up the corresponding number and returns to the network the MSISDN that the call should be connected to at step 43 1. Figure 22 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to transfer a username via SMS 200 using the system of Figure 1 in accordance with an example embodiment.
At step 4401, users send the short code 220 e.g. TRANSFER followed by the number (i.e. MSDISDN) that the user wishes to transfer the username to via SMS 200. The request is received at the application server 190 at step 4407. At step 4409, the user receives an SMS notification that the request is now pending confirmation of 'transfer-to' party 4410. At step 44 , the application server 190 sends an SMS 200 to the 'transfer-to' party 4410 informing him/her of the transfer request and prompting to confirm. At step 4413, the 'transfer-to' party confirms via SMS with 'YES' and the transfer is completed. At steps 4413 and 4415, the application server 190 respectively informs the users 110 and the 'transfer-to party via SMS 200 about the transfer. If the user 110 has multiple usernames, at step 4403, the user 110 is prompted to select the username that the user wishes to manage, and upon selecting the username at step 4405, steps 4407 to 4415 are followed accordingly.
Figure 23 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to transfer a username via USSD 600 using the system of Figure 1 in accordance with an example embodiment.
At step 4801 , users 1 0 enter the USSD command 610 that corresponds to TRANFER' in the USSD menu, or follow through the USSD menu and is prompted to enter the MSDISDN of transfer-to party 4410 at step 4810. The user enters the number at step 4812. The request' is received at the application server 190 at step 4807. At step 4809, the user receives an SMS notification that the request is now pending confirmation of!transfer-to' party 4810. At step 4811, the application server 190 sends an SMS 200 to the 'transfer-to' party 4410 informing him/her of the transfer request and prompting to confirm. At step 4813, the 'transfer-to' party confirms via SMS with 'YES' and the transfer is completed. At steps 4813 and 4815, the application server 190 respectively informs the user 110 and the 'transfer-to party via SMS 200 about the transfer. If the user 110 has multiple usernames, at step 4803, the user 110 is prompted to select the username that the user wishes to manage, and upon selecting the username at step 4805, steps 4807 to 4815 are followed accordingly. It is noted that while SMS and USSD have been described above with reference to Figures 22 and 23, the respective services can also be provided by WEB, IVR and video IVR.
Figure 24 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to link a username to an Email account via SMS using the system of Figure 1 in accordance with an example embodiment. At step 4901, users send the short code 220 e.g. LINK followed by an e-mail the user wish to link via SMS 200. At step 4907, the application system send a verification Email to the user and once the user clicks on the verification hyperlink at step 4909, the email is verified and the linkage is completed. If the user 110 has multiple usernames, at step 4903 the user 110 is prompted to select the username that the user wishes to manage, and upon selecting the username at step 4905, steps 4907 and 4909 are followed accordingly.
Figure 25 is a schematic sequence diagram illustrating the communication sequences involved when a user wants to link a username to an Email account via WEB WAP using the system of Figure 1 in accordance with an example embodiment.
At step 5001 , using the WEB WAP portal select LINK and from the menu enter an e-mail the user wish to link via SMS 200. At step 5009, the application system send a verification Email to the user and once the user clicks on the verification hyperlink at step 5011 , the email is verified and the linkage is completed. If the user 10 has multiple usernames, at step 5003 the user 110 is prompted to select the username that the user wishes to manage, and upon selecting the username at step 5005, steps 5009 and 5011 are followed accordingly.
It is noted that while SMS and WEB/WAP have been described above with reference to Figures 24 and 25, the respective services can also be provided by USSD, IVR and video IVR. Figure 26 is a schematic diagram illustrating a computer system for implementation of the systems and methods in accordance with the example embodiments.
The method and system of the example embodiment can be implemented on a computer system 5100, schematically shown in Figure 51. It may be implemented as software, such as a computer program being executed within the computer system 5100, and instructing the computer system 5 00 to conduct the method of the example embodiment. The computer system 5100 comprises a computer module 5102, input modules such as a keyboard 5104 and mouse 5106 and a plurality of output devices such as a display 5108, and printer 5 10. The computer module 5102 is connected to a computer network 5112 via a suitable transceiver device 5114, to enable access to e.g. the Internet or other network systems such as Local Area Network (LAN) or Wide Area Network (WAN).
The computer module 5102 in the example includes a processor 5 8, a Random Access Memory (RAM) 5120 and a Read Only Memory (ROM) 5122. The computer module 5 02 alsp includes a number of Input/Output (I/O) interfaces, for example I/O interface 5 24 to the display 5108, and I/O interface 5126 to the keyboard 5104.
The components of the computer module 5102 typically communicate via and interconnected bus 5128 and in a manner known to the person skilled in the relevant art.
The application program is typically supplied to the user of the computer system 5 00 encoded on a data storage medium such as a CD-ROM or floppy disk and read utilising a corresponding data storage medium drive of a data storage device 5130. The application program is read and controlled in its execution by the processor 5 8. Intermediate storage of program data maybe accomplished using RAM 5 20.
The Personal Attendant (PA) service described above allows VIP username customers who pay a premium monthly fee to access a personalized answering service. The diverted calls are answered and the incoming requests of a caller are logged and sent to the user's username account via email. The user can set specific messages to be communicated to incoming requests via SMS or WEB whenever the caller calls while that call is diverted to the PA service. The PA will see a pop-up on their system with a message that needs to be communicated and will flagged if that message has been communicated before. A history of all incoming calls and interactions are logged and available to both the PAs and the users to review at any time.
A user may be charged e.g. a username reservation fee every four weeks from the date of first purchase. If charging is unsuccessful, the operator charging policy may takes effect. If no charging policy is set by the operator, the service may attempt to reserve two weeks charge only. If successful, the user is notified that two weeks have been charged and that billing for one month will be tried again within two weeks. If unsuccessful, the service will attempt to reserve one week charge only. If successful, the user will be notified that one week has been charged and that billing for one month will be tried again within one week. If charging for one week is also unsuccessful, an SMS is sent to the user informing that charging will be tried again with 72 hours and if it is unsuccessful, the username will be released to public domain and can be reserved by other users. Charging attempts will be made within 72 hours. If successful, the user will be notified accordingly. Otherwise, the username will be released from this user, the user will be notified via SMS and the username will be in public domain.
The example embodiments described can provide the advantage of providing the convenience of usernames, aliases, IDs such as email addresses or facebook IDs to mobile/cellular/fixed line telephony system users.
In an embodiment, there is provided a method of communicating over a telephonic network comprising the steps of: receiving a pre-fix code followed by a character sequence at a service switching point; extracting, at the service switching point, the character sequence triggered by recognizing the pre-fix code; translating the character sequence into a communication address; and contacting the communication address.
In a further embodiment, there is provided a method of managing communication addresses for use with a telephonic network comprising the steps of: providing character sequences; associating each character sequence with at least one communication address; extracting, at a service switching point, a received character sequence triggered - by recognizing a pre-fix code; and translating the character sequence into the associated communication address. It will be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.