GB2520537A

GB2520537A - Determining calling party telephone number

Info

Publication number: GB2520537A
Application number: GB1320714.7A
Authority: GB
Inventors: Peter Karney; Geno Esposito; Erol Ziya
Original assignee: HIBU UK Ltd
Current assignee: HIBU UK Ltd
Priority date: 2013-11-25
Filing date: 2013-11-25
Publication date: 2015-05-27
Also published as: GB201320714D0

Abstract

A method at a telephony device comprising: sending to a web server, over an internet connection, a request to establish a telephony call with a destination telephony device, the request comprising an identifier (e.g. an application serial number of a software application at the calling party) associated with the calling telephony device; receiving, form the web server an intermediate code (e.g. a DTMF code, or a temporary telephone number or any reference that may be sent as part of a telephone call); making, in response to receipt of the intermediate code, a telephony call to a telephony call handler connected to the web server, the telephony call comprising details of the intermediate code and also comprising a telephone number of the telephony device. In various examples, a web server establishes a link between a calling party identifier and a telephone call from the calling party from which the telephone number of the calling party is observed. The web server 104 searches for and finds a link between the calling party telephone number and the calling identifier. This link is found through the intermediate code.

Description

DETERMINING CALLING PARTY TELEPHONE NUMBER

Background

Some types of existing mobile telephone operating systems do not make the telephone number of the mobile telephone available to applications which may be on the mobile telephone. Other types of existing mobile telephone operating systems may make the telephone number available to software applications on the device but do not guarantee the accuracy of the telephone number. For example, if a subscriber identification module (SIM) at the mobile telephone has been replaced the telephone number associated with the old SIM may be provided.

This makes it difficult for software applications executing on a mobile telephone to provide functionality where the telephone number of the device is required with certainty and accuracy.

In order to obtain the telephone number software applications may request this infomiation from the end user, for example, by presenting a data entry box and requesting the user to type in the telephone number. However, this is difficult and confusing for the end user. For example, the end user might not know the telephone number of the device. The end user may make a mistake typing in the telephone number. The end user may enter the telephone number in a wrong format, for example, using international dialing codes, delimiters or other formatting. The end user may lack confidence in the authenticity of a software application which asks for the telephone number and refuse to enter the data.

The embodiments described below are not limited to implementations which solve any or all of the disadvantages of known ways of determining a calling party telephone number.

Summary

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

Determining a calling party telephone number is described, for example, to enable a web service to find the telephone number of a mobile telephone even where the operating system of the mobile telephone does not make the telephone number available through an application programming interface in an accurate manner. In various examples, a web server establishes a link between a calling party identifier (such as an application serial number of a software application at the calling party) and a telephone call from the calling party from which the telephone number of the calling party is observed. In some examples the link is established by using a dual-tone multi frequency (DTMF) code. In some examples the link is established by using a unique temporary telephone number. In various examples a telephone call is established between a calling party and a destination party via a telephony call handler associated with the web server.

A first aspect provides a communications apparatus comprising: a web server arranged to receive, over an internet connection, a request from a calling telephony device to call a destination telephony device, the request comprising an identifier associated with the calling telephony device; the web server arranged to generate an intermediate code and to link the intermediate code to the identifier associated with the calling telephony device; the web server arranged to send the intermediate code to the calling telephony device; a telephony call handler connected to the web server and arranged to receive a telephony call from the calling telephony device, the telephony call comprising details of the intermediate code and also comprising a telephone number of the calling telephony device; the web server arranged to detect and store a link between the identifier associated with the calling telephony device and the telephone number of the calling telephony device.

A second aspect provides a method at an intermediate telephony apparatus comprising: receiving, over a web connection, a request from a calling telephony device to establish a telephony call with a destination telephony device, the request comprising an identifier associated with the calling telephony device; generating an intermediate code and linking the intermediate code to the identifier associated with the calling telephony device; sending the intermediate code to the calling telephony device; receiving a telephony call from the calling telephony device, the telephony call comprising details of the intermediate code and also comprising a telephone number of the calling telephony device; detecting and storing a link between the identifier associated with the calling telephony device and the telephone number of the calling telephony device.

