GB2513237A

GB2513237A - Multi-device electronic communications

Info

Publication number: GB2513237A
Application number: GB1403375.7A
Authority: GB
Inventors: Dean Elwood
Original assignee: VOXYGEN Ltd
Current assignee: VOXYGEN Ltd
Priority date: 2013-02-27
Filing date: 2014-02-26
Publication date: 2014-10-22
Also published as: GB201303492D0; GB201403375D0

Abstract

The invention discloses a system whereby an endpoint device can transfer/forward an ongoing session to another endpoint device, typically one also associated with the user of the original endpoint device. Alternatively endpoint devices can be added to the session (e.g. for conferencing) and devices may belong to one of a group of users. The original device may use an SIP REFER message to direct the remote communication endpoint to establish a session with the new device. The original endpoint device may periodically interrogate the local network to discover and authenticate other potential endpoint devices (see Figs. 3a,3b). The resulting list of devices may be presented to the user via a UI menu to allow selection of transferee devices (see Fig. 4).

Description

Multi-Device Electronic Communications This invention relates to live two-way communication between devices -particularly, but not exclusively, devices used to conduct voice calls.

An individual may use many devices in order to make a "phone call". Computers and tablets are now capable of acting as voice communications devices alongside traditional telephone handsets. Moreover other live communication sessions such as video calls, live chat etc. have become increasingly popular.

The present invention aims to provide greater flexibility to a user who has access to more than one such devices.

When viewed from a first aspect the invention provides a method of operating a plurality of devices connected to a common data network wherein a first device is capable of supporting a live two-way communication session, the method comprising: identifying at least one second device capable of supporting the same type of live two-way communication session as the first device; establishing a live two-way communication session involving said first device; displaying an indication of said second device on said first device; accepting a user input to the first device indicating that the user wishes to transfer the live two-way communication session to the second device; and transferring or extending said live two-way communication session to the second device.

The invention extends to a first electronic device capable of supporting a live two-way communication session, said first device being adapted to: identify at least one second device connected to a common data network with the first device and capable of supporting the same type of live two-way communication session as the first device; display an indication of said second device; accept a user input indicating that the user wishes to transfer the live two-way communication session to the second device; and transfer or extend said live two-way communication session to the second device The invention also extends to a computer software product, whether or not on a carrier, which is arranged when run on suitable data processing means, to identify at least one second device connected to a common data network with a first device, both of which are capable of supporting the same type of live two-way communication session; display an indication of said second device on said first device; accept a user input to the first device indicating that the user wishes to transfer the live two-way communication session to the second device; and transfer or extend said live two-way communication session to the second device.

Thus it will be seen by those skilled in the art that in accordance with the invention a user can transfer or extend a call or other live communication session between devices that have already been established as capable of receiving such a transferred call. This allows greater flexibility to a user to initiate or accept a call on one device and then to transfer it to another device -e.g. to give greater functionality, greater comfort or simply greater available battery life. However the first device does not need to relinquish involvement in the session -for example the extension to the second device could act to join the second device into a multi-party session including the first device or add a recording or broadcast application or device to allow the session to be recorded or broadcast. In a set of embodiments of the invention only devices having predetermined identities are designated as being able to receive the live two-way communication session. This could for example restrict the devices to which the communication session can be transferred to devices registered to the same user. In other embodiments designated devices comprise those belonging to a pre-defined group of users. This could for example be a particular workgroup. This would allow one user to give the user input for initiating a transfer to transfer the call to another user in the group or to a conference call or recording device associated with the group.

The transfer may be effected using any convenient method. In a set of embodiments the transfer is effected using signalling used by the two-way communication session. In one example Session Initiation Protocol (SIP) may be used.

The live two-way communication session may comprise voice -i.e. a phone call -a video call, two-way chat session, collaborative working session or any other format not specified here.

The step of establishing which of the devices on the network can conduct a live communication of a particular type, such as a voice call, could be carried out by anything which is connected to the network -e.g. a router or switch. In a set of preferred embodiments however the first device itself establishes what other devices have the ability to receive such a transfer. This could be done in response to a specific prompt or request or could be carried out automatically -e.g. at regular intervals or whenever the first device is connected to the network. In some embodiments a regular check is preferred as this allows the list of other devices available to be periodically updated. For example in a set of embodiments a multi-modal local network discovery system ("MMDS") is used to locate other devices periodically.

