WO2009010746A1

WO2009010746A1 - Data format selection

Info

Publication number: WO2009010746A1
Application number: PCT/GB2008/002425
Authority: WO
Inventors: Huina Chua; Wei Ju Khoo; Lee Fueng Yap
Original assignee: British Telecommunications Public Limited Company
Priority date: 2007-07-16
Filing date: 2008-07-16
Publication date: 2009-01-22

Abstract

A method for presenting data sent by a sender to a receiver, the receiver using a receiving device having a plurality of output method capabilities, the method including the steps of - receiving the data at the receiving device, and - selecting an output method to present the data to the receiver, the selection being based on - a transmission factor affecting the transmission of the data to the receiving device, - a presentation factor affecting the ability of the receiving device to present the data, and - a perception factor affecting the ability of the receiver to perceive the data.

Description

DATA FORMAT SELECTION

This invention relates to apparatus, systems and methods for the transmission of data from a caller to a called party, particularly but not exclusively in the identification of a caller whose identity is unknown to the called party.

Call forwarding is a well known and popular service available on both fixed and mobile telecommunication networks. Essentially, a subscriber can specify that calls destined to him are to be forwarded to another subscriber's number under various conditions. For example, when a call forwarding service is activated, all the calls destined to the subscriber are forwarded to a given number. A problem arises when the subscriber does not wish to receive all calls forwarded to him but wish to have the flexibility to choose when to accept calls, to bar certain incoming call numbers, calls from certain areas, or from certain parties.

Call processing of call-forwarded and other calls is essential not only to commercial customer looking to compete in rapidly growing global markets and providing customer service, but also for individual subscribers to automatically and flexibly handle incoming calls in various situations.

Various approaches in the handling of such calls are known from e.g. WO98/05153. US7095838 describes how calls may be selectively barred to prevent incoming calls pre- identified to originate from a forwarded number. A subscriber may stipulate e.g. in his subscriber information that all, or certain calls forwarded to him are to be rejected or accepted. US6385446 sets out another approach where call forwarded calls are allowed despite restrictions when the number to be used in forwarding the call meets special pre- specified conditions.

The above known systems are based on barring or restricting calls when upon the existence of certain known numbers or known conditions. They do not however address the situation where the caller is unknown or unidentified. For example, a subscriber receives an incoming call wherein the caller's number is blocked, unfamiliar, or else is not listed in his contacts list (e.g. his telephone book). Methods which address this issue are described in e.g. EP 0837611 , where a method of prioritising calls depending on the identity of the caller is discussed. There is therefore a need to provide flexible system options for a subscriber to decide whether to accept the incoming unknown call under such circumstances.

Meanwhile, the variety of telecommunications devices and services is now vast, allowing callers and subscribers a wealth of choice in available media formats, display, playback and presentation means and functionalities, in a bewildering range of apparatus across a spectrum of access network types. In particular, many telecommunication devices now commonly include at least one other non-voice based output method. Thus, traditional voice/audio communications are now augmented or supplanted with alternatives such as text, still images, moving videos, or tactile or haptic means (e.g. vibration), to name some of the more conventional output capabilities.

A further issue thus arises where more than one communications option is available on the devices of the parties to a call: commonly the called party can choose how the data sent by the caller is output or presented to him, e.g. in terms of the media format (e.g. voice, visuals, etc.) taken by the data. It may be that any available media format may be suitable for use at a particular time, subject to the media format being supported by the called party's device. At other times, however, one or more media formats may less preferred either in being incapable of being presented to the called party entirely (e.g. where the data is of a type which cannot be sensibly communicated by the media format e.g. the caller's identity through a vibration alert mode - unless e.g. it is akin to a haptic version of Braille) or in partly (e.g. when the communications link between the parties is congested so that the data transmission to the called party is slow and/or compromised in any way).

The present invention addresses the above problems by use of a process model and incoming call handling methods to enable flexible and real-time forwarding decision- making based on subscriber preferences.

In a first aspect of the invention, there is provided a method for presenting data sent by a sender to a receiver, the receiver using a receiving device having a plurality of output method capabilities, the method including the steps of receiving the data at the receiving device, and selecting an output method to present the data to the receiver, the selection being based on a transmission factor affecting the transmission of the data to the receiving device, a presentation factor affecting the capability of the receiving device to present the data, and a perception factor affecting the ability of the receiver to perceive the data.

