GB2488517A

GB2488517A - Simultaneous voice and data communication between mobile telephones

Info

Publication number: GB2488517A
Application number: GB1102646.5A
Authority: GB
Inventors: Shay Moshe Magzimof
Original assignee: INNOBELL LLC
Current assignee: INNOBELL LLC
Priority date: 2011-02-15
Filing date: 2011-02-15
Publication date: 2012-09-05
Anticipated expiration: 2031-02-15
Also published as: GB201102646D0; GB2488517B

Abstract

A bridging module for a mobile telephone 306, the bridging module (112, Figure 1) comprising: an actuator (202, Figure 2) associated with a telephony module (108, Figure 1) of the mobile telephone and configured, in response to a call initiation event (206, Figure 2) of the telephony module, to detect a telephone network identifier, e.g. telephone number, of a different mobile telephone 308 participating in the call; and a communicator (204, Figure 2) being triggerable by said actuator upon initiation of the call, and being configured to interface with a data network connection module (110, Figure 1) of the mobile telephone for communicating with the different mobile telephone using a central server 310 maintaining a database of corresponding telephone network 302 and data network 304 identifiers, e.g. IP addresses. The method allows simultaneous voice 302 and data 304 connections to be established between a calling 306 and called party 308 upon detection (208, Figure 2) of a call being started so that data can be exchanged whilst the call is on-going over a separate data channel. Data exchanged may include location information, money transfer or game session information as examples. The central server may be an Extensible Messaging and Presence Protocol (XMPP) server wherein the communicator comprises an XMPP client for communicating with the different mobile telephone directly or indirectly through the central XMPP server. The XMPP client may comprise a Smack client library.

Description

t V.' INTELLECTUAL ..* PROPERTY OFFICE Application No. GB 1102646.5 RT1VI Date:15 June 2011 The following terms are registered trademarks and should be read as such wherever they occur in this document: Bluetooth Symbian Maemo Meego Android Blackberry Windows Paypal Linux Java Intellectual Properly Office is an operating name of the Patent Office www.ipo.gov.uk

DATA COMMUNICATIONS BETWEEN MOBILE

TELEPHONES ENGAGED IN A TELEPHONE CALL

FIELD OF THE INVENTION

The invention relates to a system, device and method for data communications between mobile phones, simultaneously with a telephone call.

BACKGROUND OF THE INVENTION

Mobile telephones (sometimes referred to as "cellular telephones" or "handheld telephones") have seen great improvement in recent years. Such advanced telephones, often referred to as "smart phones", offer a far more progressive computing ability and connectivity compared to basic mobile telephones. They usually utilize powerful processors, abundant memory, larger screens, and generously-featured operating systems.

Aside from a telephony module, which wirelessly connects to the telephone network in order to make and receive calls, many smart phones include additional communication modules, examples of which include BlueTooth radio modules for short-range communications, infrared modules for short-range, line-of-sight communications, NFC (Near Field Communication) modules for high-frequency, proximity communications, and data network modules (or "modems") for exchange of data -which is often used for accessing the Internet and its utilizing its many features.

Despite the multiplicity of different communication capabilities of a typical smart phone, there is still a certain usability gap arising out of this very quality. Different communication capabilities usually require distinct protocols and user identification methods, and, therefore, users who wish to simultaneously communicate with one another over multiple communication types may encounter certain difficulties.

U.S. Patent No. 7,773,550 to Lin et al. discloses a technique for a direct data transfer session, including for multimedia content, between mobile devices without the need for using a separate multimedia server to store multimedia content. Direct data transfer sessions between mobile devices are established by transmitting necessary address information through page-based messaging services that utilize the underlying digital mobile network databases and services to resolve the identification and location of the mobile devices.

U.S. Patent Application Publication No. 2010/0029302Al to Lee et al. discloses that during an ongoing wireless telephone call communication session between a pair of mobile devices, a local device responds to its user's activation of a virtual or actual button or key, or its user's verbal command, by automatically sending an over the air message (e.g., a SMS or text message or other network communication message) to the remote device. The message requests location information of the remote device. Upon obtaining location information from the remote device, a location of the remote device is automatically displayed on the local device.

European Published Patent Application No. 1.940.096A1 to Rodellar discloses a method for transferring data between a first terminal device and at least one second terminal device, whereby the first terminal device and the second terminal device or devices connect to and register with a central unit, the connection data of the first terminal device and the second terminal device are sent to the central unit, the connection data of the terminal device being stored in a lookup table of the central unit in a way assigned to the corresponding terminal device, a first transfer request comprising at least a specification of data to be transferred and an identification of the destination is created and sent to the central unit by the first terminal device, at least one corresponding second terminal device is identified based on the received identification of the destination, and the appropriate connection data of the second terminal device are retrieved from the lookup table of the central unit, a second transfer request is created based on the first transfer request and the retrieved connection data of the second terminal device, and is sent to the second terminal device by the central unit, and the transfer of data is accepted by the second terminal device, the data being transferred to the second terminal device.

U.S. Patent Application Publication No. 2005/0075l7lA1 to Fujiwara discloses a cellular telephone having a program for interlocking the telephone function with a prize service. A game is started by a reception by the cellular telephone or calling from the cellular telephone. When the connection of the cellular telephone for the reception or the calling is released or when a predetermined period of time has elapsed, a game result is displayed on the display means showing whether a particular profit is given to the user of the cellular telephone.

Still, there is a need in the art for ways to bridge, or at least mitigate, the usability gap described above, which may be seen as the outcome of the rich and versatile communication capabilities of the typical smart phone.

