WO2010135000A1

WO2010135000A1 - Rapid temporary phone number

Info

Publication number: WO2010135000A1
Application number: PCT/US2010/001508
Authority: WO
Inventors: Behzad Mohebbi
Original assignee: Behzad Mohebbi
Priority date: 2009-05-21
Filing date: 2010-05-21
Publication date: 2010-11-25
Also published as: WO2010135000A9

Abstract

A Rapid Temporary Phone Number system and apparatus operating as part of the cellular network, comprising of at least one application software residing in at least one of the mobile units of the network having a unique initial subscriber number, and a Rapid Temporary Phone Number network unit comprising of at least a Temporary Number Application Server unit, where the said mobile unit application software enables the said mobile unit to acquire at least one new additional subscriber number from the Rapid Temporary Phone Number network on demand and facilitates the subsequent said mobile unit's outgoing calls via the new additional subscriber number, and where Temporary Number Application Server unit: - provides and allocates at least one new subscriber number for the said mobile unit if demanded and, - directs subsequent incoming calls made to the new subscriber number to the said initial subscriber number and, - directs subsequent outgoing calls made by the said mobile unit to the specified number.

Description

RAPID TEMPORARY PHONE NUMBER

Behzad Mohebbi

TECHNICAL FIELD

Most mobile users have a phone number which they use to receive calls from everyone, including friends, family and also use it for business-related calls. Some subscribers may even have two or more handsets with two different phone numbers, or two or more SIM or USIM cards (if their network is based on GSM or GSM derivatives or WCDMA systems), in order to separate business calls from social calls. There is also the recently introduced "Google voice", where a user can register with a Google application server, provide a number of contact phone numbers for home landline, cellular mobile and others, in exchange for a unified phone number. All these schemes have to be planned in advance and require considerable effort to set up. They are also a permanent or semi- permanent arrangement, where changing the arrangement also requires considerable effort. More and more subscribers are using their cell phones for applications such as social networking that require increased levels of data and voice interaction with other users that they may or may not know well, or perhaps want to keep in contact with for only a limited time. Also, a security-conscious person may not want to use a personal phone number for temporary situations where a phone number is needed for only a short time. There are situations that may arise unexpectedly, where a rapid temporary phone number (MSISDN) is required, which is neither possible to acquire with a slow permanent or semi-permanent arrangement, nor desirable as even a semipermanent arrangement cannot be changed regularly. For example, after a car accident, or during a business transaction, one may require a second temporary phone number rapidly (on-the-fly), valid only for the duration required by the event. Such service currently does not exist.

BACKGROUND ART

The novel invention disclosed here provides a cost-effective method for providing a "Rapid Temporary Phone Number", where the number can be kept as long as the subscriber requires. The capability of being able to download and execute application software within Smartphones, such as Google "G1" or Apple "iPhone", enables the inclusion of new applications and services with such phones, such as the invention for the "Rapid Temporary Phone Number" disclosed here. For the purposes of describing the novel idea here, WCDMA cellular network is used as the example cellular network. However, it is understood that with the appropriate modifications, the same invention can be used in other networks such as cdma2000, GSM, LTE and WiMax. It is also possible to use shorter range wireless networks such as WiFi or BlueTooth, with a Smartphone or device that can support them to support the patent described here.

For the purposes of describing the novel idea here, Google G1 is used as the example Smartphone. However, it is understood that with the appropriate modifications, the invention can be used with any Smartphone or any other "computing device" that has processing capability with the ability to communicate with a wireless network.

For the purposes of describing the novel idea here, Short Message Service (SMS) is used as the example bearer service. However, it is understood that, with the appropriate modifications, any circuit or packet switched bearer services such as voice or data, or long-SMS, MMS or EMS can be used instead of or as well as SMS.

SUMMARY

A Rapid Temporary Phone Number system and apparatus operating as part of the cellular network, comprising of at least one application software residing in at least one of the mobile units of the network having a unique initial subscriber number, and a Rapid Temporary Phone Number network unit comprising of at least a Temporary Number Application Server unit, where the said mobile unit application software enables the said mobile unit to acquire at least one new additional subscriber number from the Rapid Temporary Phone Number network on demand and facilitates the subsequent said mobile unit's outgoing calls via the new additional subscriber number, and where Temporary Number Application Server unit: - provides and allocates at least one new subscriber number for the said mobile unit if demanded and,

- directs subsequent incoming calls made to the new subscriber number to the said initial subscriber number and,

- directs subsequent outgoing calls made by the said mobile unit to the specified number. BRIEF DESCRIPTION OF DRAWINGS

Embodiments of the invention relating to both structure and method of operation, may best be understood by referring to the following description and accompanying drawings whereby:

Figure 1 represents an example of WCDMA (or UMTS) example network block diagram;

Figure 2 represents an example of Computing Device (e.g. G1 Smartphone);

Figure 3 represents an example of "PLMN-Based" Rapid Temporary Number system block diagram; Figure 4 represents an example of "TNAP Main" program flowchart;

Figure 5 represents an example of "Account Setup" program flowchart;

Figure 6 represents an example of "Request TN" program flowchart;

Figure 7 represents an example of "Relinquish TN" program flowchart;

Figure 8 represents an example of "TNAS Main" program flowchart; Figure 9 represents an example of "Grant Account" program flowchart;

Figure 10 represents an example of "Grant TN" program flowchart;

Figure 11 represents an example of "Release TN" program flow chart;

Figure 12 represents an example of Example field allocation for TNAP SMS request messages; Figure 13 represents an example of Example field allocation for TNAS SMS response messages;

Figure 14 represents an example of "Temporary Number Connection Center" (TNCC);

Figure 15 represents an example of "TNCC Telephony" program flowchart;

Figure 16 represents an example of "Temporary Number Connection Center" (TNCC) with no PLMN connection;

Figure 17 represents an example of "TNCC Telephony" program flowchart with "call transfer";

Figure 18 represents an example of "TNAP outgoing telephony" program flowchart;

Figure 19 represents an example of "Stand-alone" Rapid Temporary Number system block diagram.

DESCRIPTION OF EMBODIMENTS