The first device could be any sort of device capable of supporting a live two-way communication session. It could for example be a smart-phone, tablet computer, laptop or desktop. However the invention is not restricted to these and can be used with any other devices having appropriate functionality.

The user input could comprise any suitable form of input available on the device. In a set of preferred embodiments the input comprises a gesture carried out on a touch-screen. This allows for example an intuitive movement of a graphical element representing a current two-way communication session to be moved by the users gesture to a graphical element representing the second device. In a set of embodiments a visual indication is given on both the first and second devices to indicate that the call transfer is taking place. For example if a gesture is performed on the device of the first screen and a visual feedback is given on the display, a complementary visual feedback might be given on a display of the second device.

In one non-limiting example, a sweep gesture performed from left to right on the screen of the first device, such as a smartphone, to move a graphical object (as the user might perform if the second device is placed to the right of the first device) might give rise to an animation effect on the left edge of the second device, such as a tablet, indicating that the second device has received' the graphical object. This may give the user the impression that the two device windows are two ports onto a large canvas such that the left edge of the second device is the same as the right edge of the first device.

In a set of embodiments the first and second devices are arranged to use a known encrypted technique to authenticate each other, e.g. to create an ad hoc peer-to-peer network. In one exemplary set of embodiments a hash-key system is used.

A particular embodiment of the present invention will now be described, by way of example only, with reference to the accompanying drawings in which: Figure 1 is a schematic diagram showing a telecoms system using central server-based coordination; Figure 2 is a schematic diagram showing a UDP broadcast system; Figure 3a shows an authentication flow; Figure 3b shows a hash key system; Figure 4 shows a sample user interface indicating an active call and the identified peers to which it can be transferred; Figure 5 shows transfer of a call using another sample user interface; Figure 6 is a diagram illustrating a call transfer protocol after a user has begun engaging in an active call; and Figure 7 is a diagram illustrating a call transfer during a ringing phase of an active call.

Figure 1 illustrates a typical client/server model operated by most commercial telecommunications networks. The server 2 may be connected to wired or wireless phones 4, 6 which are hardware devices. Increasingly however as more devices can be connected to the internet, connected "clients" may now be software based applications running on e.g. phones, tablets 8 and computers 10.

Whilst the server 2 in the arrangement shown in Figure 1 may have an awareness that more than one client device is currently connected, as shown in Figure 2, the connected clients 100, 201, 202 may be behind NAT (Network Address Translation) and other network objects which mask the local locations of the client devices meaning the server will only have visibility of a single public location 12 representing all devices behind the NAT whereas other devices 203, 204 are visible individually on the network 200.

In the embodiment of the present invention described herein, multi-modal local network discovery system ("MMDS") is used to periodically locate other devices, which belong to the same user, on the local network and to identify them. The MMDS may use any method to effect device discovery. For example using the User Datagram Protocol (UDP) a broadcast (sometimes called multi-cast) packet originated from device 100 is sent out on the network 200 to connected devices 201, 202, 203 and 204. Devices 201 and 202 are telephone end-points belonging to the same user as device 100. Device 203 is a telephone end-point belonging to a different user and device 204 is a non-communications device. When the network broadcast packet is received by end-points 201, 202 and 203 these three end-points seek to authenticate with device 100 by using a hash-key system generated by the system as shown in Figure 3b. This is utilized to authenticate users' devices with each other, creating an ad-hoc peer to peer network.

The method described here uses a UDP broadcast mechanism to detect other users on the same local area network (LAN). Each peer authenticates the other to establish the two-way trust relationship. The authentication uses a hashed password+salt exchange, combined with a timestamp. The hash is a one-way process applied to the password, where the peer performs the same one way operation such that secrets are never revealed "in the clear" as part of the exchange. The timestamp imposes a time-limit on the authentication, after which the current keys are invalid, minimizing the chances of a replay attack. This timestamp will be based on the UNIX format (seconds since 1 Jan 1970), but may also incorporate a higher precision element (microseconds) to allow sub-second precision for what could be quite short timed events.

Other use-cases of the underlying system are possible. These include reducing server-side load of multiple registered devices by having just one registered device which is then responsible for multiple peers for parallel ringing signals etc. This helps improve scale by requiring only one registered device over TLS (Transport Layer Security), for example.

When required, client systems should send an MT_ANNOUNCE message to the local LAN IP address modified so that the last Octet is.255 (the broadcast address). This allows local switches to present the announcement to all stations on the same IP network segment. The session flow is then as shown in Figure 3a.