SUMMARY OF THE INVENTION

There is provided, according to an embodiment, a bridging module for a mobile telephone, the bridging module comprising: an actuator associated with a telephony module of the mobile telephone and configured, in response to a call initiation event of the telephony module, to detect a telephone network identifier of a different mobile telephone participating in the call; and a communicator being triggerable by said actuator upon initiation of the call, and being configured to interface with a data network connection module of the mobile telephone for communicating with the different mobile telephone using a central server maintaining a database of corresponding telephone network and data network identifiers.

In some embodiments, the central server is configured to relay communications between mobile telephones based on the data network identifiers of the mobile telephones; and said communicator is fi.irther configured to communicate with the different mobile telephone through the central server.

In some embodiments, the central server is an XMPP (Extensible Messaging and Presence Protocol) server, and wherein said communicator comprises an XMPP client for communicating with the different mobile telephone indirectly, through the central XMPP server.

Tn some embodiments, said XMPP client comprises a Smack client library.

In some embodiments, said communicator is configured to interface with an operating system of the mobile telephone for discovering a data network identifier of the mobile telephone, and to transmit the data network identifier to the central server, for updating the database.

Tn some embodiments, said actuator comprises a synchronization manager configured to interface with the central server to detect address book entries in said mobile telephone which appear in the database of the central server.

In some embodiments, the bridging module further comprises a call event listener configured to monitor the telephony module of the mobile telephone, to detect the call initiation event.

In some embodiments, said communicator is further configured, prior to communicating with the different mobile telephone, to check with the central server the availability of the different mobile telephone to communicate.

In some embodiments, said communicator is further configured to maintain a connection to the central server by periodically reconnecting to the central server.

In some embodiments, said communicator is further configured to query the central server for a data network address of the different mobile telephone, based on the telephone network of the different mobile telephone, and to communicate with the different mobile telephone directly, based on the data network address.

There is provided, according to an embodiment, a method for data communication between two or more mobile telephones being engaged in a telephone call, the method comprising, in a first one of the mobile telephones: automatically detecting, upon initiation of a telephone call, a telephone network identifier of a different at least one of the mobile telephones engaged in the telephone call; over a data network connection module of the first one of the mobile telephones, transmitting the detected telephone network identifier to a central server maintaining a database of corresponding telephone network and data network identifiers; and over the data network connection module of the first one of the mobile telephones, communicating with the different at least one of the mobile telephones, using the central server.

In some embodiments, the central server is of a type configured to relay communications between mobile telephones based on the data network identifiers of the mobile telephones, and wherein the communicating with the different at least one of the mobile telephones using the central server comprises relaying communications through the central server.

In some embodiments, the relaying of communications through the central server comprises transmitting XMPP instant messages from the first one of the mobile telephones to the central server, and relaying the XMPP instant messages from the central server to the different at least one of the mobile telephones.

In some embodiments, the method further comprises interfacing with an operating system of the first one of the mobile telephones for discovering a data network identifier of the first one of the mobile telephones, and transmitting the data network identifier to the central server for updating the database.

In some embodiments, the method further comprises interfacing with the central server and detecting address book entries in the first one of the mobile telephones which appear in the database of the central server.

In some embodiments, the method further comprises monitoring the telephony module of the first one of the mobile telephones, to detect the initiation of the telephone call.

In some embodiments, the method further comprises checking with the central server the availability of the second one of the mobile telephones to communicate over the data network.

In some embodiments, the method further comprises maintaining a connection to the central server by periodically reconnecting to the central server.

In some embodiments, the communicating with the different at least one of the mobile telephones using the central server comprises: querying the central server for a data network address of the different at least one of the mobile telephones, based on the telephone network of the different at least one of the mobile telephones; and communicating with the different at least one of the mobile telephones directly, based on the data network address.

BRIEF DESCRIPTION OF THE FIGURES

Exemplary embodiments are illustrated in referenced figures. Dimensions of components and features shown in the figures are generally chosen for convenience and clarity of presentation and are not necessarily shown to scale. The figures are listed below.

Fig. 1 shows a block diagram of a mobile telephone; Fig. 2 shows a block diagram of a bridging module included in the mobile telephone of Fig. 1; Fig. 3 shows a network diagram in which parties to a telephone call seamlessly communicate also over a data network, concurrently with the call; Fig. 4A shows a server-side method for data communication between two or more mobile telephones being engaged in a telephone call; Fig. 4B shows a client-side method for data communication between two or more mobile telephones being engaged in a telephone call; Figs. 5A-D show exemplary graphical user interfaces; and Fig. 6 shows a network diagram of an exemplary implementation.

DETAILED DESCRIPTION

The invention relates to a communication system, device and method which enable parties to a telephone call to communicate also over a data network (such as the Internet), concurrently with the call. The communication over the data network may include, for example, transmission of various files, photos, text, joint web browsing, multi-player gaming, social network interaction and/or the like.

Advantageously, the system causes the mobile telephone devices of the parties, upon initiation of a call, to effortlessly and seamlessly establish a data network connection between them. This may be achieved, in one example, by maintaining, in a central server, a database with records of corresponding telephone network identifiers (such as telephone numbers) arid data network identifiers (such as IP addresses) of subscribed mobile telephones, and relaying communications between the mobile telephone devices of the parties through the server, optionally in real-time.

In a second example, a central server may include a similar database, and inform the mobile telephones of the parties about data network identifier(s) -either periodically or in response to a request made upon call initiation, so that the parties my communicate directly, using each other's data network identifiers.