Figure 1 shows an example block diagram of a WCDMA (or UMTS) network, with some blocks such as "Billing server", EIR and OMC not shown. In this example, the User

Equipment (UE) is shown as a Google G1 Smartphone and hereafter is referred to as "UE" or "computing device". All network elements and interfaces are known to a person sufficiently skilled in the art.

Computing device shown in Figure 2 is intended to represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smart phones, and other similar computing devices. The components shown here, their relationships and their functions, are meant to be exemplary only, and are not meant to limit implementations of the inventions described and/or claimed in this document. The computing device shown in Figure 2 can also be used as representative of Google G1 Smartphone. Figure 2 does not show all the components of a Google Smartphone G1 , but does show the units in a Smartphone G1 that are relevant to the novel idea disclosed here. Figure 2 does not show the internal connections of the units or interfaces or input/output ports or antennas of the G1 Smartphone.

Computing device shown in Figure 2 includes a processor unit, memory unit, a display unit, a communication interface labeled "control unit", a WCDMA, a GPS, a Bluetooth and a WiFi unit, among other components. The Computing device shown in Figure 2 may also be provided with a storage device, such as a microdrive or other device, to provide additional storage. All of the shown units in Figure 2 are interconnected using various buses, and several of the components may be mounted on a common motherboard or in other manners as appropriate. The processor unit can execute instructions within the computing device, including instructions stored in the memory unit. The processor unit may be implemented as a chipset of chips to include separate and multiple analog and digital processors. The processor unit may provide, for example, for coordination of the other components of the computing device, such as control of user interfaces, applications run by computing device, and wireless communication by the computing device. Processor unit may communicate with a user through control unit and display unit. The display unit may be, for example, a TFT LCD (Thin-Film-Transistor Liquid Crystal Display) display or an OLED (Organic Light Emitting Diode) display, or other appropriate display technology. The display unit may comprise appropriate circuitry for driving the display to present graphical and other information to a user. The control unit may receive commands from a user and convert them for submission to the processor unit. In addition, an external interface (not shown) may be provided for communication with processor unit, so as to enable near area communication of the computing device with other devices. The external interface may provide, for example, for wired communication in some implementations, or for wireless communication in other implementations, and multiple interfaces may also be used. The memory unit stores information within the computing device. The memory unit can be implemented as one or more of a computer- readable medium or media, a volatile memory unit or units, or a nonvolatile memory unit or units. Expansion memory (not shown) may also be provided and connected to the computing device through an expansion interface (not shown), which may include, for example, a SIMM (Single In Line Memory Module) card interface. Such expansion memory unit may provide extra storage space for the computing device, or may also store applications or other information for the computing device. Specifically, expansion memory unit may include instructions to carry out or supplement the processes described above, and may include secure information also. Thus, for example, expansion memory unit may be provided as a security module for the computing device, and may be programmed with instructions that permit secure use of the computing device. In addition, secure applications may be provided via the SIMM cards or over-the-air via one of the wireless interfaces such WCDMA unit, (along with additional information such as placing identifying information on the SIMM card) in a non-hackable manner. The memory unit may include, for example, flash memory and/or NVRAM memory, as discussed below. In one implementation, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer- or machine-readable medium, such as the memory unit, expansion memory unit, memory on processor unit, or a propagated signal that may be received, for example, over WCDMA unit or WiFi or BlueTooth units or external interface. Computing device may communicate wirelessly through communication interfaces such as WCDMA, WiFi or BlueTooth, which may include digital signal processing circuitry where necessary. Communication interface units may provide for communications under various modes or protocols, such as GSM voice calls, SMS, EMS, or MMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, GPRS, WiMax or LTE among others, although the example is based on WCDMA (UMTS). Such communication may occur, for example, through WCDMA unit. In addition, short-range communication may occur, such as using a Bluetooth, WiFi, or other such transceiver (not shown). In addition, GPS (Global Positioning System) unit may provide additional navigation- and location-related wireless data to computing device, which may be used as appropriate by applications running on device in the background or foreground. Computing device may also communicate audibly using audio codec unit (not shown), which may receive spoken information from a user and convert it to usable digital information. Audio codec unit may likewise generate audible sound for a user, such as through a speaker, e.g., in a handset of device 950. Such sound may include sound from voice telephone calls, may include recorded sound (e.g., voice messages, music files, etc.) and may also include sound generated by applications operating on the computing device. The computing device has an accelerometer unit that is used by the processor unit to find out the orientation and dynamic handling of the computing device. The computing device may be implemented in a number of different forms, as shown in the figure 2. For example, it may be implemented as a cellular telephone. It may also be implemented as part of a Smartphone, personal digital assistant, or other similar mobile device.

There are at least two approaches to realize the novel idea disclosed here, I)

"PLMN-based" method and II) "stand-alone" method. In the "PLMN-based" method, the new network elements are embedded within the cellular operator's Private Land Mobile Network (PLMN), and the service is operated and maintained by the operator itself. In the "stand-alone" method, the solution is outside an operator's network (PLMN) and is possibly operated and maintained by a third party. While the stand-alone approach has the advantage of being able to serve many PLMNs at the same time, PLMN-based method is faster and more secure.

PLMN-based method A block diagram example of the "PLMN-based" method is shown in Figure 3. It must be noted that Figure 3 is one example in which the novel idea can be realized. There may be other network permutations that can also support the disclosed invention here. For most part, Figure 3 is a simplified version of the network shown in Figure 1, with only the logical network connections shown in this figure. In the "PLMN-based" model, a new application server called "Temporary Number Application Server" (TNAS) is connected to SMSC. TNAS is also connected to two databases and storage units called "Temporary Number DataBase" unit (TNDB) and "Number Pool DataBase" unit (NPDB). TNDB and NPDB can be integrated into one database, if desired. The TNDB unit is also connected to another unit which is called "Temporary Number Connection Centre" (TNCC), which in turn is connected to PSTN/ISDN public telephony network and Public Data Network (PDN/IP) and optionally (depending on the design options) connected to GGSN, MSC. TNCC unit, with some modifications, can alternatively be connected to SGSN, instead of GGSN. TNCC unit is preferably also connected to NPDB unit, although strictly not required. The SMSC, TNAS, TNDB, NPDB and TNCC are all parts of the same PLMN. In Figure 3, UE is a G1 Smartphone from Google which now has additional new application software, called "Temporary Number Application Program" (TNAP) stored in its memory unit. TNAP can be downloaded into UE via the WCDMA unit (i.e. over the air), or from the web (e.g. the operators or any other website), via wireline or wireless internet, or by proximity to a server device via the Bluetooth unit. It can alternatively be placed in the UE memory unit at the operators' shop or at the time of manufacture by the manufacturer or in an expansion memory unit inserted later.