In the situation where one output or presentation method is preferred over another, the method of the invention addresses the decision of which to use by reference to a number of factors or criteria.

The transmission factors or criteria are those which have a bearing on the quality and speed of transmission of data such as identification data, as received by the communications device of the recipient called party, such as the access network type and the bandwidth available in the link between the parties. Thus if the sender or caller is using a sophisticated multimedia personal digital assistant and the receiver is on a mobile phone having only voice and short message system (SMS) text capabilities, this will affect the affect the output mode ultimately selected. Where the quality of the data transmission is compromised by latency and such other bandwidth issues, the output presentation method ultimately selected may bypass a streamed video method.

Factors which affect the presentation of the data to the called party are those which influence the called party's device directly - for example where it is sensed that the speaker on the recipient's device is malfunctioning; in such a case an audio output may be avoided.

The called party may be in a variety of situations at the time when the called party's identity or other information arrives at the called party's device. For example, he may be in a meeting, or in a noisy place, or driving. This may affect his ability to perceive the received data. The third factor influencing the selection of the presentation mode thus takes into account that the called party would probably wish for the data from the caller to be output visually if he were in a quiet or noisy place, or prefer to receive a text message if he is busy driving or doing something else. The presentation mode selection method of the invention can operate automatically, where the above three criteria or factors are pre-determined so that upon meeting certain conditions, a yes/no decision can be made. For example, if bandwidth availability degrades beyond a certain pre-specified level, it could be automatically decided to select a less resource-hungry method. In particular, the transmission factors could be pre-sent for automatic selection in this way.

The selection process could also be wholly or partially so that the system is set up either allowing for the user to have complete control over the selection process, or to manually override any pre-sets. For instance, certain pre-defined templates of "profiles" could be set up so that the recipient can select an appropriate profile so have a certain (set of) criteria apply where the called party is in a meeting, or already on another call, when he is commuting, and so on.

In a preferred embodiment, the selection of which output method to use also takes into account the called party's personal preferences. This allows for even further fine-tuning of the method of the invention to personalise it to the called party's needs and preferences. Such preferences could be set up so that they are taken into account automatically, or else left entirely open to the complete control of the user as when such data is received and needs to be presented to him.

The selection step is preferably carried out dynamically and in real time when the data reaches the called party's device: the processing associated with the selection could start after all the data is received, or could commence while the data is still being received (e.g. in the case of streamed data). Preferably therefore the selection will be made at the point when the data is to be presented to the called party, to take into account, "live", the factors that will affect the presentation.