The MT_HELLO response is a peer response claiming that it has the same credentials as the MT_ANNOUNCE sender. This initiates an authentication session between both clients directly by their IP addresses.

The authentication system is initiated by an MT_CHALLENGE message which uses a hashed timestamp combined with a random element and username and password to create a unique package. In an internal table, clients link this generated hash value to the recipient's IP address.

The purpose of the timestamp is to ensure timely response and thwart a replay attack in the event that the intended peer does not respond. The random string adds further complexity and ensures a replay attack will fail, even if initiated within the time-limit allowed for the authentication process.

Advantageously the clients are arranged to clean out the aforementioned internal storage table every time it is accessed, by removing timestamps that are older than about 5 seconds.

On receipt of an MT_CHALLENGE message a peer should hash the received hash with its username and password and return it as an MT_CHALLENGE_RESPONSE to the senders IP address. This enables the recipient to confirm that this peer has the same username and password as itself.

MT_ANNOUNCE may be sent multiple times in the absence of a response. If an MT_HELLO is received, sender should stop from sending more MT_ANNOUNCE messages.

The MT_HELLO message must be replied to with MT_CHALLENGE, then MT_CHALLENGE must be replied to with MT_CHALLENGE_RESPONSE.

If an MT_HELLO is sent and MT_CHALLENGE has not been received within 1 second, MT_HELLO should be sent again, up to a maximum of 5 times.

If an MT_CHALLENGE is sent and MT_CHALLENGE_RESPONSE is not received within 1 second, MT_CHALLENGE should be sent again, up to a maximum of 5 times and with a new random number The session ends with an MT_ACK.

A user's device may repeat this authentication with a number of peers, establishing a list of trusted devices as it does so. This list of devices can then be used for later operations, for example appearing as textual or graphical elements of the user interface of an application.

The user interface for an exemplary application for a smart-phone 14 is shown in Figure 4. This Figure shows three different stages of the transfer of a live phone call using intuitive gestures. The novel functionality be indicated initially by an additional graphical element 16 which is available on the standard in-call' menu 18.

When the user touches or grabs' this element 16 and starts to move it, it causes the in-call menu 18 to shrink, thereby revealing icons behind for trusted peer devices 20, 22 connected to the same LAN as the device 14 initially handling the call. By dragging the element 16 to one of these icons 20, 22, the call is automatically transferred to it. However in other embodiments this may effect some other operation such as joining the device to a conference or a recording device.

Figure 5 shows another sequence of drawings illustrating a call being transferred from a smart-phone 14 to a laptop computer 24. As the user drags the icon 26 to the edge of the screen of the smart-phone 14, a corresponding graphic 28 appears from the edge of the screen on the laptop 24.

Figure 6 shows an exemplary SIP-based protocol for transferring a call which is already established between a remote Peer A and a Transferor to a Transferee C. In this diagram, as in Fig. Sa, the time axis extends vertically downwards. Thus the first message sent by the Transferor in the sequence is a standard SIP REFER message to the Peer A and the Peer A replies with a 202 accepted' message. The Peer A then issues a NOTIFY message to the Transferor B and receives a 200 OK' message in reply. Subsequently the Peer A issues a SIP INVITE message to the Transferee C which replies with a 180 Ringing' message to indicate that the Transferee device now has a ringing call. When the user of the Transferee device C answers the call the Transferee device C issues a 200 OK' message which is acknowledged by an ACK message from the Peer A. Peer A then issues a further NOTIFY message to the Transferor B to notify it of the transfer to C and the Transferor B sends a 200 OK message in reply. Finally the Peer A sends the Transferor B a BYE message indicating that it can relinquish the call which it acknowledges with a 200 OK' message. This then completes the transfer process.

Figure 7 shows an alternative procedure that is followed when the Transferor device has not yet answered the original call. Here the Transferor device receives the SIP INVITE message and replies with a 302 moved temporarily' message which gives details of the Transferee device to which the call is to be transferred.

The Transferor device receives the resulting acknowledgement and then a further INVITE message is sent to the Transferee device. The Transferee device then replies with a 180 Ringing message to indicate that it is displaying the ringing call.

Once the user of the Transferee device has picked up the call, it sends a 200 OK' message which is then acknowledged with an ACK message indicating that the transfer is complete.

Claims