TNAS is made up of at least four SW blocks, called "TNAS Main" program, "Grant Account" program, "Grant TN" program and "Release TN" program. TNAS is responsible for, and performs, amongst other things, the following tasks:

1) Communication with TNAP, through PLMN or PSDN/ISDN or PDN/IP network elements, to enable: a) Setup of accounts and assignment of Personal IDentification number (PID). PID is an identification code, with fixed or variable length, agreed with a subscriber, which can be made up of a number of preferably numeric (or alphabetic and other) characters (say minimum 5 and maximum 10 characters, or fixed at 5 characters). PID has to be provided by "the caller" to be connected to a subscriber, and for network to be able to route the call to the subscriber. Therefore both PID and Temporary Number (TN) have to be given as part of the "subscriber number" to "callers", for them to be able to reach a subscriber. PID can be treated as a dedicated extension for the subscriber, while TN can be treated as the main calling Subscriber Number (SN). TN can be a PSTN or ISDN subscriber numbers or serving PLMN MSISDN number.

b) Allocation (and reallocation) of temporary number (TN). A temporary number (TN) is a phone number (SN) which is assigned to a subscriber temporarily, as long as the subscriber needs it, after which the temporary number (TN) can be reused and assigned to other candidate subscribers. TN has to be dialed by "the caller" to be connected to a subscriber, and for network to be able to route the call to the subscriber. Therefore both TN and PID have to be given as part of the "subscriber number" to "callers", for them to be able to reach a subscriber. TN can be treated as the main calling number (SN), while PID as the extension number of the subscriber.

c) Relinquishing (releasing) of TN back to network. 2) Updating and maintenance of TNDB and NPDB databases. Temporary Number DataBase (TNDB) holds active subscriber phone numbers (MSISDN), together with their associated PID and TN. TNDB is also responsible for billing the subscribers for use of "Rapid Temporary Number Services". Number Pool DataBase (NPDB) holds all the temporary numbers (TN), which can be PSTN or ISDN subscriber numbers or serving PLMN MSISDN numbers, and together with their associated "PID History" list. "PID History" list is a list of all assigned PIDs to a given TN, over a finite time (say the last two years), together with the time of their last release.

TNAP is made up of at least five SW blocks, called "TNAP Main" program,

"Account Setup" program, "Request TN" program, "Relinquish TN" program and "TNAP outgoing telephony" program. TNAP is responsible for, and performs, amongst other things, the following tasks:

1) Communication with TNAS, through PLMN or PSDN/ISDN or PDN/IP network elements, to enable: a) Setting up of accounts and negotiating Personal IDentity number (PID) with TNAS. b) Requesting of temporary number (TN). c) Relinquishing (releasing) of TN back to network.

2) Communication with TNCC and facilitation of the outgoing calls.

3) User interface and storage of data.

TNCC is made up of at least one SW block, called ""TNCC telephony" program.

TNCC is responsible for, and performs, amongst other things, the following tasks:

1) Communicate with PSTN/ISDN public network, preferably using SS7 or R1 protocols, and facilitate: a) Accepting the incoming calls. b) Initiating the outgoing calls. c) Initiating PSTN/ISDN network signaling for activating such features as "call transfer" and "call forwarding". d) Switching and connecting calls between PSTN/ISDN and PLMN and between PDN/IP and PLMN and between PSTN/ISDN and PDN/IP. 2) Optionally communicate with PLMN (preferably using SS7) and facilitate: a) Accepting the incoming calls. b) Initiating the outgoing calls. c) Initiating PLMN network signaling for activating such features as connecting a voice call to a MSISDN through MSC or data call through GGSN. d) Switching and connecting calls between PSTN/ISDN and PLMN and between PDN/IP and PLMN and between PSTN/ISDN and PDN/IP

3) Communicate with PDN/IP (optional) and facilitate: a) Accepting the incoming data sessions and messages such as emails. b) Initiating the outgoing data sessions such as forwarding emails. c) Initiating PDN/IP network signaling for activating such features as sending IP packets and connecting to other IP switches and routers. d) Switching and connecting calls between PSTN/ISDN and PLMN and between PDN/IP and PLMN and between PSTN/ISDN and PDN/IP

4) Communicate with TNDB and PNDB databases.

Now, by way of an example and use of flowcharts, the operation of TNAP of the Rapid Temporary Number System is explained. It is understood that the flowcharts and system operations are exemplary and can be modified and changed within the scope of the invention.

On subscriber (hereafter, by "subscriber" it is meant a cellular subscriber who is also subscribing, or is about to subscribe to "Rapid Temporary Number Services") execution of "TNAP Main" program (Figure 4), the subscriber is asked for the Subscriber Number (SN) (102). Subscriber Number (SN) is the phone number used to contact a user, also known as Mobile Subscriber ISDN (MSISDN) number. After SN entry, this number is read and stored (103). Although, as shown in Figure 4, every time "TNAP Main" program (100) is executed, the subscriber is required to enter its SN, it is possible to ask for SN once, the first time that "TNAP Main" program (100) is executed. After which, SN can be stored on a non-volatile memory and is retrieved by the program (100) automatically, and shown to subscriber for confirmation. It is also possible to retrieve MSISDN (SN) from USIM automatically, eliminating the need for (102).

The subscriber is then given at least three choices (104), 1) "Account Setup", 2)

"Request Temporary Number (TN)" and 3) "Relinquish Temporary Number (TN)". A further option can also be added, requesting for a temporary email account (not shown in the Figure 4).