In one implementation of the inventive method, the steps of receiving the data from the sender or caller and then deciding which presentation mode to use, can be repeated. This allows the called party to request that the data be re-sent e.g. where the data itself is unsatisfactory (e.g. where the data is the callers' identity, and where the called party suspects the veracity of the information provided). In a second aspect of the invention, there is provided a method for setting up a connection between a sender and a receiver, the sender being anonymous to the receiver, including the steps of the sender making a request to the receiver for the connection with the receiver, - the receiver requesting an identity of the sender, the sender consenting to divulge its identity to the receiver, and presenting the identity to the receiver as data in accordance with the method of the invention as claimed below.

In a third aspect of the invention, there is provided a method for identifying a sender prior to a connection being set up or continuing between the sender and a receiver, including the steps of determining the presence of the identity of the sender from an identity database, obtaining consent of the sender to send its identity to the receiver, - presenting the identity to the receiver as data in accordance with the method as claimed below, and setting up, ending, or continuing the call based on one or both of performance or failure of the receiving step, or an identity of the sender.

One application of the method of the invention is arises in the situation where the called party is attempting to discover and/or verify the identity of the caller prior to the set up of the call itself, and the embodiments and examples will refer mainly to this application.

In one implementation, the method of the invention includes an attempt to discover the identity of the caller initially from a database by e.g. reverse lookup techniques. Where such a match cannot be made, for example where the caller has blocked his identity such as his telephone number, he is then requested to provide such information whereupon (if necessary) a further reverse lookup or other matching process is undertaken, and the identity information sent to the called party. Upon being presented with the information, the receiver called party can choose to accept or reject call set up.

However the successful receipt and suitable presentation of data from the sender is not restricted to this application, but can serve as a precursor to a decision of take any type of subsequent action. Thus, the agreement or consent of the sender to send the data (which could be a crucial pre-condition to the use of the method) is required, and after the data has been presented to the called party, the decision can then be taken - e.g. yes/no about a particular course of action, or which of a range of options to select, and so on. An example of such a course of action may be to allow the sender access to a secure website.

Moreover, the method can be invoked at any stage, even after a connection has been established between the parties. Furthermore, the sender or caller may, part-way through the call, himself invoke the method to confirm the identity of the called party - e.g. where after one party returns to the call from attending to another call from another party. In such a case, if the party requested for identity data fails to provide satisfactory, or indeed any data at all, the requesting party can choose to end the connection, flag up his concern, and so on.

Furthermore, the method can be used to obtain from the sender a variety of data, such as a cryptographic key, a password, as well as ordinary payload data. The method could be also used in the fight spam or to identify the sender of email from unknown parties.

In further aspects of the invention, apparatus is provided to carry out the methods of the invention. In various embodiments, the selection method can be carried out by apparatus located at either parties' end (e.g. in the receiving device of the called party), or at a server located at the server side under the control of the network operator.

Embodiments of the , invention will now be described by way of example only with reference to the accompanying drawings in which:

Figure 1 depicts the system architecture showing components of the invention,

Figure 2 is a system flow chart of the incoming call handling functions, and

Figure 3 is a flow chart depicting the process of converting a video message to text.

In the present description, a "call" (also a "message", "packets" or the like) includes any telecommunication connection comprising a network or otherwise over a variety of media (e.g. copper, optical, radio and other wireless means), including voice, data, and so on. "Callers" or "senders" in this description generally refer to the anonymous party in the call, whose identity is unknown to the "called party" (also "callee", "subscriber" or "customer", "receiver" and the like), although the caller may also, in the same transaction, use the methods and apparatus of the invention to verify the other party's identity in a mutual or unilateral request for the same. Typically the "caller" will have made the call and seeks a connection with the "called party" who is unsure whether to receive the call. "Presentation" includes the display of visual data and the playback of audio data.

Figure 1 is a block diagram of the main components of an unknown call handling system according to the invention. The system (10) comprises a client side, here consisting of two calling devices or systems, one for the caller (12) and for other for the called party or callee (14). The unknown caller is attempting to contact the called party, and before connection is made, the system diverts to a preliminary routine to identify the caller to the called party the decision to set up the call is made. In this embodiment, the components which carry out the identification or verification process sit on the server side (20). However the skilled person would appreciate that one or more components could alternatively be arranged to be co-located with the callee or called party's device (such as the subscriber's contact lists (24) which could sit in the onboard memory of the device or on the SIM card in a mobile phone).

In a typical scenario, if a telephone number of an incoming call is received at the called party's end, this is sent to the incoming call number analysis (ICNA) component (22) for analysis. This component compares such incoming call numbers with the callee's contact list from subscriber's contact lists (24). The ICNA module determines if the identity of the caller making the call needs to be discovered or verified: if there is no match found for the telephone number in the subscriber's own phone list (24), or if the number is absent or blocked (i.e. a negative comparison result) then the incoming call is deemed to require verification. The ICNA component will then search the global subscribers' database and/or a distributed global database to get information about the caller and to trigger the call verification handling (CVH) system component (28).

The main function of the CVH module is to send a request to the unknown caller for consent or approval to identify himself to the called party or callee. This process is initiated by a message received from the ICN module. The CVH component sends e.g. a voice or other request to the caller and awaits the caller's response. Upon receiving a positive response containing the requested data from the caller, the CVH component can be arranged to route the information contained in e.g. a voice response by the caller to the callee and then to presenting it to the callee by e.g. playing the response back as an audio file through the speaker of the callee's communication device. (Of course, if the caller does not provide the requested information, then the process is aborted.)