At the client side, namely -in each of the mobile telephones, a software module may continuously monitor the telephony module of the mobile telephone. Upon detection of a call event, the software module may identi& the other party or parties to the call, based, for example, on their phone numbers, and correlate this identification data with the database records fetched from the central server. Then, when at least one of the mobile telephones participating in the call is aware of its counterpart's data network address, data communication may be established between the parties.

Alternatively, the telephony module may itself be configured to perform the correlation and trigger the data communication, without the need of an external software module to do the monitoring.

The terms "telephone network", "telephony network", "cellular network", "cellular telephony" etc., as referred to herein, may relate to a wireless radio network, analog or digital, which provides telephone services, usually to mobile devices but also to fixed sites. The services may include voice and/or video calling. The network may include, in its physical layer, multiple base stations (also "antennas") providing the necessary geographical coverage of the network. Commonly, a certain geographical area is covered by multiple networks, each operated by a different cellular carrier (or "operator"). Accordingly, a call between two users belonging to different carriers may utilize two different networks. For reasons of simplicity, therefore, the use of the term "network", in singular form, refers also to a scenario where the telephone network used to facilitate the call is actually two or more networks.

The term "data network", as referred to herein, may relate to a wireless data transmission service which is provided, similar to the telephone network, using base stations. The data network is usually linked to a global network such as the Internet, so that the data network subscribes may utilize this network for Internet access.

Therefore, for simplicity of discussion, usage of the term "data network" is intended to cover also that global network. Commonly, cellular carriers provide their subscribers with both telephone network services and data network services. These services, or networks, may be physically separate (such as using discrete base stations, protocols andlor standards) or, in some technologies, may be essentially a single network, capable of providing both telephony and data services, using the same protocols and/or standards. Furthermore, the mobile telephone may be equipped with a wireless LAN (Local Area Network) module, sometimes referred to as a WiFi (Wireless Fidelity) module, which enables the phone to access the global network (such as the Internet) using a wireless access point located in its proximity. Accordingly, the term "data network" refers to the service of data transfer (commonly, Internet access) -whether provided by the cellular carrier or through a wireless access point, while the term "telephone network" refers to the service of telephone calling -whether these services are provided using separate or joint physical networks.

Reference is now made to Fig. 1, which shows a block diagram of a mobile telephone (hereinafter "phone") 100, in accordance with an embodiment. Phone 100 may be regarded as a representative phone operable according to the present disclosure. The enablement of parties to a telephone call to seamlessly communicate also over the data network, concurrently with the call, may require that the phones of the parties include components discussed below, in connection with phone 100.

Phone 100 may include a processor 102, a random access memory (RAM) 104, a non-volatile memory 106, a telephony module 108, a data network connection module (hereinafter "modem") 110, and, advantageously, a bridging module 112 enabling parties to a telephone call to communicate, at least partially simultaneously with the call, over the data network. Phone 100 may further include one or more additional devices 114 (not shown in detail), such as audio and/or video circuitry, a display, radio frequency (RF) circuitry, a global positioning system (GPS) device, a battery etc. Telephony module 108 may include a radio transceiver operative according to one or more cellular telephony standards and/or technologies, such as GSM, CDMA, iDEN or the like. The radio transceiver may be controlled by a software module embedded in the transceiver's circuitry and/or included in the operating system of phone 100, for the purpose of initiating and receiving cellular telephone calls.

Modem 110 may be a wireless broadband modem providing data communications, such as Internet access. Modem 100 may operate according to one or more mobile broadband standards and/or technologies, such as GPRS, EVDO, EDGE, HSPDA, UMTS, LTE, Mobile WiMax or others. An alternate meaning of the term "modem", also intended herein, is a WLAN module or a similar module providing global network access through a local, essentially short-range wireless access point. However, in both meanings of this term, it is intended that the device -whether a wireless broadband modem or a WLAN module -provides access to the global network, such as the Internet. The reason for the dual usage of the term "modem" in this description results from the fact that many mobile telephones include both a wireless broadband modem and a WLAN module; the OS of the telephones usually switches between these devices automatically, according to their signal strength and/or other criteria. In some embodiments, it is of no relevance which device is chosen by the OS to provide the global network connectivity, as long as this connectivity is achieved.

Optionally, the capabilities of telephony module 108 and modem 110 are encapsulated in essentially a single communication device, enabling both telephony and data communications. The telephony and data communications, in this case, may utilize the same frequency range, and optionally enable simultaneous usage. In the LTE and Mobile WiMax standards, for example, a single modem may be used for virtually all the network communication needs of the phone, such as voice calls, video calls and data communications.

Bridging module 112, which enables parties to a telephone call to seamlessly communicate also over the data network, may be a software module saved in non-volatile memory 106 and executed by processor 102, which loads it onto RAM 104 at least for the duration of its operation. Bridging module 102 may run as an add-on module in or be an integral part of an operating system (OS) of phone 100, which may be, for example, Nokia's Symbian, Maemo or Meego, Google's Android, Apple's iOS, RIM's BlackBerry OS, Microsoft's Windows Phone, Palm/HP's WebOS, Samsung's Bada or any other mobile operating system.

Reference is now made to Fig. 2, which shows bridging module 112 in more detail. Bridging module 112 may include an actuator 202 and a communicator 204, embodied as separate or joint processes, programming language functions, programming language code lines or the like.