If subscriber selects "Account Setup" option (105), "TNAP Main" program will enter the "Account setup" branch (106) and executes "Account Setup" program (107). On the successful execution of "Account Setup" program, TNAP stores the assigned Personal IDentity number (PID) (108) and stops (112).

If subscriber selects "Request Temporary Number (TN)" option (105), "TNAP Main" program will enter the "Request TN" branch (106) and execute "Request TN" program (109). On the successful execution of "Request TN" program, TNAP stores the assigned Temporary Number (TN) (110) and stops (112)

If subscriber selects "Relinquish TN" (105), "TNAP Main" program will enter the "Relinquish TN" branch (106) and execute "Relinquish TN" program (111) and stop (112).

Note that setting up an account (i.e. execution of "Account Setup" program (107)) is not strictly required for requesting a temporary number (TN). A temporary number can be requested at any time, after the installation of TNAP and execution of "TNAP Main" with "Request TN" option with or without an account already in existence. The execution of "Account Setup" program merely speeds up the process of getting a temporary number (TN), when needed, as the personal ID number (PID) has to be confirmed, and may require one or more iterations before an acceptable PID is agreed upon, by the subscriber and TNAS unit. This is also true if a temporary email account is to be requested, as a non-contentious email identity can require a few iterations to converge on.

Figure 5 shows the "Account Setup" program flowchart. On entry into "Account Setup" program (201), the subscriber is asked to enter a "preferred ID" number (202), which can be used to refer to the subscriber in database TNDB unit (It has to be mentioned that this "preferred ID" is not strictly required as the subscriber phone number can be used as a unique ID in the network. However, for reason that is discussed later, this ID enables an unambiguous identification of the recipient of a call). After the successful entry of the "Preferred ID" (203) and storage on a non-volatile memory or disk, "Account Setup" program sends a SMS message to TNAS, introducing the subscriber by UE phone number (MSISDN) (or other USIM numbers, such IMSI, which is also known to TNAS can be used), and presents the "Preferred ID" for approval (204). A timer (t) is set to timeout the waiting for the TNAS acknowledgement (205). TNAS will estimate the ratio of the granted "Preferred ID" to the total number of phone numbers (TNs) available in the number pool, stored on NPDB. If the ratio is below an acceptable level, the "Preferred ID" is accepted. Otherwise "Preferred ID" is rejected by TNAS. In either of the cases, an acknowledgment message (ACK) is sent by TNAS to "Account Setup" program. If timer (t) expires without an ACK from TNAS (207), "Account Setup" program reports an appropriate "Error message", informing the subscriber of unsuccessful termination of the process (208), before stopping (212). If timer (t) expires without an ACK from TNAS, it is also possible to send a number of SMS messages to TNAS before reporting an appropriate "Error message", informing the subscriber of unsuccessful termination of the process (208), and stopping (212).

However, if an ACK is received while timer (t) is still valid (206), the status of "Preferred ID" is examined (209), and if accepted and granted by TNAS, the acceptance of "Preferred ID" is reported to the subscriber (211), before stopping (212). After the acceptance of "Preferred ID", "Preferred ID" number is tagged as "Personal ID" number

(PID) in the non-volatile memory or disk (not shown in Figure 5). If "Preferred ID" is not accepted by TNAS, the subscriber is informed (210), and a new "Preferred ID" is requested (202). It is also possible that TNAS recommends to subscriber a variation of the original "Preferred ID", which is acceptable to TNAS, for consideration (not shown in

Figure 5).

Note that the above process shown in Figure 5 can be repeated (or performed) as well (or instead) of the temporary phone number ID selection, for an email ID selection and setup (not shown in Figure 5).

Figure 6 shows the "Request TN" program flowchart. On entry into "Request TN" program (301), program looks in the UE memory or disk for an existing PID (302). If no PID exists, "Request TN" asks the subscriber to enter a "preferred ID" (303), which can be used to refer to the subscriber in database TNDB unit (It has to be mentioned that this "preferred ID" is not strictly required as the subscriber phone number (MSISDN) can be used as a unique ID in the network. However, for reason that is discussed later, this ID enables an unambiguous identification of the recipient of a call). After the successful entry of the "Preferred ID" (304), "Request TN" program sends a SMS message to TNAS, requesting a Temporary Number (TN), introducing the subscriber by the UE phone number (MSISDN) (or other USIM numbers, such IMSI, which is also known to TNAS can be used), and presents the "Preferred ID" number for approval (305). A timer (t) is set to timeout the waiting for the TNAS response (306). TNAS will estimate the ratio of the granted "Preferred ID" to the total number of phone numbers (TNs) available in the number pool, stored on NPDB. If the ratio is below an acceptable level, the "Preferred ID" number is accepted. Otherwise "Preferred ID" number is rejected by TNAS. In either of the cases, a "TN response" message is sent by TNAS to "Request TN" program. If timer (t) expires without a "TN response" message from TNAS (308), "Request TN" program reports an appropriate "Error message", informing the subscriber of unsuccessful termination of the process (309), before stopping (314). If timer (t) expires without a "TN response" from TNAS, it is also possible to send a number of SMS messages to TNAS before reporting an appropriate "Error message", informing the subscriber of unsuccessful termination of the process (309), and stopping (314).

However, if a "TN response" is received while timer (t) is still valid (307), the status of "Preferred ID" is examined (310), and if accepted and granted by TNAS, "Preferred ID" number is turned into PID (Personal ID number) and is stored along with TN (312) in non-volatile memory or disk, before reporting to the subscriber (313), and stopping (314). If "Preferred ID" is not accepted by TNAS, the subscriber is informed (311), and a new "Preferred ID" number is requested (303). It is also possible that TNAS recommends to subscriber a variation of the original "Preferred ID", which is acceptable to TNAS, for consideration (not shown in Figure 6).

If there is a PID already in existence in the UE memory or disk (302), then the "Request TN" program will send a "Request TN" SMS message to TNAS, that includes the subscriber PID (315). A timer (t) is set to timeout the waiting for the TNAS response

(316). TNAS will allocate an appropriate TN (temporary number) to the PID and sends a