A third aspect provides a method at a telephony device comprising: sending to a web server, over an internet connection, a request to establish a telephony call with a destination telephony device, the request comprising an identifier associated with the calling telephony device; receiving, from the web server an intermediate code; making, in response to receipt of the intermediate code, a telephony call to a telephony call handler connected to the web server, the telephony call comprising details of the intermediate code and also comprising a telephone number of the telephony device.

A fourth aspect provides a telephony device comprising: a communications intertace arranged to send to a web server, over an internet connection, a request to establish a telephony call with a destination telephony device, the request comprising an identifier associated with the calling telephony device; the communications interface being arranged to receive, from the web server, an intermediate code; a telephone arranged to make a telephony call to a telephony call handler connected to the web server, the telephony call comprising details of the intermediate code and also comprising a telephone number of the telephony device The methods described herein may be performed by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium. Examples of tangible (or non-transitory) storage media include disks, thumb drives, memory cards etc and do not include propagated signals. The software may be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.

This acknowledges that firmware and software may be valuable, separately tradable commodities. It is intended to encompass software, which runs on or controls "dumb" or standard hardware, to carry out the desired functions. It is also intended to encompass software which "describes" or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.

The preferred features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the invenfion.

Brief Description of the Drawings

Embodiments of the invention may be described, by way of example, with reference to the following drawings, in which: Figure 1 is a schematic diagram of a calling party phone number detection system deployed at communications networks comprising a calling party and a plurality of destination telephony devices; Figure 2 is a message sequence chart of a method of detecting a calling party telephone number; Figure 3 is a message sequence chart of another method of detecting a calling party telephone number for use subsequent to the method of Figure 2; Figure 4 is a schematic diagram of a calling party phone number detection system, a calling party, a destination telephony device, and illustrating an example DTMF method; Figure 5 is a schematic diagram of the deployment of Figure 4 and illustrating a method subsequent to the method of Figure 4; FigureS is a schematic diagram of the deployment of Figure 4 and illustrating an example number pool method; Figure 7 is a schematic diagram of a calling party computing device or a calling party phone number detection system which may be implemented as any form of a computing and/or electronic device, and in which parts of the methods described herein may be implemented.

Common reference numerals are used throughout the figures to indicate similar features.

Detailed Description

Embodiments of the present invention are described below by way of example only. These examples represent the best ways of putting the invention into practice that are currently known to the Applicant although they are not the only ways in which this could be achieved.

The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

Figure lisa schematic diagram of a calling party phone number detection system 102 deployed at communications networks 108 comprising a calling party 100 and a plurality of destination telephony devices 110, 112, 114. The calling party phone number detection system 102 may provide a web service which detects a telephone number of the calling party 100. The telephone number may then be made available to other entities such as other web services (not shown), or applications at the calling party 100. For example, to enable a telephone directory to be compiled, for caller profiling, to track and/or measure calls, to authenticate the caller using the telephone number, orto route calls based on the caller's identity (such as in a call centre for example).

The calling party 100 comprises a telephony device such as a smart phone or any other communications device which is capable of both communications with a web server and telephony communication. The calling party 100 may be a voice over internet protocol telephony device in examples where the destination telephony device also has voice over internet protocol facility. The calling party 100 comprises a web interface 122 such as a browser or other component arranged to establish a web socket or other internet communications channel between the calling party 100 and web server 104. The web interlace 122 may be implemented using software and/or hardware. The calling party comprises a telephony component 120 which enables telephone calls to be established between the calling party and one or more destination telephony devices 110, 112, 114. The telephone calls may be for example, voice calls, fax or in-band data calls. In some examples, the calling party 100 comprises at least one software application which has an application serial number 118. The software application may be configured to interoperate with the web server 104 and/or with a second web server 124. For example, software at the web server 104 comprises an application programming interface. For example, software at the second web server 124 comprises a second application programming interface. Software at the calling party 100 application may use functionality at the web servers by sending requests to the web servers which have function names of the application programming interfaces.

In one example, the software application and functionality at the second web server 124 together provide a directory service to enable an end user to find electricians, plumbers, builders or other entities. For example, as illustrated in Figure 1 the software application may display a graphical user interface 116 with information retrieval results comprising at least one destination listing (that is, details of an electrician, plumber or other party to be contacted).