Actuator 202, in response to a call initiation event 206 of telephony module 108 (Fig. I), which indicates either an incoming or an outgoing call, may detect a telephone network identifier of another mobile phone or a plurality of other mobile phones participating in the call. In the case of an outgoing call, actuator 202 may fetch the dialed identifier (which is optionally a telephone number) from telephony module 108, while with an incoming call, the actuator may detect the identifier using a "caller ID" feature of the telephone network. Caller ID (or "CID"), also referred to as calling line identification (CUD) or calling number identification (CNID), is a service provided by a telephone network carrier, which transmits a caller's number to the called party's telephone equipment during a ringing signal, or when the call is being set up but before the call is answered.

In case bridging module 112 (Fig. 1) is an integral part of the OS of phone 100 (Fig. I), actuator 202 may be associated with telephony module 108 (Fig. I) by way of incorporation into the software code constituting the telephony module.

In the opposite case, where bridging module 112 (Fig. 1) is an add-on to the OS of phone 100 (Fig. 1), the association between actuator 202 and telephony module 108 (Fig. 1) may be made using an optional call event listener (or simply "listener") 208, which monitors call events of the telephony module. Listener 208 may be loaded onto RAM 104 of phone 100 (Fig. 1) and run continuously in the background, monitoring the activity of telephony module 108 (Fig. 1), for example using an API (Application Program Interface) of the telephony module, which is provided by the OS. The API may provide the present state of the telephony module, such as its idle state, incoming/outgoing call initiating event or on-call state. Once call initiation event 206 is detected, listener 208 may send a signal to actuator 202, triggering the actuator to detect the telephone network identifier of the other mobile phone(s) participating in the call.

Communicator 204 may be triggerable by actuator 202, such that after the detection of call initiation event 206, the communicator initiates data network communication 210, via modem 110 (Fig. 1), with the other mobile phone(s) participating in the call.

Reference is now made to Fig. 3, which shows a network diagram 300 in which parties to a telephone call seamlessly communicate also over a data network, concurrently with the call.

A data network 302 and a telephone network 304 are shown schematically. A first mobile phone 306 and a second mobile phone 308 are also shown. For simplicity of presentation, only two mobile phones are illustrated in the figure. However, a call carried out may include more than two participants. The simple case of two participants is shown and discussed herein merely as an example. Conference calls including three or more participants are explicitly intended here, and those of skill in the art will recognize that the foregoing and subsequent discussions apply, mutatis inutandis, to such scenarios.

Each of first 306 and second 308 phones may include a telephony module, marked 306a and 308a, respectively, and a data network connection module (hereinafter "modem"), marked 306b and 308b, respectively. Telephony modules 306a and 308a may be similar to telephony module 108 of Fig. 1, and modems 306b and 308b may be similar to modem 110 of Fig. 1.

A central server 310 may be accessible to first 306 and second 308 phones over a global network 312 (such as the Internet), using their modems 306b and 308b, respectively. Modems 306b and 308b may connect to data network 304, which is linked to global network 312. It should be emphasized, however, that the "data network" referred to here is also intended to cover other means for connecting the global network, such via WLAN or the like. Therefore, the term "data network" referred to here is to be interpreted as covering any means for global network connection.

In the context of Fig. 2, where communicator 204 initiates data network communication 210 with the other mobile phone(s) participating in the call, first 306 and second 308 phones of Fig. 3 may both employ a bridging module having a communicator. Initiation of the data communications between first 306 and second 308 phones may be performed by either one (or both) of these phones' communicators, regardless of the issue of who initiated the telephone call and who received it.

Central server 10, as well as first 306 and second 308 phones, may have multiple modes of operation, according to different embodiments. In a first exemplary mode, referred to herein as the "direct mode", central server 310 may serve as a registry, in which a database (DB) 310a of corresponding telephone network identifiers and data network identifiers is maintained. This registry may provide information to any one of first 306 and second 308 phones, based on a query sent from any of the communicators of these phones to the registry. A query may include at least a telephone network identifier, and a response from the registry may include at least a data network identifier, such as an IP address, corresponding to that telephone network identifier. Based on the data network identifier(s), first 306 and second 308 phones may establish direct data network communications between them.

In a second exemplary mode, referred to herein as the "indirect mode", central server 310 may serve as a communication server, configured to relay the communications between first 306 and second 308 phones, optionally in real-time.

When one of these phones queries central server 310 with a telephone network identifier of the other, the server may match the telephone network identifier with a data network identifier of the other phone stored in DB 310a, and relay the communications from first phone 306 to second phone 308 andlor vice versa, using their data network identifiers registered in the server's database.

Reference is now made back to Fig. 2. Communicator 204 may continuously monitor the OS of phone 100 (Fig. 1), to discover a data network identifier, such as an IF address, of the phone. The IP address may occasionally change, such as when phone (Fig. 1) disconnects from and reconnects to the global network, due to switching between mobile broadband and WiFi connections or other reasons. Upon a change in the IF address, or at pre-determined intervals, communicator 204 may utilize modem (Fig. 1) to transmit the new IF to central server 310 (Fig. 3), so that the server may update its records.