SMS response back to "TN response" program, with TN included. If timer (t) expires without a "TN response" message from TNAS (318), "Request TN" program reports an appropriate "Error message", informing the subscriber of unsuccessful termination of the process (319), before stopping (322). If timer (t) expires without a "TN response" from

TNAS, it is also possible to send a number of SMS messages to TNAS before reporting an appropriate "Error message", informing the subscriber of unsuccessful termination of the process (319), and stopping (322). However, if a "TN response" is received while timer (t) is still valid (317), PID (Personal ID number) along with TN (Temporary number) is stored in non-volatile memory or disk in UE (320), before reporting them to the subscriber (321), and stopping (322).

So far the example has shown the setting up of a single PID for requesting TN. However, it is understood that with minor modifications it is possible to change the program to accept one or more PIDs (or email IDs) for the same subscriber.

Note that the above process shown in Figure 6 can be repeated (or performed) as well as (or instead of) the temporary phone number ID selection, for an email ID selection and request (not shown in Figure 6).

Figure 7 shows the "Relinquish TN" program flowchart. On entry into "Relinquish TN" program (351), program looks for an existing TN in UE memory or on UE disk (352). If no TN exists, "Relinquish TN" displays the appropriate error message (358) and stops (360).

If a TN already exists (352), "Relinquish TN" program (350) send a 'relinquish TN" SMS message to TNAS, including TN and PID in the message (354). A timer (t) is set to timeout the waiting for the TNAS acknowledgement (355). On successful release

(relinquish) operation, an acknowledgment message (ACK) is sent by TNAS to

"Relinquish TN" program (350). If timer (t) expires without an ACK from TNAS (357),

Relinquish TN" program (350) reports an appropriate "Error message", informing the subscriber of unsuccessful termination of the process (358), before stopping (360). If timer (t) expires without an ACK from TNAS, it is also possible to send a number of SMS messages to TNAS before reporting an appropriate "Error message", informing the subscriber of unsuccessful termination of the process (358), and stopping (360).

However, if an ACK is received while timer (t) is still valid (356), the subscriber is informed of the confirmation (359) and program stops (360).

Now, by way of an example and use of flowcharts, the operation of TNAS of the Rapid Temporary Number system is explained. It is understood that the flowcharts and system operations are exemplary and can be modified and changed within the scope of the invention. On execution of "TNAS Main" program (Figure 8), the program waits for SMS messages from all subscribers, to arrive via PLMN elements, (402). On receipt of a SMS message, say subscriber X, the subscriber phone number (MSISDN) (or other USIM numbers, such IMSI, which is also known to TNAS can be used) is extracted from the message and stored (403). It is assumed that the SMS message forwarded to TNAS is from the subscriber belonging to the serving PLMN, and it has been authenticated before. Alternatively, TNAS can authenticate that the received SMS message is from a subscriber served by the operating PLMN (the PLMN TNAS belongs to and resides in). The message is then examined to establish the type of message; to identify it from "account setup" message or "Request TN" message or "Relinquish TN" message (404). If it is an "account setup" message, the program extracts and stores subscriber X "preferred ID" selection (405), after which it executes the "Grant Account" program (406). After the successful execution of "Grant Account" program, "TNAS Main" program (400) examines to see whether the "Grant Account" program has accepted the "preferred ID" or not (407). If the "preferred ID" is not accepted, "TNAS Main" program (400) sends an ACK message to subscriber X TNAP, declining the selected "preferred ID" (408). If the "preferred ID" is accepted, "TNAS Main" program (400) sends an ACK message to subscriber X TNAP, confirming the acceptance of the selected "preferred ID", which is now treated as a PID (409). The program then waits for new SMS messages (402).

On the other hand, if the received SMS message is "Request TN" message, the program extracts and stores subscriber X "preferred ID" selection, or the PID, if available (410). If PID is not available, and a "preferred ID" selection is received (411), the "TNAS Main" program (400) executes the "Grant Account" program (412). After the successful execution of "Grant Account" program, "TNAS Main" program (400) examines to see whether the "Grant Account" program has accepted the "preferred ID" or not (413). If the "preferred ID" is not accepted, "TNAS Main" program (400) sends an ACK message to subscriber X TNAP, declining the selected "preferred ID" (414). If the "preferred ID" is accepted, "TNAS Main" program (400) executes "Grant TN" program (415). After the successful execution of "Grant TN" program, "TNAS Main" program (400) send an SMS "TN response" message to subscriber X, including TN and PID in the message (416), and then returns to waiting for SMS messages (402).

If the SMS message is a "relinquish TN" message, the program extracts and stores subscriber X temporary number TN (sent with the message) and PID (417), after which it executes the "release TN" program (418). After the successful execution of "release TN" program, "TNAS Main" program (400) sends an ACK message to subscriber X TNAP, confirming the release of the TN (409), and then returns to (402), waiting for SMS messages.

Although only a single instantiation of "TNAS Main" program (400) is shown (running) above, it is understood that several instantiations of "TNAS Main" program (400) can be executed at the same time on TNAS, to deal with larger numbers of arriving SMS messages. It is also possible to introduce a SMS message buffer (not shown in Figure 8), where the incoming SMS messages are queued for processing by "TNAS Main" program (400). In such a case, care has to be taken that the queue length (and total latency) does not exceed the timeout (t) duration in TNAP programs.

Figure 9 shows the "Grant Account" program flowchart. On entry (501) the program reads the subscriber X phone number (MSISDN) and "preferred ID" number

(502), which was saved by "TNAS Main" program (400). The program then looks for identical PIDs in TNDB unit; counting and recording the number of entries into a register

(say SID register) (503). The "Grant Account" program (500) then counts and stores the total number of available "temporary numbers" (TNs) in the database pool NPDB, in register (say TNTN register) (504). The ratio of SID to TNTN is then calculated and stored in another register (say R register) (505), and if this ratio (R) is greater than a desirable threshold (say Rth = 0.25) (506), the program rejects the selected "preferred ID" number