In the main, the information requested of the caller can comprise identification information such as the caller's name, telephone number, his location, the company the caller represents, and the like. Other information could also be included, e.g. a commercial "cold caller" could describe the services or products he can offer to the called party. If the caller agrees to send such data to the callee, the ICNA analysis component then sends the caller data to the receiver.

Upon receiving the information, the callee can then decide if he agrees or consents to the request of the caller for connection with the caller, e.g. on the basis that he recognises the calling party, or is otherwise wishes to make the connection. If he does, then the CVH component calls the call session handlings (CSH) module (32) to set up the call. On the other hand, if the callee does not wish for the connection to the caller to be made, then no call is set up.

The primary function of the call session handling (CSH) module (32) is to set up the call session between the caller and callee after the called party agrees to the creation of the connection.

The verification methods analysis (VMA) module (30) carries out the task of discovering verification methods available in the particular session. "Verification" in this description includes the process of discovering - as well as checking and confirming - the identity of the caller. The process is described more fully in the algorithm of Figure 2.

In an embodiment of the invention, subscribers' contact list or lists (SCL) (24) are kept centrally or in a distributed manner on the server side (20). These contain one or more subscribers' contact lists, and represent the parties known to a subscriber. The entries therein are preferably kept updated and synchronised e.g. on a regular basis with the local contact list ("phone book") stored in the device used by the subscriber(s). In the invention, the SCL is referred to e.g. to determine when the caller first requests connection to the callee, if the caller is known to the called party. Other uses include the situation where the caller provides only one piece of information (e.g. his telephone number), so that by looking up the SCL, the system can look up the caller's name (and any other information associated with that number) for use. The skilled person would appreciate that the SCL database is merely a preferred feature and that in an alternative implementation, it is possible for the system to refer to entries in the phone book local to the called party's device. For that matter, it is not crucial to the method of the invention to perform the step of looking up the SCL to initially determine if the caller is known to the callee although doing so is an initial useful data filter.

The global subscribers' database (GSD) (26) is a centralised or distributed database also located at the server end that provides information about phone subscribers' location, registered name and contact number. The entries can include information about customers across different phone network operators. In this case, operators or companies hosting the system of the invention would generally agree with other operators to obtain or share subscribers' information across different networks.

On the client side are located the communications systems of the parties to the session: the caller (12) and the called party or callee (14). The caller in this case attempts to connect to the callee but as the caller identity is unknown to the called party, the method of the invention is invoked to provide the information to enable the called party to make the decision of whether to consent to the connection and thus for the system to proceed to call set up. The skilled person would appreciate that this method can be invoked even after the call has been set up, as a precondition to e.g. continuing the call, and/or that the caller can also request verification of the callee's identity at any point before or during the call.

The communications systems of the present implementation discussed are conventional telephones which can be physically or wirelessly linked to a network operator system allowing the parties to make and receive telephone calls. In this embodiment, no additional system modules are required to be installed in the telephones on the client side. However, it would be clear that some or even all the equipment and modules shown on the server side (20) can be incorporated into the client-side apparatus or within the premises housing the client-side apparatus.

Although the present discussion concerns a telephone-based system with the aim of eventually agreeing to (or rejecting) call set up, the inventive concept also includes within its scope other communications apparatus such as a two computers, the first of which may be seeking to access a secure second computer such as may be the case in a packet-based communication where the question is the identification and verification by use of a user identity and/or password. Such other applications would be apparent to the skilled person.

Turning now to Figure 2, this shows the flow chart of the logical processing, decision making points and the sequential flow of the system by the executive components of the system of the invention, specifically by the ICNA (22), CVH (28), VMA (30) and CSH (32) modules discussed above.

In brief, a caller initiates a request for a connection to the callee. The system receives the call and the ICNA module determines if the caller (from what information is available from the call itself) is already known to the called party. This is done by referring to the SCL (24) and/or the callee's own address and phone books, which may be located with the callee's device on the client side. If the caller provides no or insufficient information about himself in the call allow permit identification, or such identity is otherwise absent from the SCL and and/or the callee's own address and phone books, the ICNA component searches the GSD (26).