The information retrieval results may be retrieved by the second web server 124 from database 126 or any other source. An end user may have an option to select a call button 119 to make a telephony call from the calling party 100 to a destination telephony device associated with the destination listing. The calling party phone number detection system 102 may facilitate tracking of a call from the end user to the destination telephony device. This is one example given to illustrate the potential use of the calling party phone number detection system 102. However, many other examples are possible.

The calling party phone number detection system 102 comprises a telephony call handler 106 which is able to receive telephone calls, route telephone calls, initiate telephone calls, play custom sound files to either party. For example, the telephony call handler 106 may be implemented using software running on computer hardware such as a server. The calling party phone number detection system 102 also comprises a web server 104 connected to the telephony call handler 106. The web server 104 is computer implemented using software and/or hardware and may comprise a software application programming interface as mentioned above.

The second web server may be arranged to serve one or more web pages to the calling party 100 web browser and/or software application. For example, the second web server 124 serves a graphical user interface to the calling party 100 to enable a graphical user interface display 116 at the calling party 100.

The communications networks 108 comprise wired and/or wireless communications networks and are able to support both web-based communications and telephony calls (where telephony calls include any one or more of: traditional voice telephone calls, fax or in-band data calls, voice over internet protocol calls).

A plurality of destination telephony devices 110, 112, 114 are illustrated in Figure 1 and it is noted that the calling party phone number detection system 102 may also be a destination telephony device in some examples (such as when the connection fails and an error announcement is played). The destination telephony device may be a conventional land line telephone 110, a mobile telephone 112, a voice over internet telephone 114 or any other telephony device which is able to receive a call, such as a voice fax or data call.

Figure 2 is a message sequence chart of a method of detecting a calling party telephone number. Each vertical line in Figure 2 represents an entity and arrows between the vertical lines represent messages or telephone calls between the entities. The relative vertical position of the arrows on the page indicates the chronological order of the messages or telephone calls. In the example of Figure 2 a calling party web interface 122 and a calling party telephony component 120 are shown such as those components of the calling party 100 illustrated in Figure 1. Although these components are shown in Figure 2 using separate vertical lines these components may be connected within the calling party equipment. A web server 104, and an intermediate telephony call handler 106 are also shown using separate vertical lines although these components may be connected within the calling party phone number detection system 102. A second web server 124 is shown as in FIG. 1. A destination telephony device 110, 112, 114 is shown as in Figure 1.

The calling party web interface 122 sends a request 214 to the second web server 124. The request may be a hyper text transfer protocol (HTTP) web request or any other suitable web request. The web request may be sent over a web socket or other web communication channel already established between the calling party and the web server 104, for example, as a result of operation of the software application at the calling party. The request may be an information retrieval request, for example, a request to find plumbers in a geographical area. The second web server 124 sends a response 216 over the web communication channel. The response may comprise the information retrieval results. User input at the calling party may indicate that a call is to be placed to one of the plumbers for example. The call may be established as now described, in a mannerwhich tracks the call.

The calling party web interface 122 sends a request 200 to the web server 104. For example, the software application at the calling party creates the request and knows the address of the web server 104 to send the request to. The request may be initiated as a result of an end user selecting an optional to call a destination which may be one of the destination telephony devices of Figure 1, or may be the detection system 102 itself in some examples. In some examples the request 200 is initiated automatically without the need for user input.

The request may be a hypertext transfer protocol (HTTP) web request or any other suitable web request. The web request may be sent over a web socket or other web communication channel already established between the calling party and the web server 104, for example, as a result of operation of the software application at the calling party.

In some examples the request comprises a destination telephone number or other details of a destination telephony device with which it is required to establish a call.

The request comprises a calling identifier. Forexamplethe calling identifier is an application serial number 118 of the software application at the calling party. In other examples the calling identifier is an identifier of the calling party device 100 such as a manufacturer's device serial number. The calling identifier may be a unique identifier created on the web server 104 that is stored in a web browser cookie on the calling party device 100. The calling identifier may be a randomly generated unique identifier, created by the application on the calling party device.