(509). If R is smaller than Rth , then the "Grant Account" program (500) accepts and stores the "preferred ID" number, which is now treated as PID (507). "Grant Account" program (500) also registers the subscriber X phone number (MSISDN), along with the associated PID (508), on TNDB database, before stopping (510).

Figure 10 shows the "Grant TN" program flowchart. On entry (601) the program reads the subscriber X phone number (MSISDN) and PID number (602). Then "Grant TN" program (600) proceeds to assign an "unassigned" and suitable temporary number (TN) from the number pool on NPDB (603), and mark (label) it as "Assigned" on NPDB. The temporary number (TN) is selected such that, the TN has never been allocated to subscriber with the same PID number, as indicated in the "PID History" list on NPDB. The "PID History" may have to be practically limited to a finite time (Z), say of 24 months. If a TN is selected that had been assigned to another subscriber with the same PID number in the past, it is possible that some of calls to the previous subscriber are routed to the new one by mistake. By using a TN which has not been used with the same PID number, the chance of an incorrect routing of calls is eliminated. "Grant TN" program (600) registers the subscriber X phone number (MSISDN), along with the associated temporary number (TN) and subscriber PID number (604), on TNDB database, before stopping (605).

Figure 11 shows the "Release TN" program flowchart. On entry (701) the program reads the subscriber X phone number (MSISDN), TN and PID numbers (702). Then "Release TN" program (700) proceeds to mark (label) the released TN as "un-assigned" in NPDB (703), and updates the "PID History" with the subscriber X associated PID number and time (and date) of the release (704). "Release TN" program (700) un- registers the subscriber X phone number (MSISDN), along with the associated PID and TN numbers on TNDB database, before stopping (706).

In the above "Release TN" program (700) example, a single TN was assumed both at TNAP and TNAS. However, with appropriate modifications of "Release TN" program (700) it is also possible to handle scenarios where several assigned TNs exists at both TNAP and TNAS for the same subscriber.

Notes:

1- A subscriber can hold on to a temporary number (TN), as long as needed. When the subscriber no longer needs the temporary number, the assigned TN can be relinquished back to the network and the number pool database (NPDB), where it can be reassigned to other subscribers (or the same subscriber later). Other arrangements for release of the temporary number

(TN) are also possible. For example an automatic release of a TN₁ if not used for a given length of time (say three month), with or without prior notification(s).

2- A list of all the PID numbers used with a particular TN, along with their time of last release, is kept on NPDB in the "PID History" list, so that a TN is not assigned twice to the same PID number (even though the subscribers may be different), as this causes confusion by routing calls intended for the previous PIDs to the new PID. It is however possible to assign the same PID number and the same TN to the same subscriber, to restore a previous assignment, if the original TN is available. 3- A newly relinquished TN can be kept unused for a while (say two weeks), in case the last subscriber changes mind and requires the same number again, such that they can receive calls on it again, with the same PID number.

4- In the above example, a PID number is used to reduce the chance of misrouting calls in the system. It is also possible to assign a TN to a subscriber without the use of a PID. However, as the temporary numbers (TN) are reused, if there is no PID associated with a TN, the incoming calls intended for previous subscribers using the same TN will inevitably end up routed to the subscriber with the newly assigned TN. Clearly this is not desirable.

5- An interested subscriber should be able to retrieve and acquire an old TN with the original associated PID number, as long as the TN had not been assigned to anyone else at the time.

6- It is possible to assign the same TN to several subscribers with different PID numbers at the same time. However, the TN can only be used by one assigned subscriber at a given time.

7- The example above shows a single PID number assignment to a subscriber. However, with appropriate modifications, a subscriber can register with TNAS with several PID numbers.

A SMS message has a header which is used for message delivery and 140 bytes of payload. While this payload is sufficient for the examples used here, if higher payloads are required, "Long" or "concatenated" SMS message can be used. Figures 4 and 5 show examples of the required fields for TNAP and TNAS request and response messages discussed in the example description above.

With reference to Figure 12, in the TNAP SMS message payload, the first filed labeled "phone number" is 15 bytes of the 140-byte payload and is used for sending the subscriber phone number (MSISDN) to TNAS. This can either be entered once, for example as discussed, at the beginning of "TNAP Main" program (shown in Figure 4) manually, or it can be retrieved from UE's USIM card (or network) automatically (not shown). This number may also be retrieved from the SMS transport protocols and messages send from serving MSMC. The next 5 bytes are reserved to define the message type which can at least be: "account setup", "request TN" or "relinquish TN" message types. "PID/Pref. ID" field which is 10 bytes is used to send either the "preferred ID" (before PID grant), or send the PID number to TNAS. The following field "PID/Pref. ID indicator" which is only 1 byte defines which one, the PID number or "preferred ID", is included in the "PID/Pref. ID indicator" field. A 15-byte filed, reserved for temporary number (TN) follows next, which is followed by the "time stamp" filed (20 bytes) indicating the time message was constructed.

With reference to Figure 13, in the TNAS SMS message payload, the first filed labeled "phone number" is an optional 15 bytes of the 140-byte payload and is used for sending the subscriber phone number (MSISDN) to TNAP, which can be used for confirmation of the intended subscriber.

The next 5 bytes are reserved to define the message type which can at least be: "account setup ACK", "TN Response" or "relinquish TN ACK" message types. "PID/Pref. ID" field which is 10 bytes is used to send either the "preferred ID" (before PID grant), or send back the agreed PID number to TNAP. The following field "PID status", which is only 1 byte, indicates whether the "preferred ID" has been accepted and hence, the PID number has been granted, or rejected, therefore remaining as "preferred ID". A 15-byte field, reserved for temporary number (TN) follows next, which is followed by 1-byte "TN status" field, indicating if the field is "valid" or "invalid" (if "invalid" it should be ignored). The last field is "time stamp" field (20 bytes), indicating the time message was constructed.

Note that the above field allocations are exemplary and as such can be modified and optimized without a major impact on the invention. As there are a number of unused bytes in the payload, it is possible to send further information for improved performance of the system.

Now, by way of an example and use of flowcharts, the operation of TNCC of the