If the needed information is located, this is then sent to the called party for a decision to be taken whether the process to proceed to set up the call. If the GSD fails to provide the required information, or if the callee requests verification of the information it received, then the verification process starts.

In telecommunications networks, network operators maintain information about the location of their mobile subscribers. In some cases, subscriber information may be shared between network operators. For example, in GSM (mobile) networks, this location information is distributed between the home location register (HLR) and visitor location registers (VLR) and directly connected to mobile services switching centres. The HLR is located in the home network of the mobile subscriber, and contains the permanent subscriber information and the location information of the mobile subscriber with an accuracy of one VLR area. The VLR area is typically similar to the area served by one mobile services switching centre. The VLR of the visited mobile services switching centre responsible for the area the subscriber is currently visiting, contains more exact and current information about the subscriber's location. In a typical VoIP implementation, VoIP users' location information is identified through the static or dynamic IP address assigned by their ISP. Each VoIP subscriber's device i.e. digital private branch exchanges or IP phone terminal is bound with an E.164 telephone number. In a SIP-based implementation when a VoIP user dials an E.164 number, it is translated into a URI at the user terminal using ENUM for instance. The ISP uses the URI to locate the called party through DNS lookup. Using the resolved IP address the caller establishes a communication channel with the intended callee. Alternative implementations allow the return of naming authority pointer resource (NAPTR) records from the DNS lookup. NAPTR records specify various mechanisms to reach the intended party according the called party's preference such as using email, instant messaging or by VoIP. The nature of the Internet is such that the actual geolocation of a VoIP user is difficult to determine unless the ISP is able to distribute its IP address pools according to a specific geographical map. To increase the accuracy to locate a VoIP user's location, an ISP could use an automatic mechanism to draw physical location information such as street address or the like from the VoIP user every time they log in to the ISP network.

In a public switched telephone network (PSTN) system, location information is registered with the operator directory server. The calling line identification presentation (CLIP) reveals the location of the caller to the extent of a numbering plan area (NPA). The NPA, also known as an "Area Code", is a defined geographic area identified by a unique code used for the respective numbering plan.

In the invention, the system is set up to check the access network and the output or presentation capabilities of the end devices used by caller and callee in a specific case, communication. After this is determined, it can then be decided if multimedia (i.e. using text, still picture, video) authentication mechanism are to be deployed. There are various ways to carry out the discovery process, depending on e.g. the protocol used by the device to transmit communication message, as described below.

The network operator can check the caller's and callee's access network type in order to determine if the communication channels have the capacity and the bandwidth to support a multimedia-based transmission: The end device's functionalities such as checking mechanisms, are dependent on the access network used. The checking of network access type uses by the caller is fairly straightforward: it can be determined by analysing the caller's point of termination, while the access network type of the callee can be deduced from the phone number format. If one of these access networks is e.g. POTS, it may be unsuitable as being unable to support a transmission of a multimedia application.

In the case of GSM or UMTS based devices, one known method to check the parties' end devices' functionality is to refer to the international mobile equipment identity (IMEI) number of said devices. The IMEI number comprises fours fields, which includes information that can be used to uniquely identify the model of the phone/device being used. The SNR which uniquely identifies a particular phone can be used as well. From such information, the network operator can determine the functionalities (GPRS-enabled, 3G-capable, MMS-enabled or SMS-enabled) supported by the devices used by the parties.

In the case of CDMA phones, mobile equipment identifiers (MEIDs) can be used. These are similar to IMEIs in that they that also contain information which can be used to determine the model of a phone thereby enabling identification of its supported features such as its output capabilities. For VoIP calls, use of a signalling protocol such as SIP is typically needed to set up additional non-voice based channels. The capability of the device (such as whether it is codec/media supported) can be embedded in the SIP message header, which might take the following form:

INVITE sip:411@salzburg.at;user=phone SIP/2.0 Via: SIP/2.0/UDP abc . edu: 5060 ;branch=z9hG4bKld32hr4Max-Forwards : 70

To : <sip : 411@salzburg . at ;user=phone> From: XYZ <sip :xyz@abc . edu>; tag=817234

Call-ID: 12-45-A5-46-X7@abc.edu

CSeq: 1 INVITE

Subject: Train Timetables