The web server checks whether it already knows the calling party by checking whether it has previously received the calling identifier. This check enables the web server 104 to decide 202 whether to generated an intermediate code or not. If the calling party is already known, no intermediate code is to be generated and the process moves to the situation of Figure 3. If an intermediate code is to be generated, the web server generates that code. In some examples the intermediate code is a dual tone multi-frequency (DTMF) code. In some examples the intermediate code is a temporary telephone number. The intermediate code may be any reference that may be sent as pad of a telephone call or associated signalling.

In examples where the request 200 comprises a destination telephone number or other details of a destination telephony device, the web server may store that information together with the intermediate code.

The web server sends 204 the intermediate code to the calling party web interFace 122. For example, this information is sent from the web server to the calling party over the web socket.

In response, the calling party telephony component 120 makes a telephone call to the intermediate telephony call handler 106. This telephone call may be made by the calling party telephony component 120 automatically. In other examples, the software application at the calling party 100 generates a graphical user interlace giving the end user an option to place the call. For example, the user may be requested to place a call to the destination without displaying the destination telephone number. If appropriate user input is received the software application instructs the telephony component 120 to place the call to the telephony call handler 106. The telephone number of the telephony call handler 106 may be pre-configured at the software application on the calling party device 100. In other examples, a telephone number of the telephony call handler 106 is sent as part of message 204 or is the intermediate code.

The telephone call 206 comprises the calling party telephone number. The telephone call 206 also comprises the intermediate code. For example, by sending DTMF tones as pad of the call. In another example, this is achieved by the fact that the telephone call is made to the intermediate code which is one of a plurality of temporary telephone numbers of the intermediate telephony call handler 106.

The web server 104 searches for and finds a link between the calling party telephone number and the calling identifier. This link is found through the intermediate code. The web server is then able to store the link 208 and/or store the calling party telephone number associated with the calling identifier. Once this link is established the web server is able to delete the intermediate code from any records it created as part of the process of enabling the link to be found. This saves memory and enables the deployment to scale up for large numbers of calling parties. In the case that the intermediate code is a temporarytelephone number allocated from a limited pool of such numbers, the intermediate code is returned to the pool for reuse. This enables a limited pool of intermediate telephone numbers to be used even for large scale deployments.

In some examples, the intermediate telephony call handler 106 proceeds to make a telephone call 212 to the destination telephony device. The telephone calls 206, 212 may be joined so that a telephony call between the calling and destination parties is established 210.

Note that the second web server 124 and the messages 214 and 216 are not essential and may be omitted in some examples. For example, where a directory service (finding plumbers etc.) is not used and the web server 104 provides the service of determining a calling party telephone number.

Figure 3 is a message sequence chart such as that of FIG. 2 and for a situation where the calling party is already known to the calling party phone number detection system 102.

In this example a request 214 may be sent to a second web server 124 and a response 216 received in the same way as described for Figure 2. For example, where a directory service is provided by the second web server 124. However, this is not essential.

In the example of Figure 3 a request 200 is sent from the calling party web interface 122 to the web server 104 in the same way as described for Figure 2. The web server finds that the calling identifier is already known 300. The web server and associated telephony call handler 106 are now able to track and/or route any calls from the calling party because the calling party telephone number is accurately known and associated to the calling identifier.

For example, to track a call from the calling party, the process of FIG. 3 may be used.

The web server sends a message 302 to the calling party web interface 122 indicating that it knows the calling identifier. In response the calling party telephony component 120 makes a telephone call 304 (as described above with reference to Figure 2) to the telephony call handler 106 without the need for an intermediate code. The incoming call 304 may be joined to an outgoing call 306 from the telephony call handler 106 to the destination.

The web server is able to track the call between the calling party and the destination because the call passes through the telephony call handler 106. Also, the web server knows the association between the calling party telephone number and the calling identifier and so it is able to track the call's association with use of the software application.

Figure 4 is a schematic diagram of a calling party phone number detection system 104, 106, a calling party400, 120, a destinationtelephonydevice 110, 112, 114, and illustrating an example DTMF method. In this example the calling party comprises a mobile application 400 which is a software application at a mobile communications device such as a smart phone.