Claims: 1. A method of operating a plurality of devices connected to a common data network wherein a first device is capable of supporting a live two-way communication session, the method comprising: identifying at least one second device capable of supporting the same type of live two-way communication session as the first device; establishing a live two-way communication session involving said first device; displaying an indication of said second device on said first device; accepting a user input to the first device indicating that the user wishes to transfer the live two-way communication session to the second device; and transferring or extending said live two-way communication session to the second device.
2. A method as claimed in claim 1 comprising designating only devices having predetermined identities as being able to receive the live two-way communication session.
3. A method as claimed in claim 2 comprising designating devices belonging to a pre-defined group of users.
4. A method as claimed in any preceding claim comprising using signalling used by the two-way communication session to carry out said step of transferring or extending.
5. A method as claimed in claim 4 comprising using Session Initiation Protocol.
6. A method as claimed in any preceding claim comprising said first device itself establishing what other devices have the ability to receive said transfer.
7. A method as claimed in any preceding claim comprising carrying out a regular check of which of the devices on the network can conduct a live communication of a particular type. -10-
8. A method as claimed in claim 7 comprising using a multi-modal local network discovery system to locate other devices periodically.
9. A method as claimed in any preceding claim wherein the user input comprises a gesture carried out on a touch-screen.
10. A method as claimed in any preceding claim comprising giving a visual indication on both the first and second devices to indicate that the call transfer is taking place.
11. A method as claimed in any preceding claim comprising the first and second devices using an encryption technique to authenticate each other.
12. A method as claimed in claim 11 comprising using a hash-key system.
13. A first electronic device capable of supporting a live two-way communication session, said first device being adapted to: identify at least one second device connected to a common data network with the first device and capable of supporting the same type of live two-way communication session as the first device; display an indication of said second device; accept a user input indicating that the user wishes to transfer the live two-way communication session to the second device; and transfer or extend said live two-way communication session to the second device
14. A device as claimed in claim 13 arranged to designate only devices having predetermined identities as being able to receive the live two-way communication session.
15. A device as claimed in claim 14 arranged to designate devices belonging to a pre-defined group of users. -11 -16. A device as claimed in any of claims 13 to 15 arranged to use signalling used by the two-way communication session to transfer or extend said two-communication session.17. A device as claimed in claim 16 arranged to use Session Initiation Protocol.18. A device as claimed in any of claims 13 to 17 arranged itself to establish what other devices have the ability to receive said transfer.19. A device as claimed in any of claims 13 to 18 arranged to carry out a regular check of which of the devices on the network can conduct a live communication of a particular type.20. A device as claimed in claim 19 arranged to use a multi-modal local network discovery system to locate other devices periodically.21. A device as claimed in any of claims 13 to 20 wherein the user input comprises a gesture carried out on a touch-screen.22. A device as claimed in any of claims 13 to 21 arranged to give a visual indication on both the first and second devices to indicate that the call transfer is taking place.23. A device as claimed in any of claims 13 to 22 arranged to use an encryption technique to authenticate the second device.24. A device as claimed in claim 23 arranged to use a hash-key system.25. A computer software product which is arranged when run on suitable data processing means, to identify at least one second device connected to a common data network with a first device, both of which are capable of supporting the same type of live two-way communication session; display an indication of said second device on said first device; accept a user input to the first device indicating that the user wishes to transfer the live two-way communication session to the second device; and -12-transfer or extend said live two-way communication session to the second device.26. A software product as claimed in claim 25 arranged to designate only devices having predetermined identities as being able to receive the live two-way communication session.27. A software product as claimed in claim 26 arranged to designate devices belonging to a pre-defined group of users.28. A software product as claimed in any of claims 25 to 27 arranged to use signalling used by the two-way communication session to transfer or extend said two-communication session.29. A software product as claimed in claim 28 arranged to use Session Initiation Protocol.30. A software product as claimed in any of claims 25 to 29 arranged to cause the first device to establish what other devices have the ability to receive said transfer.31. A software product as claimed in any of claims 25 to 30 arranged to carry out a regular check of which of the devices on the network can conduct a live communication of a particular type.32. A software product as claimed in claim 31 arranged to use a multi-modal local network discovery system to locate other devices periodically.33. A software product as claimed in any of claims 25 to 32 wherein the user input comprises a gesture carried out on a touch-screen.34. A software product as claimed in any of claims 25 to 33 arranged to give a visual indication on both the first and second devices to indicate that the call transfer is taking place. -13-35. A software product as claimed in any of claims 25 to 34 arranged to use an encryption technique to authenticate the second device.36. A software product as claimed in claim 35 arranged to use a hash-key system.