Contact: sip:xyz@abc .edu Content-Type: application/sdp

Content-Length: 151 v=0 o=xyz 2890842326 2890844532 IN IP4 abc.edu s=Phone Call C=IN IP4 50.61.72.83 b=10 where: v= (protocol version) o= (owner/creator and session identifier). b=^* (bandwidth information) c=* (connection information - optional if included at session-level) From the interactions and exchanges of SIP messages, the network operator can deduce the capabilities of the devices involved and thus proposing the most viable options.

Similarly, a device using the HTTP protocol can have device capability information embedded in its HTTP message header.

Thus, the data sent from the caller to the callee via the system of the invention will be presented to the caller using a media format (e.g. audio, text, still images, video or the like) which the called party's device is capable of supporting; in a simple example, the data will not be output to an audio-only landline device in a multimedia format.

In one example, a video call originating from a caller may be converted to text for presentation on the called party's device. As depicted in the flow chart of Figure 3, the conversion process involves at least the following:

1. Demodulation: The analogue signal is demodulated to obtain the original baseband signal. Various demodulation techniques are well known, and the method selected will depend on the parameters of the base-band signal as transmitted in the carrier signal. This task can be carried out by modem.

2. Decompression: The signal is decompressed with e.g. an AMR-WB decompressor. As with any communication, compressed data communication only works when both the sender and receiver of the information understand the encoding scheme. For example, the text to which the signal is converted will make sense only if the receiver understands that it is intended to be interpreted as characters representing e.g. the English language. Similarly, compressed data can only be understood if the decoding method is known by the receiver. Video file formats capable of compression would have files extensions such as .avi, .mp3, and .wav.

3. Speech recognition: Automatic speech recognition in particular, involves the conversion of an audio speech signal to a sequence of words in the form of digital data, by means of an appropriate algorithm implemented as a computer program. This is related to voice recognition or speaker recognition, which attempts to identify the person speaking, as opposed to what is being said. Even where the devices at each end are capable of supporting e.g. streaming video, other factors which affect the transmission of the data such as bandwidth may affect the decision to use one media format over another. Furthermore there could be other factors which have an impact on the callee's choice of how to have the information presented to him even after the data has been successfully transmitted to his device. For example, the ringer on his phone may be broken, or the screen on a PDA not functionally fully. The device may be used in an area where there is a strong magnetic current or in extremely hot or humid conditions affecting the capability of the device to output the data in a particular presentation mode.

Owing to the above factors which affect the transmission of the data to the callee's device and the ability of the device to output the data using a particular format, a selection is performed by the system of the invention to reduce the presentation method options open to the callee. Preferably, these selection/reduction steps are performed automatically so that the process is transparent to the callee. It would however be possible to give the callee partial or full control over the selection process at these stages, by providing the necessary information (e.g. bandwidth capacity available, etc.) to the callee and providing a GUI allowing for interfacing with the device to make the selection of presentation method.

Furthermore, the called party will, at the time of receiving the data about the caller's identity or other data, be in a variety of situations and circumstances. He may be sitting in a quiet room and entirely free to select any output mode to have the data presented to him. Often however, he will be constrained in some manner which will make one or some presentation modes more suitable other others. For example, he may be out in a noisy, public area, in which case a visual presentation form may be more appropriate. He may be in a meeting or driving so that a text message would be the preferred output method.

Aside from such external physical or environmental factors, the callee may also have user-specific, personal preferences. For example, he may be hard of hearing. Or he may want to use "free inclusive voice minutes" in a monthly mobile phone contract, which do not include the receipt of text messages for which he has to pay.

After it has been determined what presentation or output capabilities are available on the parties' calling devices - in particular the called party's device, the called party then selects one of a number of verification methods available to him, which decision is based on the factors which affect his ability to perceive (by hearing, seeing, and the like) at the time the caller's identity is to be presented to him. As noted above, such perception ability may be hampered by environmental conditions. This selection can be made manually by the callee making a selection on a GUI on his device for this purpose. Alternatively, the device may be arranged to automatically sense the environmental or physical conditions (e.g. inclusion of a GPS to sense movement, a light meter to determine light levels, a microphone to detect sound levels and to recognise crowd noises indicating a lack of privacy, etc.). The selection may then be made automatically for the callee based on pre- specified criteria, which may be factory-set, or set or modifiable by the callee.