Optionally, actuator 202 includes a synchronization manager (not shown), configured to connect to central server 310 (Fig. 3) from time to time in order to fetch records pertaining to address book entries of the phone. Actuator 202 may interface with the OS of the phone, and gain access to its address book, which includes, inter alia, telephone network identifiers of other mobile telephones. In the "direct mode", actuator 202 may then transmit these telephone network identifiers to central server 310 (Fig. 3), and receive, in response, updated data network identifiers which match the telephone network identifiers. This synchronization may prevent the need to connect to the central server every time a call is initiated, especially if the other party was included in the address book. In the "indirect mode", actuator 202 may still transmit these telephone network identifiers to central server 310 (Fig. 3), but receive, in response, information indicating whether these telephone network identifiers are registered in the server or not. This information may then be associated with the relevant entries in the address book, so that the phone's user may know which of his or hers contacts support data communications simultaneously with telephone calls.

The synchronization manager may perform the synchronization in pre-determined intervals, and/or, in a "passive" mode, await a request (also referred to as a "push" message) from central server 310 (Fig. 3) to perform the synchronization. In this passive mode, the server may initiate the synchronization, for example, when its records include an update which is relevant to this particular user, such as when another person, included in the phone's address book, joins the service or updates his or hers information.

Reference is now made to Figs. 4A and 4B, which show flow charts of server-side 400 and client-side 450 methods for data communication between two or more mobile telephones being engaged in a telephone call, in accordance with an embodiment. Methods 400 and 450 lays out the operation of first 306 and second 308 phones and central server 310 of Fig. 3, phone 100 of Fig. 1 and bridging module 112 of Fig. 2 in greater detail.

On the server side, in a block 402, a subscriber database is maintained. This database may include telephone network and data network identifiers of mobile telephones subscribed to the service. In the direct mode of operation, in a block 404, data network identifier(s) are provided to mobile telephones who request them, so that direct data connection may be established between the telephones using thefl data network identifier(s). In the indirect mode, the telephone network identifiers stored in the subscriber database may serve as the subscriber identifiers, based on which the server identifies the subscribed phones and recognizes messages to and from these phones. The actual relay of communications over the global network, in a block 406, is performed using the data network identifiers associated with these subscriber identifiers.

On the client side, in an optional block 452, the telephony module of the phone's OS may be monitored for call initiation events. This may be needed in case actuator 202 of Fig. 2 is not an integral part of the OS.

In case actuator 202 of Fig. 2 is an integral part of the OS, client-side method 450 may start in a block 454, in which a telephone network identifier is detected when a call is received or initiated.

In a block 456, an interface with the phone's modem is opened by bridging module 112 (Figs. 1-2), so that in a block 458, the telephone network identifier may be transmitted to the central server.

Then, client-side method 450 splits between the direct and indirect modes. In the indirect mode, in a block 460, the server identifies the present phone and the other phone(s) being party to the telephone call based on their telephone network identifiers, and relays the data communications between the phones.

In the direct mode, in a block 462, the phone may query the server with the telephone network identifier, to receive the data network identifier of that subscriber.

Then, in a block 464, the present phone and the other phone(s) being party to the telephone call may communicate directly, based on their data network identifiers.

As an alternative to actions of blocks 454-458, the synchronization manager may, as discussed above, periodically fetch information from the server, in order to prevent the need to do so instantly upon every call.

Reference is now made to Figs. 5A-D, which show an exemplary GUI (Graphical User Interface), in accordance with an embodiment. GUI may be used in mobile telephones subscribed to the present service, of which phone 100 of Fig. is a representative member. The GUI may enable each party to a telephone call to communicate with the other party(ies) also over the data network (such as the Internet), concurrently with the call. It is emphasized that the GUI showed here is an example only, and that differently-designed GUIs are also possible -as long as they enable operating the software and/or hardware of the phone along the lines of the

present disclosure.

Fig. 5A shows a contacts screen 500, in which contacts 502a-f from the phone's address book are listed. Contacts screen 500 may either be the OS's inherent contacts screen, or, in case bridging module 112 (Figs. 1-2) is not an integral part of the OS, be a screen generated by the bridging module by interfacing with the OS's address book.

Next to each contact 502a-f, a status icon 504a-f, respectively, is displayed. The status icon 504a-f indicates whether this contact is subscribed to the service or not. If the contact is subscribed, the icon may read "synced" or bear a similar text. This indicates that the synchronization manager has discovered, by synchronizing with the server, that this contact is subscribed to the service. If this contact is not subscribed to the service, the icon may read "invite", allowing the user of the phone to click the icon and invite the contact to join the service, such as via email, SMS message or the like.

A "call" icon 506 may appear next to each contact, allowing the user to call the contact via the telephone network by clicking on the icon. In this example, we shall assume that the user clicked the call icon 506 next to Jane Doe's listing 502a. Then, in Fig. SB, an on-call screen 530 is displayed. On-call screen 530 shows the details 532 of the called contact. Next to them, one or more call-related action buttons may be shown. An "end" button 534 may be used to terminate the call andlor to terminate the usage of one or more add-ons. In other words, it may terminate also the data network communications between the parties. For simplicity of presentation, only a single "end" button 534 is shown, but two separate end buttons may exist -one for terminating the call and one for terminating the data network communications.

Alternatively, a single button may be used, where a first click ends the call and a second click ends the data network communication.

An "add-ons" button 536 may be used to display an upper pane 542 of on-call screen 530, in case this upper pane is hidden, due to the use of an add-on. A "speaker" button 538 may be used to switch between audio output devices, such as the phone's earpiece, loudspeaker or an external audio device such as a car's hands-free speaker, an earphone or the like. A "back" button 540 may be used to exit the GUI, and to return to the phone's regular call screen (not shown), in case the user does not desire to communicate with the other party(ies) over the data network.