The calling party also comprises a telephony component 120. This is an example only as other types of calling party device may be used in place of a mobile telephone.

The mobile application 400 allows an end user, also referred to as an A-party, to search for a destination. Following the search the details of the destination are shown to the end user.

The destination listing includes a "call" button at a graphical user interface of the mobile telephone.

STEPI

When the end user presses the call" button an HTTP web request is sent from the mobile application 400 to the web server which in this example is an Intermediate Telephony Platform API 104. The request contains the Application Serial Number as well as the destination B-number (the destination B-number is the telephone number of the destination telephony device.

STEP 2A When the Intermediate Telephony Platform 104 receives the incoming request it performs a database lookup in an end users "table" based upon the Application Serial Number. Since this is the first time the Intermediate Telephony Platform 104 has encountered the end user and their application no record may be present. The end users table may be stored in any suitable form such as a list or array and does not need to be a table.

STEP 2B The Intermediate Telephony Platform 104 may generate a short and unique string of digits such as 123. These digits may later be sent via DTMF tones and therefore must conform to the DTMF numbering range (09,A,B,C,D,* and It). Since the * and It may have other special uses in other pads of this example the effective range is 0-9, A, B, C,D. The generated shod, unique string of digits is referred to herein as DTMF String.

STEP 2C The Intermediate Telephony Platform may create a new record in the end users"table". Within this table may be stored the following parameters for each end user and their application: * Application Serial Number (to act as the index) * DTMF String Additional data may be linked to this record later.

STEP 2D The Intermediate Telephony Platform 104 may create a new record in an inbound calls "table". The inbound calls table may be stored in other forms such as a list and is not limited to a table. Within this table may be stored the following parameters: DTMF String (to act as the index) * Destination B-number STEP 3 The Intermediate Telephone Platform 104 may respond to the application with the DTMF String, User State: Unknown and a Fixed Intermediate Numberwhich is the telephone number of the intermediate telephony platform call handler 106 (this is optional as another approach is to hard code the fixed intermediate number in the application).

An example response message takes the following form: <Response> <User State> Unknown </User State> <DTMF String> 1D# </DTMF String> <Fixed Intermediate Number> <I Fixed Intermediate Number> </Response> The # is to used as a terminating character to indicate the end of the DTMF string for when it is sent in band as tones.

STEP 4 The application may now initiate a call to the Fixed Intermediate Number returned in the response appended with a comma "," and the DTMF String.

0118 123 4567,10# It is the behaviour of the phone dialler at the calling party to dial the number proceeding the comma and the once the call has been answered play the DTMF string as tones down the line. The carrier of the end user may route the call to the Fixed Intermediate Number destination which may be the Intermediate Telephony Platform.

STEP GA

A call handler 106 on the Intermediate Telephony Platform may answer the call and collect and decode the DTMF tones received in band, namely 1 D#. The U denotes the end of DTMF sting and therefore the call handler may not need to wait for additional digits.

Also received as part of the call related signalling may be the MSISDN of the A-party (the end user). For example: 44777 123 4567. An MSISDN is a telephone number linked to an international mobile subscriber identity (IMSI). An IMSI is used to identify the user of a cellular network and is a unique identification associated with cellular networks.

STEP GB

Based on the A-party number the call handler 106 may check within the inbound calls table to check if there are any records. As this is the first call from the end user no record may be found based on the A-party number.

Based on the DTMF string the call handler may check within the inbound calls table to check if there are any records. A record may be found with a corresponding B-number (the number of the destination telephony device).

STEP GC

Based on the DTMF string the call handler may check within the end users "table". A record may be found with a corresponding Application Serial Number. This record may now be updated to also include the A-Party number. The call handler may therefore now have a mapping between the Application Serial Number and A-party Number for future subsequent use.

STEP 6 Based on the B-number a call may be initiated to the destination telephony device and the two calls joined (incoming and outgoing).

STEP 7 Now that the record within the end users "table" has been updated and the call to the destination telephony device B-number has been established, the DTMF string may now be released for re-use. Since the case exists where the call does not arrive at the platform the, allocated DTMF strings that are not used within a certain time pehod may be set to expire.