Specified criteria may also be set or made modifiable in the same way for the callee's personal preferences.

The following is pseudo Java code for an example algorithm to determine available verification methods by selecting a suitable presentation method:

findVerification (ml,m2 ,n, al,a2) // ml ,m2=device models used by caller and called party // relocation of caller

// al,a2= access networks of caller and called party {

String X; //verification method name (e.g. audio, text, video and image)

String Z; //location identification name String M; //temporary device model String A; //temporary access network Integer B; //bandwidth threshold value ArrayList result [X]; //default result of available verification methods - can be

// updated via retrieving a user writable setting file.

ArrayList T[X, B]; //a list storing threshold of optimum bandwidth level

//associated with the verification methods ArrayList D[M, X] ; //a list of device models supporting verification method

ArrayList L[X, Z]; //a list of locations not suitable for verification method

//(e.g. library, cinema) result [X]; //a list storing the results of this algorithm

//i.e. the available verification methods callee[X]; //temporary list storing verification methods caller[X]; //temporary list storing verification methods for loop (y=0,y<2,y++) {

//lst loop to get verification methods suitable for caller //2nd loop to get verification methods suitable for caller if (y == 0) { M = ml; A = al; else { M = m2;

A = a2;

S = O; fail = false; j = 0; while !D[ ] .empty ( ) { if D[j , 0] .matchString(M) { //to get device model and supported verification method k = 0; while ( !T[] .empty () && k>=0) {

// to check if the access network bandwidth within

// the optimum threshold if T[k,0] .matchString(D[j,l] ) { if A >= T[k,l] { q = 0; while ( !L[] .empty () && q>=0) {

// to filter verification methods

// based on location if

L[q, 0] .matchString(D[j , 1] ) { fail=true; } ^g = ^~1; else q++; } if flag == true {

// do nothing } else { if y==o { caller[s] = D[j, I]; } if y==l { callee[s] = D[j, I]; } s++; } flag = false; } else { // k++;do nothing} k = -1; } else { k++; } }

} } // to get intersection results of available verification methods // between caller and callee if (! caller [] .empty () && ! callee [] .empty () ) { s = 0; x = caller [] .size; y = callee []. size; for loop (j=0, j<y, j++) { for loop (i=0, i<x, i++) { if (caller [i] .matchString (callee [j ])) { result[s] = caller[i] ; S++; i = x; } else i++; } } } else { // no verification method is available} return result [s] ;

}

Once the selection of the presentation mode is made, the caller's identity is output to the callee, which may take the form of a recorded voice from the caller (e.g. stating his name, company he is representing, contact details and purpose of the call), or a text message, a still or moving image or the like containing such information as would allow the callee to make the decision whether to agree to connect the call. If the callee responds e.g. by voice, this may be sent to the caller. Of course, the called party may responds in a variety of ways, e.g. by depressing a button on his device, or the like. If there is no response, the system may take this as an indication of rejection of the caller's connection request, and terminate the preliminary verification process and the call with the caller. If the response contains an indication that the callee will accept the call, the process moves to the call set up stage. The response may alternatively indicate that the callee wishes to repeat the verification process where for example he is unsure about the information provided by the caller.

The methods and configurations as described above and in the drawings are for ease of description only and not meant to restrict the apparatus or methods to a particular arrangement or process in use. It will be apparent to the skilled person that various sequences and permutations on the methods and apparatus described are possible within the scope of this invention as disclosed. The methods and apparatus described herein may also be used for a variety of data, not just caller identification. Also, the method of the invention may be used as a precursor to a variety of further events e.g. entry into a secure area, provision of confidential information, determining if a user will accept delivery of email which may or may not be spam and so on, i.e. not only or exclusively for a call set up process.

Claims

Claims:

1. A method for presenting data sent by a sender to a receiver, the receiver using a receiving device having a plurality of output method capabilities, the method including the steps of receiving the data at the receiving device, and selecting an output method to present the data to the receiver, the selection being based on a transmission factor affecting the transmission of the data to the receiving device, a presentation factor affecting the capability of the receiving device to present the data, and a perception factor affecting the ability of the receiver to perceive the data.