Upper pane 542 of on-call screen 530 may include one or more add-ons, each of which has a functionality which utilizes the data communication possibility between the parties. As mentioned above, the communication over the data network may include, for example, transmission of various files, photos, text, joint web browsing, multi-player gaming, social network interaction and/or the like. Fig. 58 shows some exemplary options: One example is the use of the phone's GPS device to share a location 544 of one or more of the parties participating in the call. The user of the phone may use this function to extract his or hers location information from the phone's GPS device, and transfer them, over the data network, to the other party -Jane Doe in this case.

Additionally or alternatively, location button 544 may enable the user to request Jane Doe to share her location. After the location of either party is shared, it may be continuously displayed (not shown) to the opposite party.

Another example involves the sharing of various Internet sources with the other party. A link, optionally formatted as a URL (Uniform Resource Locator) may be shared with the other party using a "share link" button 546. Fig. SD shows a joint web browsing screen 580 which may be opened on both phones when "share link" button 546 is pressed by either of the parties. In this example, it is Jane Doe who pressed this button, and a pop-up window 582 asks the present user to confirm whether to initiate a joint browsing session with Jane. Once the request is confirmed, the parties may perform various web browsing activities (such as pressing links, typing text etc.), while a browser window 584 is constantly. synchronized between them over the data network, as if they were using the same web browser.

Yet another option is to use the GUI to display information about the other party(ies), fetched from various Internet sources. For example, a "social" button 548 in Fig. SB may be clicked on in order to display Jane Doe's social network profile 560.

Jane Doe's information is extracted from the phone's OS, and matched with a database of the social network or the pertinent Internet resource. Once matched, the profile is displayed to the user. In this usage option of the GUI, no active data network connection is required between the parties, and each of them may separately fetch information from the internet.

Multi-player, online games may also utilize the data communications between the parties. A "games" button 550 may be used to access one or more games, in which the users compete against each other or collaborate. The data communications, in this case, are used to synchronize the user actions performed throughout the game in real time.

Other examples of add-ons are a "money" 552 add-on which allows the parties to transfer money between each other using an online service such as PayPal, and a "group buying" 554 add-on which allows the parties to perform joint browsing in group buying websites. All the examples brought here are meant to be illustrative.

Numerous other options for seamlessly utilizing the data network connection of mobile telephones simultaneously with a telephone call exist.

In order to add more add-ons to upper pane 542 of on-call screen 530, the user may click a "+ add-ons" button 501, which leads to a screen (not shown) with a library of multiple other add-ons which utilize the phone's data network connection for communication between call parties.

EXAMPLES

One example of the invention, which has been successfully implemented by the inventor and is schematically shown in Fig. 6, is based upon the use of the Andoid mobile OS on the client 602 side, and the OpenFire real-time collaboration (RTC) server 604 on the server side. On the client-side, the implementation is an add-on to the OS (what is often referred to as a "third-party application").

The Android mobile OS is based upon a modified version of the Linux kernel.

Android is currently maintained and further developed by the Android Open Source Project (AOSP), headed by Google, Inc. Android is commonly divided into multiple "layers" -the Linux kernel, libraries, application framework and application layer.

Third-party applications for Android usually lie in the application layer, and utilize the application framework and libraries as needed. Applications for Android are commonly programmed using C andlor Java-based syntax, developed and compiled using the Android SDK (software development kit) provided to developers.

The Android application framework includes a native public class called TelephonyManager, which handles the telephone calling capabilities of the phone. In the present exemplary implementation of the bridging module at the client side, a call event listener is registered in the OS, and utilizes method in TelephonyManager class to receive notifications of the TelephonyManager activity and state changes. The call event listener does not instantiate the TelephonyManager class directly; instead, it retrieves a reference to an instance through Context.getSystemService (Context.TELEPHONY_SER VICE).

The call event listener is then notified upon the following changes in the phone's state, through the provided constant android.intent.action.PHONE_STATE: CALLfiTATEJDLE, CALL_STATEOFFHOOK and CALL STATE RINGING.

Whereas the CALL_STATERINGING value indicates an incoming call, the CALLSTATE_OFFHOOK value indicates that dialing (outgoing calling) is in progress, or that a telephone call (incoming or outgoing) is already being carried out.

When the call event listener detects that the status changes from CALL_STATE_IDLE to CALL_STATE_OFFHOOK or to CALL.STATE_ RiNGING, namely -that a call initiation event is occurring, the actuator may be set to work. The actuator interfaces with the TelephonyManager class, to detect the telephone network identifier of the other party. This is done by running the function getStringExtra(EXTRAJNCOM1NG_NUMBER) upon CALL_STATE_RfNWNG, or the function OutgoingCallReceiver.INTENT_PHONE_NUMBER upon CALL_STATE_OFFHOOK.

When the telephone network identifier of the other party it detected, the actuator may trigger the communicator. The communicator then, in the foreground, displays a GUI to the user, and, in the background, interfaces with the phone's data connection module to enable the data communications between the parties, as requested by the user using the GUI. The interface with the data connection module may be performed using the android.net package and its sub-packages, the org.apache.http class and its sub-classes, and/or other packages and classes provided in the SDK.

When the communicator is first triggered, it may perform a check of whether the other party(ies) is available to communicate over the data network. This may be performed, in the exemplary Smack case, by utilizing an "if" condition if(user.presenceMode "Available") prior to attempting to initiate the data communication between the parties. This "if' condition is based upon the "presence" functionality of XMPP, which maintains connection between the clients and the server so that the clients may be "present" and available for instant messaging activity whenever required.