Rapid Temporary Number system is explained. It is understood that the flowcharts and system operations are exemplary and can be modified and changed within the scope of the invention. The description is given for a single telephony (PSTN/ISDN) line connected to TNCC, with the allocated SN, which is used as the temporary number (TN) (the same is valid for the data (PDN/IP) line connected to TNCC). However, it is understood that, with appropriate modifications, instead of a single line a multiplicity of lines can be handled by TNCC, with TNCC using substantially the processes that may have some possible modifications to HW, SW and the process flows for optimized operation. Operation of TNCC is discussed for incoming and outgoing calls separately. Further, the example description provided is for voice telephony only, however, it is understood that with appropriate modifications, the same operation can be performed for data services (PDN/IP) and temporary email allocation.

Figure 14 shows the TNCC example schematic block diagram, which is adapted to interface to PSTN/ISDN public network, PLMN and PDN/IP, with the appropriate interfaces to connect to PSTN/ISDN (801), PDN/IP (802) and PLMN (808). TNCC also has additional interfaces to connect to PNDB (806) and TNDB (807) databases. TNCC also has a processing unit (804) to run the TNCC SW (803) and a data storage unit (805). The processing unit (804) also has switching capability to connect PSTN/ISDN, PDN/IP and PLMN lines to each other (two at a time, or all together).

TNCC communicates with the PSTN/ISDN public network via "telephony network interconnect unit" (801), which can be a link based on SS7 protocol or ISDN signaling or other type of signaling such as R2. TNCC operates as entryway for the subscriber's UE to communicate not only with other devices via the PSTN/ISDN public network, but also through other mobile units via the PLMN, using the temporary number (TN). The

"Processing & Switching unit" (804) manages communications and switching functionalities, and has direct control and signaling connections to all interconnect units

(PSTN/ISDN, PDN/IP, PLMN, TNDB & PNDB) and data storage and SW units. TNCC performs various functions to coordinate signaling among PSTN/ISDN public network and

PLMN and between PDN/IP and PLMN. TNCC also has rate adaptation functionality that coordinates signaling rates of different networks. TNCC also performs switching between calls that begin or terminate at the mobile terminal.

Incoming calls

By way of an example, the process in which the incoming calls are processed by TNCC is now discussed. "TNCC telephony" program (850) waits for an incoming call on TN line (852). On receiving a call, the line is connected and a handshaking procedure is performed with caller (853) by the "Processing & Switching Unit" (804), to identify the caller as the TN subscriber or otherwise. By the process of handshaking, the "Processing & Switching Unit" (804) establishes if the call is from the TN subscriber or from a "caller" to TN subscriber, by one (or more) of the following methods described below:

1- Detection of manual or automatic in-band control signaling tones, indicating the call is from TN subscriber. 2- A manual or automatic one-way or two-way sequenced exchange of known sequence of in-band control tones between the TNCC "Processing & Switching Unit" (804) or (904), and the "TNAP outgoing telephony" program (or the TN subscriber, if manual).

3- By using out-of-band signaling if SS7 protocol is used between TNCC and PSTN/ISDN and/or between TNCC and PLMN, if a connection exists between TNCC and Core network. SS7 protocol parts such as INAP can be used with PSTN/ISDN public network, while MAP or CAMEL can be used with PLMN. It may also be possible to use MTP levels 1 , 2 and 3 for this purpose. Note that by checking "caller ID", if available, the handshaking process can be avoided. If "caller ID" is the same as the TN subscriber MSISDN, then the call is from TN subscriber (not shown).

For the purpose of the description here, it is assumed that handshaking is one- way, and based on TNCC detecting the presence of a predefined automatic in-band control signaling tones, generated by "TNAP outgoing telephony" program on connection onset, to establish that the call is from the TN subscriber. If the call is from a "caller" (i.e. it is an incoming call, with in-band control signaling tones absent) (854), the "Processing

& Switching Unit" (804) will ask the "caller" for subscriber PID number (extension) (855). After reading the entered PID number (856), the program proceeds to check the entered

PID number against the TN associated PID number on TNDB (857). If the entered PID number is not the same, the program announces the PID number is incorrect and disconnects the line (858), and returns to wait for an incoming call (852). It is also possible to ask for the PID number again (for a number times) before disconnecting the line (858). If the entered PID number is similar to the PID number on TNDB for TN, "TNCC telephony" program (850) initiates (or dials) a call to subscriber MSISDN number (859) (retrieved from TNDB), via the PLMN interconnect unit (808). "Processing & Switching unit" (804), via the switching unit, will connect the PSTN/ISDN line, carrying TN call, to PLMN link, carrying the MSISDN call (860). Alternatively, it is also possible for the "Processing & Switching unit" (804) to wait until the MSISDN line is connected, optionally inform the subscriber of the incoming TN call, before connecting the PSTN/ISDN line, carrying TN call, to PLMN link carrying the MSISDN call (860). "TNCC telephony" program (850) will then wait for either the MSISDN line (861) or PSTN/ISDN line (862) to get terminated, before terminating the other line (863 & 864) and returning to waiting for an incoming call (852). Note that if SS7 protocol is used between TNCC and PSTN/ISDN and between TNCC and PLMN, SS& SCCP can be used to establish the end-to-end link between the caller and the TN subscriber, before the voice (speech) call is allowed through, hiding the above operation from the end users.

Note if a single TN is used for the operation, without an associated PID number for verification, the simplest option for the "Processing & Switching unit" (804) in connecting the "caller" to subscriber, is to use the ISDN/PSTN public network signaling feature called "call forwarding". For such a case, as soon as the TN is assigned to a subscriber, "Processing & Switching unit" (804) needs to use the required signaling to setup the "call forwarding" of the TN calls to MSISDN number at the PSTN/ISDN switching center.

As mentioned before, the connections between TNCC and MSC (MSCG) and GGSN are optional. An alternative arrangement for TNCC is shown in Figure 16.