2. A method according to claim 1 wherein the selecting step commences upon receiving the data at the receiving device.

3. A method according to claim 1 or claim 2 wherein the selecting step is further based on a preference of the user.

4. A method according to any preceding claim wherein the selecting step comprises manually selecting one or more of the transmission factor, the presentation factor or the perception factor.

5. A method according to any one of claims 1 to 3 wherein the selecting step comprises automatically selecting one or more of the transmission factor, the presentation factor or the perception factor.

6. A method according to any one of claims 2 to 5 wherein the selecting step comprises automatically or manually selecting the user preference.

7. A method according to any preceding claim wherein the plurality of output methods capabilities comprises capabilities to output one or more of audio, static or dynamic visual, or haptic data.

8. A method according to any preceding claim wherein the transmission factor of the selecting step comprises one or both of access network type or available bandwidth during the receiving step.

9. A method according to any preceding claim wherein the presentation factor of the selecting step comprises one or more of pressure, magnetic or other physical interference with the capability of the receiving device to present the data.

10. A method according to any preceding claim wherein the perception factor of the selecting step comprises one or more of physical location, light levels, noise levels, crowds, or movement of the receiver affecting the ability of the of the receiver to perceive the data if presented by a particular output method.

11. A method according to any preceding claim further including the steps of the receiver requesting a re-sending of the data, and an iteration of all or some of the steps of the method.

12. A method according to any preceding claim wherein the data presented to the receiver comprises an identity of the sender.

13. A method for deciding if an action should be taken based on one or both of the data presented to the receiver in accordance with the steps of the method of any preceding claim, or on performance of the receiving step.

14. A method according to claim 13 wherein the action comprises deciding whether to set up a connection between the sender and the receiver based on one or both of performance of the receiving step, or an identity of the sender.

15. A method for setting up a connection between a sender and a receiver, the sender being anonymous to the receiver, including the steps of the sender making a request to the receiver for the connection with the receiver, the receiver requesting an identity of the sender, the sender consenting to divulge its identity to the receiver, and presenting the identity to the receiver as data in accordance with the method of any one of claims 1 to 12.

16. A method for identifying a sender prior to a connection being set up or continuing between the sender and a receiver, including the steps of determining the presence of the identity of the sender from an identity database, - obtaining consent of the sender to send its identity to the receiver, presenting the identity to the receiver as data in accordance with the method of any one of claims 1 to 12, and setting up, ending, or continuing the call based on one or both of performance or failure of the receiving step, or an identity of the sender.

17. Apparatus arranged for presenting data sent by a sender to a receiver, the receiver using a receiving device having a plurality of output method capabilities, including receiving means for receiving the data at the receiving device, and selecting means for selecting an output method to present the data to the receiver, the selection being based on a transmission factor affecting the transmission of the data to the receiving device, a presentation factor affecting the ability of the receiving device to present the data, and - a perception factor affecting the ability of the receiver to perceive the data.

18. Apparatus according to claim 17 wherein the selecting means is arranged to further base the selection on a preference of the receiver.

19. Apparatus according to claim 17 or claim 18 wherein the selecting means is co- located with the receiving device.

20. Apparatus arranged for setting up a connection between a sender and a receiver, the sender being anonymous to the receiver, including - means for the sender to make a request to the receiver for the connection with the receiver, means for the receiver to request an identity of the sender, means for the sender to consent to divulge its identity to the receiver, and means for presenting the identity to the receiver as data in accordance with the method of any one of claims 1 to 12.

21. Apparatus for identifying a sender prior to a connection being set up or continuing between the sender and a receiver, including the steps of means for determining the presence of the identity of the sender from an identity database, means for obtaining consent of the sender to send its identity to the receiver, means for presenting the identity to the receiver as data in accordance with the method of any one of claims 1 to 12, and means for setting up, ending, or continuing the call based on performance of the receiving step, or an identity of the sender, based on one or both of performance or failure of the receiving step, or an identity of the sender.

22. Apparatus according to claim 21 wherein the identity database comprise one or both of a subscriber's contact list or a global subscribers' database.