The various add-ons are regarded herein as part of the communicator. The data communications utilized by these add-ons are handled by the communicator, using the aforementioned packages and/or classes of the OS.

When the TelephonyManager changes its status back to CALL_STATE_IDLE namely, when the call in ended, the communicator may terminate or continue the data communications between the parties, based either on its pre-determined, programmed behavior or on user request.

On the server side, as mentioned, the OpenFire RTC server is utilized. OpenFire is a cross-platform, open source XMPP server written in Java. XMPP is an open-standard communications protocol for message-oriented middleware, based on Extensible Markup Language (XML). The basics of XMPP, which is extendible by nature, are laid out in RFCs (requests for comments) 3920, 3921, 3922 and 3923, standardized by the Internet Engineering Task Force (IETF). These RFCs are incorporated herein by reference.

According to the XMPP protocol, messages between end-users (mobile telephones, in the present case) are referred to as "instant messages" (IMs), and are relayed through the XMPP server. Optionally, multiple XMPP servers may exist, and be connected therebetween using a gateway, to relay messages from a user of a first server to a user of a second server, and so forth. Scaling up the operation of the XMPP server may also be performed by deploying multiple connection managers 604a, which are a component of the OpenFire server, on a single server, wherein each group of users (commonly hundreds to thousands) is handled by a different connection manager.

The data communications between mobile telephones, according to the present implementation example and in the context of XMPP, are realized as IMs 606 between the phones. The transferred data is encapsulated inside the XML text which is transferred from one client, through the server, and on to the other client(s) -all over the Internet. Such IMs exchanged back and forth between parties to a telephone call may be referred to as a "chat room", which is essentially an XMPP communication session between defined clients.

For reasons of simplicity, and in order not to burden the subscribers with the need to use a designated identifier for this service, their telephone network identifiers may serve as their identifiers in the XMPP server, This also enables seamless registration to the service, since the telephone network identifier of the registering phone is readily available to the bridging module, in an automatic manner.

In XMPP, users are uniquely addressable in a form that is consistent with RFC 2396. For historical reasons, the address of an XMPP entity is called a Jabber Identifier, or JID. A valid JID contains a set of ordered elements formed of a domain identifier, node identifier, and resource identifier. The typical syntax for a JID is shown below: jid = [node "(."] domain ["I" resource] domain = fqdn / address-literal fqdn = (sub-domain 1 *(tI,II sub-domain)) sub-domain = (internationalized domain label) address-literal = IPv4address / IPv6address The most common use of this structure is to identify an instant messaging user, the server to which the user connects, and the user's connected resource (e.g., a specific client) in the form of cuser@hostlresource>. In the present exemplary implementation, the "node" is the user's telephone network identifier (i.e. telephone number) and the "address-literal" is the user's data network identifier (i.e. IP address). The IP address is necessary for communication between the client and the server over the Internet.