This may have an impact on the number of strings required and may tend to increase it from the theoretical minimum.

STEP 8&9 The call handler maintains the call until either the A-or B-party hangs up. The call is then released.

Any call metadata may then be written into an additional table to allow call metrics to be stored. These may include: * Call Start Time * A-party number * B-party number * Call Duration * Call state (Answered, Busy, No Answer) FIGURE 5 In the case where the end user makes subsequent calls the scenario may be further optimised based on information already held within the end users "table".

STEP I

When the end user presses the call" button an HTTP web request is sent from the mobile application to the Intermediate Telephony Platform API 104. The request contains the Application Serial Number as well as the Destination telephony devices B-number.

STEP 2A When the Intermediate Telephony Platform receives the incoming request it performs a database lookup in the end users "table" based upon the Application Serial Number. Since this is not the first time the Intermediate Telephony Platform has encountered the end user and their app, a record may be present including their MSISDN.

STEP 2B The Intermediate Telephony Platform may create a new record in an inbound calls lable".

Within this table may be stored the following parameters: * End userA-number * Destination telephony device B-number STEP3 The Intermediate Telephone Platform may respond to the application indicating that the mobile application serial number, and therefore end user, is known and the Fixed Intermediate Number (this is optional as another approach would be to hard code this in the app).

STEP 4 The application may now initiate a call to the Fixed Intermediate Number returned in the response. No DTMF tones need to be applied. The carrier of the end user may route the call to the Fixed Intermediate Number destination which may be the Intermediate Telephony Platform.

STEP 5 A call handler on the Intermediate Telephony Platform may answer the call.

Also received as part of the call related signalling may be the MSISDN of the A-party (the end user). For example: 44777 123 4567.

Based on the A-party the call handler may check within the inbound calls table to check if there are any records. A record may be found with a corresponding B-number (the number of the destination telephony device).

STEP 6 Based on the B-number a call may be initiated to the destination telephony device and the two calls joined (incoming and outgoing) STEP 7&8 The call handler maintains the call until either the A-or B-party hangs up. The call is then released. Any call metadata may then be written into an additional table to allow call metrics to be stored. These may include: * Call Start Time * A-party number * B-party number * Call Duration * Call state (Answered, Busy, No Answer) In another example with reference to Figure 6, rather than using DTM F tones to form a correlation between an application serial number and an incoming call, a pool of dialled numbers may be used. So rather than returning a DTMF string to the requesting application a unique and temporary phone number is returned for the initial call. This greatly reduces the call setup time for the first call and brings the first call into line (in terms of call set up) with all other calls adding just a second to the overall call setup. It also gets around other issues such as: * The end user may hear the DTMF tones and become confused or concerned.

* The rate at which the dialler sends DTMF tones is inconsistent across handset model and manufacturers.

* Not all phone diallers may be able to handle the pause.

The mobile application allows the end user who in this case may also be the A-party to search for a destination telephony device.

Following the search the details of the destination telephony device are shown to the end user. The destination telephony device listing includes a "call" button

STEPI

When the end user presses the "call" button an HTTP web request is sent from the mobile application to the Intermediate Telephony Platform API. The request contains the Application Serial Number as well as the Destination telephony devices B-number.

STEP 2A When the Intermediate Telephony Platform receives the incoming request it performs a database lookup in the end users "table" based upon the Application Serial Number. Since this is the first time the Intermediate Telephony Platform has encountered the end user and their app. No record may be present.

STEP 2B The Intermediate Telephony Platform may select a Fixed Intermediate Number from the pool of available numbers. We may call this the Temporary Intermediate Number.

STEP 2C The Intermediate Telephony Platform may create a new record in an end users "table". Within this table may be stored the following parameters for each end user and their app: * Application Serial Number (to act as the index) * Temporary Intermediate Number.

Additional data may be linked to this record later.

STEP2D The Intermediate Telephony Platform may create a new record in an inbound calls "table".

Within this table may be stored the following parameters: * Temporary Intermediate Number.

* Destination telephony device B-number STEP 3 The Intermediate Telephone Platform may respond to the application with the User State: Unknown and Temporary Intermediate Number.