In this arrangement (Figure 16), TNCC has no PLMN interconnect unit and hence no direct connection to MSC (MSCG) exists. Therefore the connection of the TN line to subscriber line (MSISDN) has to be through the PSTN/ISDN (or PDN/IP with VoIP). In such an arrangement, the PSTN/ISDN public network signaling feature called "call transfer" (where available) can be used by "TNCC telephony" program (950). If the "call transfer" feature is used, Figure 15 can be modified as shown in Figure 17. In Figure 17, the MSISDN number is dialed over the existing PSTN/ISDN TN line at (959) and the call is then transferred either after subscriber is connected and accepting the call or soon after the dialing of the MSISDN number is finished (960). It is also possible not to terminate the TN line, and continue in a "3-way" call (Caller-TNCC-Subscriber), instead of a full "call transfer". Note that if SS7 protocol is used between TNCC and PSTN/ISDN, SS7 protocol (e.g. SCCP) can be used to establish the end-to-end link between the caller and the TN subscriber, using a single PSTN/ISDN speech line, before the voice (speech) call is allowed through end-to-end, hiding the above operation from the end users.

If the "call transfer" feature is not available, then an extra PSTN/ISDN line may be required to connect TNCC to MSISDN (i.e the TN subscriber). In such an arrangement, the incoming call over the TN line is connected to the outgoing call to MSISDN, through the "Processing and Switching Unit" (904).

Outgoing calls

Figure 18 shows the "TNAP outgoing telephony" program flowchart. This is a program that the TN subscriber runs on the UE₁ in order to make a call, using the temporary number (TN) for the TNCC to receipt connection.

On entry into "TNAP outgoing telephony" program (971), the subscriber is asked to enter the recipient subscriber number (SN) that is to be dialed (972). After reading and storing the entered SN (973), the program proceeds to retrieve the temporary number (TN) from UE memory or disk (974). The TN number is then dialed (975) and the program sets a timer t (976), waiting for the line to be connected to TNCC. If the line is not connected to TNCC while the timer t is valid (i.e. not expired) (978), the program reports an error (979) and terminates (986).

If the line is connected while timer t is valid (977), the program proceeds to perform "handshaking" with TNCC (980) to identify the caller as the TN subscriber. For the purpose of the description here, it is assumed that handshaking is one-way, and based on "TNAP outgoing telephony" sending a predefined automatic in-band control signaling tones, on connection of the line, to establish that the call is from the TN subscriber (980).

After the handshaking (980), the "TNAP outgoing telephony" program (970) proceeds to send the destination subscriber number (SN) to be called (981). The destination subscriber number (SN) can be sent by in-band control signaling tones, generated by "TNAP outgoing telephony". A timer t (982) is set, while waiting for the line to be connected to the SN destination. If the line is not connected to SN destination (983) while the timer t is valid (984), the program reports an error (985) and terminates (986). If the line is connected to SN destination while the timer t is valid (983), the program terminates, allowing the call to continue as long as needed (986).

On TNCC side, with reference to Figure 15 (TNCC telephony program flowchart), if a call is received and the call is not from TN subscriber (854), the "TNCC telephony" program (850) will extract the destination SN from the incoming in-band control signaling tones, generated by "TNAP outgoing telephony" (865). Then it proceeds to dial the SN on

PSTN/ISDN line, which can be the same line if "call transfer" is available, or a different line if "call transfer" not available (866). If it is on a different line, the "Processing & Switching Unit" (804 or 904) has to use the switch to connect the two lines, mainly the incoming (from TN subscriber) and the outgoing line (to SN destination) (867). Then the program waits until one of the lines, either the incoming or outgoing line is terminated by the user (868, 869), before terminating the other line (870, 871), and returning to (852).

The above discussion assumes the call setup between "TNAP outgoing telephony" and TNCC is performed over PSTN/ISDN line. However, as shown in Figure 15, TNCC may also have a direct line to MSC (and GGSN)₁ where the calls from "TNAP outgoing telephony" to TNCC can be routed through PLMN, not needing to go through PSTN/ISDN public network. In all examples above, PDN/IP network can be used, where available, with VoIP applications, in any of the links within the operations discussed so far.

Stand-Alone method

Figure 19 shows the "Stand-alone" Temporary Number system block diagram. It must be noted that Figure 19 is one example in which the novel idea can be realized.

There may be other network permutations that can also support the disclosed invention here. For most part, Figure 19 is a simplified version of the network shown in Figure 1 , with only the logical network connections shown in this figure. The "Stand-alone" network elements and operation are substantially similar to the "PLMN-based" elements and operations discussed above, with one major difference. The difference being, while TNAS in "PLMN-based" method was part of the same PLMN that housed SMSC, it is now outside the PLMN network. In this setup, a SMSG (SMS gateway) is used to connect the

SMSC servicing TNAS to other PLMN's SMSC serving cellular subscriber, via network elements and ISDN/PSTN or data network PDN/IP. As SS7 protocols can be used for control signaling between TNCC and GMSC, both TNCC architectures shown in Figures 800 and 900 can be supported with the "stand-alone" method.

General Notes

1- Personal IDentification Number (PID) can be treated as a "secret" password by the TN subscriber, or it can be stored in non-volatile memory or disk, and retrieved when ever needed.

2- A voice-box functionality can also be supported by TNCC, so that TN caller can leave a voice message on TNCC.

3- "Call waiting" can also be used in TNCC₁ such that a TN subscriber is informed of an incoming call, while TN caller is on hold.

4- An option can be introduce for subscribers who wish to keep their temporary number for a long time (say more than 12 months), where the PID inclusion is no longer required, with only TN sufficient for incoming and outgoing calls.

Claims

What Is Claimed Is:

1. A Rapid Temporary Phone Number system and apparatus operating as part of the cellular network, comprising of at least one application software residing in at least one of the mobile units of the network having a unique initial subscriber number, and a Rapid Temporary Phone Number network unit comprising of at least a Temporary

Number Application Server unit,

where the said mobile unit application software enables the said mobile unit to acquire at least one new additional subscriber number from the Rapid Temporary Phone

Number network on demand and facilitates the subsequent said mobile unit's outgoing calls via the new additional subscriber number, and where Temporary Number

Application Server unit:

- provides and allocates at least one new subscriber number for the said mobile unit if demanded and,

- directs subsequent outgoing calls made by the said mobile unit to the specified number.