Node types other than clients are possible; for example, a specific chat room offered by a multi-user chat service could be addressed as croom@service> (where "room" is the name of the chat room and "service" is the hostname of the multi-user chat service) and a specific occupant of such a room could be addressed as <room@service/nick> (where "nick" is the occupant's room nickname). Many other JID types are also possible.

Back to the client side, the communicator includes an XMPP client, which, in this exemplary implementation, is the Smack open-source XMPP client library 608, is used for instant messaging and presence. Smack is essentially a Java library which is embedded in the communicator to give it XMPP capabilities, thereby enabling the data communications with the other party(ies) through the XMPP server.

The communicator utilizes Smack to create XMPP-eompliant communications, Smack then produces the necessary XML and transmits it to the XMPP server over the Internet. The communicator uses the Smack API, whose basic lines of code needed to create an instant message are, for example: XMPPConnection connection new XMPPConnection("innobell. corn'); connection. connectO; connection.login("555-123-4567", "password'); Chat chat connection.getChatManager. createChat("SSS-] 23- 456 7@innobell. corn ", new MessageListener() ( public void processMessage (Chat chat, Message message) ( System. out.println("Received message: "+ message); 30} chat. sendMessage("Hello world!'); Further in the client, the synchronization manager included in the actuator may periodically check with the XMPP server whether contacts included in the phone's address book are registered as users in the XMPP server. The synchronization manager may access the address book by using the android.provider.ContactsContract class, in which the ContactsContract.PhoneLookup sub-class provides the telephone number of the contact. The synchronization manager may then query the XMPP server with this number, to check if it is associated with a subscribed user. According to XMPP, this query may be formatted, for example, as: UserSearchManager searchManager = new UserSearchManager(connection); answerForm. setA nswer("search ", userid); answerForm. setAnswer("Username ", true); answerForm. setAnswer("Name ", false); answerForm, setAnswer("Ernail", false); ReportedData result null; try ( result = searchManager.getSearchResultsç"answerForm, "search. 127.0.0.1 9; } catch (XMPPException e) { Log. d(TAG, e.getMessage,);

I

If the number is indeed associated with a subscribed user, the address book entry of this contact, as it appears in the GUI (for example, in contacts screen 500 of Fig. 5A), may indicate the fact that the contact is subscribed with a suitable mark, such as a "synced" text.

As discussed above, the XMPP "presence" of a user determines his or hers availability for instant messaging using the XMPP protocol. This presence may be kept either by defining, at the XMPP server, how long a connection lasts (for example, it may be set to never expire), and/or periodically triggering a client-side command that reconnects to the server. In Smack, for example, this may be performed by periodically running such a command: XMPPConnection connection = new XMPPConnection("innobelLcom'9; connection. connectO; connection. login("555-123-4567 ". "password'9; Before any of the aforementioned communications are carried out, the users wishing to use this service need to undergo a registration process. Initially, a user downloads an application containing the bridging module from an application repository 610, optionally the Android Market, available at https://market.android.com. When the application is first run, the user may click a "register" button provided in the application's GUI. The application may then register the user at the XMPP server in one of multiple ways: For instance, the application may interface with the aridroid.telephony.SmsMessage class in order to automatically, in the background, send an SMS message 612 to an SMS gateway 614 which then sends an http registration notice 616 to the XMPP server. In the present exemplary implementation, the service provided by Twilio, Inc., of San Francisco, California is utilized, in which the SMS is transmitted to a virtual telephone number associated with Twilio's gateway. Twilio' s gateway then transmits an http message, over the Internet, to the XMPP server, which registers the user and assigns it a JID which is its telephone number -as indicated by the SMS. Then, the XMPP server responds to the gateway with a "registration successful" message, and the gateway sends a confirmation SMS to the user.

Another example of how registration may be carried out is over the Internet. The actuator may detect the user's telephone number, and communicate directly with the XMPP server, over the internet, to register the new user.

In the description and claims of the application, each of the words "comprise" "include" and "have", and forms thereof, are not necessarily limited to members in a list with which the words may be associated.

Claims

CLAIMSWhat is claimed is: 1. A bridging module for a mobile telephone, the bridging module comprising: an actuator associated with a telephony module of the mobile telephone and configured, in response to a call initiation event of the telephony module, to detect a telephone network identifier of a different mobile telephone participating in the call; and a communicator being triggerable by said actuator upon initiation of the call, and being configured to interface with a data network connection module of the mobile telephone for communicating with the different mobile telephone using a central server maintaining a database of corresponding telephone network and data network identifiers.
2. The bridging module according to claim 1, wherein: the central server is configured to relay communications between mobile telephones based on the data network identifiers of the mobile telephones; and wherein said communicator is further configured to communicate with the different mobile telephone through the central server.
3. The bridging module according to claim 2, wherein the central server is an XMPP (Extensible Messaging and Presence Protocol) server, and wherein said communicator comprises an XMPP client for communicating with the different mobile telephone indirectly, through the central XMPP server.
4. The bridging module according to claim 3, wherein said XMPP client comprises a Smack client library.
5. The bridging module according to any one of claims 1-4, wherein said communicator is configured to interface with an operating system of the mobile telephone for discovering a data network identifier of the mobile telephone, and to transmit the data network identifier to the central server, for updating the database.
6. The bridging module according to any one of claims 1-5, wherein said actuator comprises a synchronization manager configured to interface with the central server to detect address book entries in said mobile telephone which appear in the database of the central server.
7. The bridging module according to any one of claims 1-6, further comprising a call event listener configured to monitor the telephony module of the mobile telephone, to detect the call initiation event.
8. The bridging module according to any one of claims 1-7, wherein said communicator is further configured, prior to communicating with the different mobile telephone, to check with the central server the availability of the different mobile telephone to communicate.
9. The bridging module according to any one of claims 1-8, wherein said communicator is further configured to maintain a connection to the central server by periodically reconnecting to the central server.
10. The bridging module according to claim 1, wherein said communicator is further configured to query the central server for a data network address of the different mobile telephone, based on the telephone network of the different mobile telephone, and to communicate with the different mobile telephone directly, based on the data network address.
11. A method for data communication between two or more mobile telephones being engaged in a telephone call, the method comprising, in a first one of the mobile telephones: automatically detecting, upon initiation of a telephone call, a telephone network identifier of a different at least one of the mobile telephones engaged in the telephone call; over a data network connection module of the first one of the mobile telephones, transmitting the detected telephone network identifier to a central server maintaining a database of corresponding telephone network and data network identifiers; and over the data network connection module of the first one of the mobile telephones, communicating with the different at least one of the mobile telephones, using the central server.
12. The method according to claim 11, wherein the central server is of a type configured to relay communications between mobile telephones based on the data network identifiers of the mobile telephones, and wherein the communicating with the different at least one of the mobile telephones using the central server comprises relaying communications through the central server.
13. The method according to claim 12, wherein the relaying of communications through the central server comprises transmitting XMPP instant messages from the first one of the mobile telephones to the central server, and relaying the XMPP instant messages from the central server to the different at least one of the mobile telephones.
14. The method according to any one of claims 11-13, fbrther comprising interfacing with an operating system of the first one of the mobile telephones for discovering a data network identifier of the first one of the mobile telephones, and transmitting the data network identifier to the central server for updating the database.
15. The method according to any one of claims 11-14, further comprising interfacing with the central server and detecting address book entries in the first one of the mobile telephones which appear in the database of the central server.
16. The method according to any one of claims 11-15, further comprising monitoring the telephony module of the first one of the mobile telephones, to detect the initiation of the telephone call.
17. The method according to any one of claims 11-16, further comprising checking with the central server the availability of the second one of the mobile telephones to communicate over the data network.
18. The method according to any one of claims 11-17, further comprising maintaining a connection to the central server by periodically reconnecting to the central server.
19. The method according to claim 11, wherein the communicating with the different at least one of the mobile telephones using the central server comprises: querying the central server for a data network address of the different at least one of the mobile telephones, based on the telephone network of the different at least one of the mobile telephones; and communicating with the different at least one of the mobile telephones directly, based on the data network address.