STEP 4 The application may now initiate a call to the Temporary Intermediate Number returned in the response.

The carrier of the end user may route the call to the Temporary Intermediate Number destination which may be the Intermediate Telephony Platform.

STEP GA

A call handler on the Intermediate Telephony Platform may answer the call Also received as part of the call related signalling may be the MSISDN of the A-party (the end user). For example: 44777 151 2290, and the dialled number 01181234599 namely the Temporary Intermediate Number.

STEP GB

Based on the A-party number the call handler may check within the inbound calls table to check if there are any records. As this is the first call from the End user no record may be found based on the A-party number.

Based on the Temporary Intermediate Number the call handler may check within the inbound calls table to check if there are any records. A record may be found with a corresponding B-number (the number of the destination telephony device).

STEP 5C Based on the Temporary Intermediate Numberthe call handler may check within the end users "table". A record may be found with a corresponding Application Serial Number. This record may now be updated to also include the A-Party number. The call handler may therefore now have a mapping between the Application Serial Number and A-party Number for future subsequent use.

STEP 7 Now that the record within the end users "table" has been updated and the call to the destination telephony device B-number has been established, the Temporary Intermediate Number may now be released for re-use. The number of Temporary Intermediate Numbers required may be calculated in the same way as the number of DTMF strings used in the previous method. Since the case exists where the call does not arrive at the platform the, allocated Temporary Intermediate Numbers that are not used within a certain time period may be set to expire.

Any call metadata may then be written into an additional table to allow call metrics to be stored. These may include: * Call Start Time * A-party number * B-party number * Call Duration * Call state (Answered, Busy, No Answer) Figure 7 illustrates various components of an exemplary computing-based device 700 which may be implemented as any form of a computing and/or electronic device, and in which embodiments of a calling party or a calling party phone number detection system may be implemented.

Computing-based device 700 comprises one or more processors 702 which may be microprocessors, controllers or any other suitable type of processors for processing computer executable instructions to control the operation of the device in order to implement at least part of one or more of the methods described herein. In some examples, for example where a system on a chip architecture is used, the processors 702 may include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method of any of Figures 2 to 6 in hardware (rather than software or firmware). Platform software comprising an operating system 704 or any other suitable platform software may be provided at the computing-based device to enable application software 724 to be executed on the device. Where the computing-based device 700 is a calling party it comprises a telephony component 706 and a web interface 706. Where the computing-based device 700 is a calling party phone number detection system it comprises a telephony call handler 708 and a web server 706.

The computer executable instructions may be provided using any computer-readable media that is accessible by computing based device 700. Computer-readable media may include, for example, computer storage media such as memory 712 and communications media.

Computer storage media, such as memory 712, includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that may be used to store information for access by a computing device. In contrast, communication media may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transport mechanism. As defined herein, computer storage media does not include communication media. Although the computer storage media (memory 712) is shown within the computing-based device 700 it may be appreciated that the storage may be distributed or located remotely and accessed via a network or other communication link (e.g. using communication interface 714).

The computing-based device 700 also comprises an input/output controller 716 arranged to output display information to a display device 718 which may be separate from or integral to the computing-based device 700. The display information may provide a graphical user interlace. The inputloutput controller 716 is also arranged to receive and process input from one or more devices, such as a user input device 720 (e.g. a mouse or a keyboard). This user input may be used to activate a call button at a graphical user interface, type in a telephone number, select a destination listing, or for other purposes In an embodiment the display device 718 may also act as the user input device 720 if it is a touch sensitive display device. The input/output controller 716 may also output data to devices other than the display device, e.g. a locally connected printing device.

The term compute( is used herein to refer to any device with processing capability such that it may execute instructions. Those skilled in the art may realize that such processing capabilities are incorporated into many different devices and therefore the term computer' includes PCs, servers, mobile telephones, personal digital assistants and many other devices.

Those skilled in the art may realize that storage devices utilized to store program instructions may be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network).

Those skilled in the art may also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.

Any range or device value given herein may be extended or altered without losing the effect sought, as may be apparent to the skilled person.

It may be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages.

Any reference to an' item refers to one or more of those items. The term comprising' is used herein to mean including the method blocks or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or apparatus may contain additional blocks or elements.

The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Additionally, individual blocks may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.

It may be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art.

Although various embodiments have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the spirit or scope of this invention.

Claims

Claims 1. A communications apparatus comprising: a web server arranged to receive, over an internet connection, a request from a calling telephony device to call a destination telephony device, the request comprising an identifier associated with the calling telephony device; the web server arranged to generate an intermediate code and to link the intermediate code to the identifier associated with the calling telephony device; the web server arranged to send the intermediate code to the calling telephony device; a telephony call handler connected to the web server and arranged to receive a telephony call from the calling telephony device, the telephony call comprising details of the intermediate code and also comprising a telephone number of the calling telephony device; the web server arranged to detect and store a link between the identifier associated with the calling telephony device and the telephone number of the calling telephony device.
2. A method at an intermediate telephony apparatus comprising: receiving, over a web connection, a request from a calling telephony device to establish a telephony call with a destination telephony device, the request comprising an identifier associated with the calling telephony device; generating an intermediate code and linking the intermediate code to the identifier associated with the calling telephony device; sending the intermediate code to the calling telephony device; receiving a telephony call from the calling telephony device, the telephony call comprising details of the intermediate code and also comprising a telephone number of the calling telephony device; detecting and storing a link between the identifier associated with the calling telephony device and the telephone number of the calling telephony device.
3. A method as claimed in claim 2 comprising generating the intermediate code in the form of a dual-tone multi-frequency code.
4. A method as claimed in claim 3 comprising sending a telephone number of the intermediate telephony apparatus to the calling party over the web connection.
5. A method as claimed in claim 2 comprising generating the intermediate code by taking a telephone number from a pool of temporary telephone numbers associated with the intermediate telephony apparatus.
6. A method as claimed in claim 2 comprising deleting or reusing the intermediate code afterthe link has been stored.
7. A method as claimed in claim 2 comprising establishing a second call from the intermediate telephony apparatus to the destination telephony device and joining the telephony call from the calling telephony device to the second call.
8. A method as claimed in claim 2 wherein the identifier associated with the calling telephony device is an application serial number of an application at the calling telephony device.
9. A method as claimed in claim 2 wherein linking the intermediate code to the identifier of the calling telephony device comprises storing the intermediate code and the identifier of the calling telephony device in a record.
10. A method as claimed in claim 9 wherein storing the link comprises storing the calling party telephone number in the record in association with the identifier of the calling telephony device.
11. A method as claimed in claim 2 comprising storing a second record having the intermediate code as an index containing a telephone number of the destination telephony device received in the request.
12. A method as claimed in claim 2 wherein sending the intermediate code to the calling party comprises sending the intermediate code to the calling party over the web connection.
13. A method at a telephony device comprising: sending to a web server, over an internet connection, a request to establish a telephony call with a destination telephony device, the request comprising an identifier associated with the calling telephony device; receiving, from the web server an intermediate code; making, in response to receipt of the intermediate code, a telephony call to a telephony call handler connected to the web server, the telephony call comprising details of the intermediate code and also comprising a telephone number of the telephony device.
14. A method as claimed in claim 13 comprising sending the intermediate code as part of the telephony call by playing a dual tone multi-frequency code.
15. A method as claimed in claim 13 comprising making the telephony call to a temporary telephone number provided as part of the intermediate code.
16. Atelephony device comprising: a communications interface arranged to send to a web server, over an internet connection, a request to establish a telephony call with a destination telephony device, the request comprising an identifier associated with the calling telephony device; the communications interface being arranged to receive, from the web server, an intermediate code; a telephone arranged to make a telephony call to a telephony call handler connected to the web server, the telephony call comprising details of the intermediate code and also comprising a telephone number of the telephony device.
17. A communications apparatus substantially as described with reference to or as shown in the accompanying drawings.
18. A method at an intermediate telephony apparatus substantially as described with reference to or as shown in the accompanying drawings.
19. A method at a telephony device claim 13 substantially as described with reference to or as shown in the accompanying drawings.
20. A telephony device as claimed in claim 16 substantially as described with reference to or as shown in the accompanying drawings.