GB2540399A

GB2540399A - Telephone set and telephone system

Info

Publication number: GB2540399A
Application number: GB1512422.5A
Authority: GB
Inventors: James Irving Roland; Hutt Daron
Original assignee: 4com Technologies Ltd; 4com Tech Ltd
Current assignee: 4com Technologies Ltd
Priority date: 2015-07-16
Filing date: 2015-07-16
Publication date: 2017-01-18
Anticipated expiration: 2035-07-16
Also published as: GB201512422D0; GB2540399B

Abstract

A telephone set comprising a log on manager for logging a user on to the telephone set, a user profile store 62 for storing a local copy of a profile of the user, and a local profile manager 60 for managing the user profile store. The local profile manager is arranged to obtain a copy of the user's profile from a remote profile store 54 when the user logs on to the telephone set. By arranging the local profile manager to obtain a copy of a users profile from a remote profile store when the user logs on to the telephone set, the user can log on to different telephone sets and have full access to their profile. This can facilitate flexible usage of the telephone set, such as hot desking. Aspects include a method of operating a telephone set, the method comprising: logging the user on to the telephone set using a log on manager, obtaining a copy of the users profile from a remote profile store when the user logs on to the telephone set; and storing a local copy of the users profile in a user profile store.

Description

TELEPHONE SET AND TELEPHONE SYSTEM

The present invention relates to a telephone set, and in particular to a telephone set for use by multiple users, as well as a telephone system incorporating such a telephone set. A telephone system may comprise a group of telephone sets, usually located within an organization, connected via a private telephone network. Each telephone set is usually allocated to a particular individual or to a particular location. The private telephone network may include a private branch exchange (PBX) for connecting calls between the telephone sets and the public switched telephone network (PSTN).

Modern telephone sets generally include some processing capability as well as some memory. This can allow the telephone set to offer increased functionality, and allow it to be customized for a particular user. In such telephone sets user profile information such as user name, user number, user settings, user preferences, user contacts and so forth is usually stored locally on the telephone set.

Organisations are increasing promoting flexible working arrangements for their staff, such as hot desking (i.e. use of a work station by different users at different times) and telecommuting. However this may mean that members of staff are not always able to take full advantage of the capabilities of their telephone sets.

According to a first aspect of the present invention there is provided a telephone set comprising: a log on manager for logging a user on to the telephone set; a user profile store for storing a local copy of a profile of the user; and a local profile manager for managing the user profile store, wherein the local profile manager is arranged to obtain a copy of the user’s profile from a remote profile store when the user logs on to the telephone set.

The present invention may provide the advantage that, by arranging the local profile manager to obtain a copy of a user’s profile from a remote profile store when the user logs on to the telephone set, the user can log on to different telephone sets and have full access to their user profile. This can facilitate flexible usage of the telephone set, such as hot desking.

The user profile may include any information which is relevant for the user’s use of the telephone set, such as user name, user number, user settings, user preferences, user contacts, call history, browsing history, user photographs etc.

The remote profile store is preferably a global profile store which stores multiple user profiles. This can allow the telephone set to be used by multiple users and facilitate flexible usage of the telephone system.

Preferably the telephone set is part of an organisation’s telephone system, and the remote profile store is operated by a party external of the organisation. For example, the remote profile store may be operated by telephony service provider which provides telephony services to the organisation.

In order to facilitate communication between the telephone set and the remote profile store, the telephone set may include a profile interface for interfacing with the remote profile store.

Communication between the telephone set and the remote profile store (as well as with other parts of the system) may be via any suitable means such as the Internet, an intranet, an extranet, or any other type of network.

The local profile manager may be arranged to send an identification of the user to the remote profile store when the user logs on to the telephone set. The identification of the user may be based, for example, on the user log on details. This can allow the remote profile store to identify the user and send back the appropriate user profile.

While the user is using the telephone set, changes may be made to the user’s profile either by the user or another part of the system. Thus the telephone set may comprise a user profile updater for updating the user profile store.

Preferably the telephone set comprises an event interface for interfacing the user profile updater with an event bus. The event bus may be a logical bus which transfers event occurrences from sources to subscribers. The user profile updater may then be arranged to monitor events on the event bus and to update the user profile store when an event relates to the profile of a user currently logged on to the telephone set. This can allow the telephone set to maintain an up to date local copy of the user’s profile even if the user’s profile is updated elsewhere in the system.

Furthermore, the user profile updater may be arranged to notify the event bus of an update in the user’s profile when the user’s profile is updated by the telephone set. This can allow other parts of the system, such as the remote profile store, to be updated when the user’s profile is updated on the telephone set, for example by the user. This can allow the system to remain synchronized with the correct user profile.

In one embodiment the telephone set further comprises a camera, a facial recognition processor, and an image store. In this embodiment the facial recognition processor may be arranged to compare an image from the camera with an image of a user stored in the image store, and the log on manager may be arranged to log a user on to the telephone set when the facial recognition processor determines that an image from the camera matches an image of the user stored in the image store. This can allow a user to log on to the telephone set using facial recognition when they approach or sit down in front of the telephone set.

The log on manager may be arranged to present a log on screen to the user if the facial recognition processor does not recognise the user. This may allow the user to log on using for example a user name and/or password. Alternatively, other methods of logging on the user may be provided, such as fingerprint recognition or any other appropriate technique for example using biometric data. The logon manager may then be arranged to store an image of the user in the image store when the user has logged on. This may allow the user to log on using facial recognition at a later date.

In another embodiment (which may be provided separately from or in combination with the above embodiment) the telephone set may further comprise a camera, a movement detection module, and a power management module. In this embodiment the movement detection module may be arranged to detect movement in an image from the camera, and the power management module may be arranged to power the telephone set from a standby state to an on state when movement is detected. This can allow the telephone set to be powered up automatically as a user approaches the telephone set. Alternatively or in addition the power management module may power up the telephone set in response to other inputs such as a signal from a telephone handset or cradle or touch screen.

The telephone set is preferably able to store user contacts, to assist the user with making telephone calls. Thus the telephone set may further comprise a local contacts manager, in order to manage the user’s contacts.

Some telephone users, such as business users, may need to access multiple contact directories during their working day. Currently this requires the user to open each contact directory separately.

In a preferred embodiment of the invention, the local contacts manager is arranged to obtain user contacts from a plurality of sources, and to store the user contacts in a local contacts store. This can allow the telephone set to merge multiple contact sources, allowing the user to access their contacts more readily.

Preferably the local contacts manager is arranged to notify an event bus of an update in the user’s contacts when the user’s contacts are updated by the telephone set. This can help to ensure that the contacts remain updated across the whole system.

Preferably the telephone set further comprises a search manager which is arranged to search for a contact in response to a user input. The search manager is preferably arranged to search a plurality of sources in response to a search query input by the user. This can allow multiple sources to be queried each time the user performs a search and the results presented together.

The telephone set may further comprise a results prioritizer arranged to prioritize the search results. In order to help prioritize the results, the telephone set may further comprise a behaviour store which stores information relating to previous usage of a telephone set by the user. The information may relate to previous usage of that telephone set and/or another telephone set. The results prioritizer may then be arranged to prioritize the results at least in part based on information stored in the behaviour store.

In order to help maintain the behaviour store, the telephone set may further comprise a prioritization learning module arranged to learn behaviour of the user and to store behaviour of the user in the behaviour store. The prioritization learning module may be arranged to receive usage events from elsewhere, for example via an event bus. This can allow the behaviour store to be kept up to date.

In any of the above arrangements the user profile information may include one or more of user name, user number, user settings, user preferences, user contacts, call history, browsing history, and user media such as photographs, video clips and audio.

According to another aspect of the invention there is provided a telephone system comprising a telephone set in any of the forms described above, and a global profile controller, the global profile controller comprising a global profile store which stores multiple user profiles.

Preferably the global profile controller is operated by a party which is external to an organisation using the telephone system. For example, the global profile controller may be operated by telephony service provider which provides telephony services to the organisation.

The global profile controller may comprise a global profile manager arranged to receive an identification of the user from the local profile manager, to look up the user’s profile in the global profile store based on the identification of the user, and to send the user’s profile to the local profile manager.

The global profile controller may further comprise an event interface for interfacing with an event bus, and the global profile manager may be arranged to receive user profile updates from the event bus, and to update the global profile store in response thereto.

The telephone system may further comprise a global contacts controller, the global contacts controller comprising a global contacts store which stores the contacts of multiple users.

The global contacts controller may further comprise a global contacts manager and an event interface for interfacing with an event bus, and the global contacts manager may be arranged to receive user contact updates from the event bus, and to update the global contact store in response thereto. This can allow the user’s contacts to be kept up to date even if the user has been using different telephone sets, or if the contacts are updated elsewhere in the system.

The telephone system may comprise a plurality of telephone sets and a telephony switch, such as a PBX. In this case the telephony switch may be arranged to notify events to an event bus. Alternatively or in addition the telephone system may include various other system components such as a client relationship management (CRM) system and an event bus.

In the arrangements described above the various parts of the telephone set and the telephone system may be implemented as software modules running on one or more processors and/or as hardware components as appropriate.

Corresponding methods may also be provided. Thus, according to another aspect of the invention, there is provided a method of operating a telephone set, the method comprising: logging the user on to the telephone set using a log on manager; obtaining a copy of the user’s profile from a remote profile store when the user logs on to the telephone set; and storing a local copy of the user’s profile in a user profile store.

According to another aspect of the invention there is provided a computer program, or a computer readable storage medium comprising program code, which, when executed on a processor, causes the processor to implement any of the components described above, or to carry out a method as described above.

In the arrangements described above features of one aspect or embodiment may be provided either independently, or in combination with any other aspect or embodiment.

Apparatus features may be provided with method aspects and vice versa.

Preferred features of the present invention will now be described, purely by way of example, with reference to the accompanying drawings, in which:

Figure 1 shows an overview of a telephone system in an embodiment of the invention;

Figure 2 shows parts of a telephone set which may be used with embodiments of the invention;

Figure 3 is a state diagram of a telephone set in an embodiment of the invention;

Figure 4 shows parts of the telephone set which may be used to log on a user;

Figure 5 shows in more detail parts of the telephone system;

Figure 6 shows parts of the telephone system which are used to manage users’ contacts; and

Figure 7 shows parts of the telephone set used to manage a search function.

System overview

Figure 1 shows an overview of a telephone system in an embodiment of the invention. With reference to Figure 1, the telephone system comprises various components and nodes, including a hub 7 which serves multiple telephone sets 5 of an organisation 10, and a telephony switch 3. The telephony switch 3 provides connections between the hub 7 and the public switched telephone network (PSTN) 9. In some embodiments the hub 7 is split into multiple hubs; in other embodiments the hub is omitted and an interface to other system components is provided in each of the telephone stations. The telephony switch 3 in this embodiment is a private branch exchange (PBX), and is provided by an external party as a service to the organisation 10.

The system of Figure 1 includes customer relationship management (CRM) system 2. CRM system 2 is provided to manage interactions between the telephony system provider (i.e. the provider of the telephony switch 3) and users of the telephony system.

The system of Figure 1 also includes a global profile controller 8. As will be explained below, the global profile controller 8 includes a central repository of the profiles of users of the telephony system.

In the example shown, each of the telephony switch 3, CRM system 2, and global profile controller 8 is off-site from the organisation’s premises 10. The telephony switch 3 communicates with hub 7 via network 6, while the CRM system 2 and the global profile controller 8 communicate with the hub 7 via network 4. The networks 4, 6 may be the same network or different networks, and may be for instance the Internet, an extranet, or any other suitable network known in the art.

The telephony system may include some or all of the system components disclosed in co-pending United Kingdom patent application number 1501138.0, the contents of which are incorporated herein by reference.

Telephone set

Figure 2 is an external view of a telephone desk set which may be used with embodiments of the present invention. The telephone desk set may be as described in co-pending United Kingdom patent application number GB 1501137.2, the contents of which are incorporated herein by reference.

Referring to Figure 2, the telephone desk set 5 includes a touch screen display 12 and a handset 13. The touch screen of the desk set 5 is supported by a base 14. The base 14 houses a data processor, a memory, and one or more hardware modules. The memory is loaded with an operating system platform, such as Android®, which causes various software applications and hardware or firmware modules to be executed. The base 14 may also house other components and sub-systems such as power regulation and loudspeakers. An internal data and signalling interface of the data processor is provided which connects to an interface of the touch screen 12. The data processor serves to control output and process (interactive) input from the touch screen by way of the connection between the respective interfaces.

The touch screen 12 is preferably a capacitive touch screen which includes a sensor to determine at which point or region on the touch screen a touch interaction is made.

The desk set 5 comprises a screen display driver, which is run or initiated by the data processor, which is configured to drive the touch screen to present on the screen one or more interactive visual displays to allow various telephonic functions to be performed by the user. These may include the ability to select a party to be called, dial a number, display the identity of a calling party, selection of a stored number from an address book or list of stored numbers, type alpha numeric data, and/or any other telephonic functionalities. The screen display driver may also present options to the user to control settings of the desk set 5, as well as control or configuration of connection settings with devices or ports external of desk set.

The desk set has incorporated therein one or more wireless transmitter/receivers, such as a Wi-Fi® transmitter/receiver and/or a Bluetooth® transmitter/receiver, to enable the desk set to communicate with other devices over an air interface.

The front facing surface of the touch screen 12, at an upper margin thereof, is provided with an integrated camera 16 which is controlled by the data processor. The camera 16 can allow video or still images to be captured and transmitted to another party with whom the user is speaking using the desk set, for example by way of a video call or video conferencing. The inclusion of the camera also allows other functions such as the use thereof as security camera, as well as other functions to be described below.

The handset 13 is detachably retained in a holder or cradle 15. Although not shown in the Figures the handset 13 is connected to the base 14 by way a cable or wiring which allows communication of data/signalling for the microphone and speaker incorporated into the headset. It will be appreciated that an alternative to a hardwired connection between the base 14 and the handset would be a connection over an air interface, such as by a Bluetooth® connection. The cradle 15 is conveniently located at the side of the screen.

The desk set comprises a hook switch in which a magnet and an induction coil or magnetically activated switch is provided in each of the handset 13 and the cradle 15. The magnet and coil are positioned so that they are sufficiently proximal to each other when the handset is placed on the cradle that the effect of the magnet is to cause an output of the coil/switch indicative of the handset being on the cradle. The signal from the coil/switch is received by the processor so that an indication of whether the handset is on- or off-hook is provided.

Although Figure 2 shows a desk top telephone set, embodiments of the present invention may be used with other types of telephone set such as a handheld telephone set.

In conventional telephone systems, each telephone set is specific to a particular user, with that user’s information stored or cached locally. However this may reduce the ability of the system to use more flexible working arrangements such as hot-desking.

In embodiments of the present invention, a telephone set is provided which facilitates the use of the telephone set by multiple different users.

State diagram

Figure 3 shows a state diagram for a telephone set in an embodiment of the invention. Referring to Figure 3, the various states which can be taken by the telephone set include a standby state 20, an on state 22, a home state 24, a phone state 26, a call state 28, and a locked state 30.

In operation, the telephone set is initially in the standby state 20. In this state the telephone is in power saving mode, with the screen switched off. However some background functions are still enabled.

When in the standby state 20, if the telephone set detects user activity then a power up signal is generated, and the telephone set moves to the on state 22. In this state the screen is turned on, and the telephone set attempts to identify the user and log them on to their account. If log on is successful, then the telephone set moves to the home state 24. If the user logs out then the telephone set returns to the on state 22.

In the home state 24, the user is presented with a customised home screen on the telephone’s display. From this screen the user can choose various options, including the option to make a phone call. If the user chooses to make a phone call, then the telephone set moves to the phone state. In this state the user is presented with various options for making phone calls, as will be discussed in more detail below. If a call is initiated, then the telephone set moves to the call state 28. The telephone set may also move from the home state 24 to the call state 28 if an incoming call is received. From the call state 28 the telephone set returns to the home state 24 when the call is terminated.

The user may also choose to lock the telephone set, in which case the telephone set moves from the home state 24 to the locked state 30. When the telephone set is unlocked, it moves from the locked state 30 back to the home state 24.

It will be appreciated that for ease of reference Figure 3 gives an overview of some of the basic states which the telephone set may take, but in practice many more states may be available.

Logging on

Figure 4 shows parts of a telephone set which are used to log a user on in one embodiment.

Referring to Figure 4, the telephone set comprises camera 16, visual feed processor 32, movement detector 34, power management module 36, facial recognition processor 38, image store 39, logon manager 40, user recogniser module 42, local profile controller 44, home state controller 46, lock state controller 48 and proximity detector 49. The camera 16 may be the same as the camera described above with reference to Figure 2. The visual feed processor 32, movement detector 34, power management module 36, facial recognition processor 38, logon manager 40, user recogniser module 42, local profile controller 44, home state controller 46, lock state controller 48 and proximity detector 49 may be implemented as software modules running on one or more processors within the telephone set. The image store 39 may be part of the memory provided within the telephone set, for example solid state memory.

When the telephone set is in the standby state, the screen is turned off to save power, but the camera 16 continues to capture images from its field of vision.

The visual image feed from the camera is fed to visual feed processor 32, which processes the image feed to produce visual image signals. An output of the visual feed processor 32 is fed to movement detector 34. The movement detector 34 analyses the visual image signal to determine whether there is movement within the visual image which is consistent with a user approaching or sitting down in front of the telephone set. If such movement is detected, then the movement detector 34 sends a signal to the power management module 36 indicating that the telephone set should be powered up. The power management module 36 then powers up the telephone set, bringing it to the on state. The power management module may also power up the telephone set in response to other signals, such as from the telephone handset cradle switch or the touch screen.

An output of the visual feed processor 32 is fed to facial recognition processor 38. The facial recognition processor 38 compares the image captured by the camera to images of users who have previously used the telephone set, which are stored in image store 39. If the image matches that of a user who has previously used the telephone set, then the identity of the user is passed to the logon manager 40. The logon manager 40 then logs the user onto their account based on the facial recognition.

If the user is not recognised, then the logon manager 40 presents a logon screen to the user, enabling them to logon using a user name and password. Other techniques for logging on a user may also be provided, such as fingerprint recognition and/or the use of other biometric data. Once the user has logged on their image may be stored in the image store 39 for use in logging the user on when they next use the telephone set.

In the arrangement described above, various mechanisms may be put into place to prevent fraudulent use of the system. For example, the facial recognition processor 38 may be arranged to monitor the image of the user over a short period of time to ensure that the image is not static. This can prevent fraudulent log on using a photograph of a user.

Once the user has logged on to their account, control is passed to the user recogniser module 42. The user recogniser module 42 passes the user’s logon details to the local profile controller 44. As will be explained below, the local profile controller 44 obtains a copy of the user’s profile from the global profile controller 8, and stores it locally while the user is logged on. This allows the telephone set to have access to user information such as settings and contacts. The home state controller 46 then displays a customised home screen to the user based on amongst other things, their stored preferences, contacts and usage history.

Figure 5 shows in more detail parts of the local profile controller 44 and global profile controller 8. The local profile controller 44 is part of the telephone set, while the global profile controller 8 is a remote apparatus which is located off-site, as described above with reference to Figure 1. The local profile controller 44 and the global profile controller 8 are connected to each other via a network such as the Internet, an intranet, an extranet, or any other suitable network.

Also shown in Figure 5 is an event bus 50. The event bus 50 is a logical bus which is used to transfer event occurrences from sources to subscribers. The event bus is connected to the telephony switch 3, the CRM system 2, the local profile controller 44 and the global profile controller 8 via one or more networks, such as the Internet, an intranet or an extranet. If an event occurs in one part of the telephone system (an event source), the event bus is notified of this event, and transfers details of the event to all other parts of the system which are subscribed to this type of event (the event subscribers). This arrangement can allow knowledge of events to be passed around the system in a managed way without interfering with other operations of the system.

Still referring to Figure 5, the global profile controller 8 comprises global profile manager 52, global user profile store 54, profile API (application programming interface) 56, and event API 58. The global profile controller 8 may be implemented using one or more processors and associated memory and storage which are located off site, for example, at the external party which provides the telephone service, or in the cloud. The global profile manager 52 may be implemented as a software module running on one or more processors.

The global profile manager 52 is used to manage the profiles of all users of the telephone system. These profiles may include information such as user name, account details, email address, call history, user settings, contacts, photos, browsing history etc. The profiles of all of the users are stored in the global user profile store 54. The profile API 56 is used to connect the global profile controller to the local profile controller, while the event API 58 is used to connect the global profile controller to the event bus 50.

The local profile controller 44 comprises local profile manager 60, user profile cache 62, cache updater 64, profile API 66 and event API 68. The local profile manager 60 is used to manage the local profile of a user who is logged on to the telephone set. The user’s local profile is stored in user profile cache 62. The local profile manager 60 connects with other parts of the telephone set, to provide them with part or all of the user profile as needed. The profile API 66 is used to connect the local profile controller to the global profile controller, while the event API 68 is used to connect the local profile controller to the event bus 50.

In operation, when a user logs on to the telephone set, the local profile manager 60 receives the user’s logon details (e.g. user name and/or password) from the user recogniser 42. The local profile manager 60 then checks the user profile cache 62 to determine whether that user’s profile is present in the user profile cache. If the user’s profile is already stored in the user profile cache, the local profile manager 60 provides all or part of the user’s profile to the home state controller 46 and other parts of the telephone set as needed.

If the user’s profile is not already stored in the user profile cache 62, then the local profile manager 60 sends a request for the user’s profile, together with the user’s logon details, to the global profile controller 8 via profile API 66. The global profile manager 52 receives the request via profile API 56. The global profile manager 52 then retrieves the user’s profile from the global user profile store 54 based on the logon details. The user’s profile is sent back to the local profile manager 60 via profile API 56 and profile API 66. The local profile manager 60 then stores the user’s profile in the user profile cache, and provides the user’s profile to the home state controller 46 and other parts of the telephone set.

In the system described above, the user’s profile may be updated by various different parts of the system. For example, the telephony switch 3, the CRM system 2, the global profile controller 8 and the local profile controller 44, as well as other system components, may all update the user’s profile at some stage. When any of these components updates a user’s profile, the update is notified to the event bus 50 via a respective event API.

In the global profile controller 8, the global profile manager 52 monitors update events on the event bus 50 via event API 58. When it detects that an update relates to a user’s profile, it updates the user’s profile stored in the global user profile store 54. In this way the global profile manager 52 maintains an up to date database of all user profiles in the global user profile store 54.

In the telephone set, the cache updater 64 monitors update events on the event bus 50 via event API 68. When it detects that an update relates to the profile of the user who is currently logged on to the telephone set, it updates the user’s profile stored in the user profile cache 62. In this way the local copy of the user’s profile is kept up to date even if updates occur elsewhere in the system.

An important feature of the embodiment described above is that, rather than storing user information locally, all user information and the account details are stored remotely in the global user profile store. All file access is abstracted to appear to the user to be local while actually be stored in the cloud. This means that any user can log on to any device in any location and have full access to all of their settings, contacts, photos, browsing history etc.

In the embodiments described above, when a user sits down in front of the phone the phone will use facial recognition algorithms to identify the user. If the user is not recognised then they will be provided with a traditional username and password prompt for identification. The user is then automatically logged on to the phone. In a standard phone or computing device, the user information is stored or cached locally; however on this device, all user information and the account details are stored in the cloud and all file access is abstracted to appear to the user to be local while actually be stored in the cloud. This means that any user can log on to any device in any location and have full access to all of their settings, contacts, photos, browsing history etc. This makes hot-desking incredibly easy, and even allows a user to use a phone in a different company as if it were their own. It also allows access of all the above features from mobile devices.

Proximity sensing

Referring back to Figure 4, the telephone set includes a lock state controller 48 and a proximity detector 49. If a user has their mobile device paired via a wireless interface such as Bluetooth® with the telephone set, the proximity detector 49 can detect the mobile device’s proximity to the telephone set. When the mobile device moves away from the telephone set, the telephone set can automatically lock itself using lock state controller 48. All calls can then be forwarded to the mobile device.

If a user is on a call on their mobile device as they approach the telephone set, the telephone set will display a button saying “take call from mobile”. Tapping this button will automatically transfer the call from the user’s mobile phone to their telephone desk phone.

If the user is on a call and wants to leave their desk, they can simply press a button on the phone and transfer it straight to their mobile.

The lock state controller 48 can also lock the telephone set in other ways, such as by touching a “lock” button on the touch screen. Similarly, the telephone set can be unlocked in other ways such as by entering a password on the touch screen.

Phone state

Referring back to Figure 3, when the telephone is in the home state 24, the user is presented with a customised home screen on the telephone’s display. From this state, if the user wishes to make a phone call, they press a “phone” button on the screen. This then takes the telephone set into the phone state 26. When in the phone state, a “phone” screen is presented to the user, which allows the user to make a call by one of four methods: 1. Enter the phone number 2. Recent calls 3. Favourite contacts 4. Search

In the case of option 1, the phone number is entered by typing into a number pad displayed on the touch screen, or on the handset. In the case of options 2 or 3, the user selects a recent call or favourite contact by touching the appropriate part of the touch screen. In the case of option 4, the user can type into a search field on the touch screen.

Contacts

The main difference (from a phonebook perspective) between a business user and a domestic user is the number of data sources. A business user will typically be calling a variety of contacts during their working day. The details of these contacts may be stored in a number of different locations. For example, a user may call: • a customer whose details are held on the company’s CRM system • a colleague whose extension is held on the phone system • a colleague’s mobile phone from their Active Directory information • a personal contact from their mobile phone contacts • a supplier whose details are held on a mail server/contact manager such as Exchange® or Outlook® • a company found on a search engine such as yell.com® or Google®.

Currently the user would have to open up the specific application that the contact was stored in and find them in that. However it would be desirable for the user not to have to decide which of these sources they want to find the user on.

In an embodiment of the invention a telephone system is provided which allows the merging of multiple contact sources. The main challenge of this is that the sources are located in various places and have varying syncing methods. For example: • CRM system contacts may be queried in real time using a database connection • The phone system contacts may be stored locally on the phone • The mobile contacts may need to be synced from a cloud provider • Exchange® contacts may be synced via Microsoft® network protocols • Search engine results may be queried asynchronously from the Internet

In the present embodiment, all of these sources are queried each time the user performs a search and the results mixed together, presenting the most relevant results to the user.

Figure 6 shows parts of the telephone system which are used to manage the users’ contacts. Referring to Figure 6, the system comprises local contacts controller 70, global contacts controller 72, contacts event controller 74 and event bus 50. The local contacts controller 70 is part of the telephone set, while the global contacts controller 72 and contacts event controller 74 are located off-site.

The local contacts controller 70 in this embodiment comprises local contacts manager 76, local contacts cache 78, contacts API 80, contacts editor 82, favourite contacts module 83, search manager 84, number lookup module 85, social media sync module 86, and Bluetooth® sync module 87. The global contacts controller 72 comprises global contacts manager 88, global contacts store 90, contacts API 92 and event API 94. The contacts event controller 74 comprises contacts event manager 96, local contacts API 97 and event API 98. The event bus may be the same as that described above with reference to Figure 5.

The global contacts manager 88 is used to manage the contacts of all users of the telephone system. All of the contacts are stored in the global contacts store 90. The contacts API 92 is used to connect the global contacts controller to the local contacts controller, while the event API 94 is used to connect the global contacts controller to the event bus 50.

The local contacts cache 78 is used to keep a local copy of a user’s contacts when that user is logged on to the telephone set. The local contacts manager 76 is used to manage the contacts of that user. When the user first logs on to the telephone set, the local contacts manager 76 obtains the user’s contacts from the global contacts manager 88 via contact APIs 80, 92, and stores the user’s contacts in the local contacts cache 78. If the user wishes to edit their contacts, this is done using contacts editor 82. In addition, social media sync module 86 may be used to obtain contacts from the user’s social media account (such as Facebook®) and Bluetooth® sync module 87 may be used to obtain contacts from another device such as the user’s mobile phone. The favourite contacts module 83, search manager 84 and number lookup module 85 are used respectively to obtain favourite contacts from the local contacts cache 78, to search for contacts in the local contacts cache 78 and elsewhere, and to look up numbers in the local contacts cache 78 and elsewhere.

When the local user’s contacts are updated, the local contacts manager 76 updates the local contents cache 78, and notifies the update to the contacts events manager 96 via local contacts API 97. The contacts event manager 96 then posts a contacts update event to the event bus 50 via event API 98.

The global contacts manager 88 monitors the event bus via event API 94. When the global contacts manager 88 detects that a user’s contacts have been updated, it updates the contacts stored in the global contacts store 90. In this way the global contacts controller 72 keeps an up to date record of all of the contacts of all of the users of the telephone system. This means that, when a user logs on to a new telephone set, they will have all of their contacts available as if the telephone set were personalised for them.

The contacts event manager 96 also monitors events on event bus 50 via event API 98. If the contacts event manager 96 detects that the user of the telephone set has had their contacts updated elsewhere in the system, then it notifies this to the local contacts manager 76 via local contacts API 97. The local contacts manager 76 then updates the local contacts cache 78. In this way the user’s contacts can be kept updated across multiple devices.

The arrangement described above allows the merging of multiple contact directories. For example, contacts from some or all of the following sources may be merged: • Personal mobile • Work mobile • CRM system • Telephony switch (PBX directory) • Email • Social media • Any other directory with user contacts.

All of these sources are queried each time the user performs a search and the results mixed together, presenting the most relevant results to the user.

Search function

As discussed above, when the telephone is in the home state 24 the user can choose to search for a contact. The search function allows the user to start typing part of a contact name, company name or keyword and then presents results back to the user. The results are drawn from multiple sources, both on the phone, in the telephone service provider’s network, and on the Internet. This means that the user does not have to decide what or how to search, they just have to search for something. This is illustrated by the following scenarios: 1. The user wants to call Gary Smith (another user in the same company). The user starts typing “Gary” and as she types, is presented with a list of Garys. The first results in the search are from the telephone system for that company. 2. The user wants to call George Hadley (a personal contact from her mobile phone). The user starts typing “George”. She is presented with a list which contains at the top “George Smith” who is in the company’s phone system, and then the next item down is “George Hadley” which has been synced from her mobile phone. 3. The user wants to call ABC Ltd (a company stored in her CRM system). She starts to type ABC, and as there is no one on the PBX or in her personal contacts called “ABC”, she is shown the ABC record from her CRM system. 4. The user wants to call a plumber. She types in “plumber”. If she has a plumber in her personal address book or company CRM this is shown first. After that combined results from the company directory, an Internet search engine and other directory sources are shown.

The relevance of each result is determined by the following mechanisms:

Text search ranking: if the search string matches the name exactly, the score is high; if the search string matches only one part of the name (first name or surname), a lower score is given.

Figure 7 shows parts of the telephone set used to manage the search functionality. Referring to Figure 7, the system comprises touch screen 16, search manager 84, local contacts manager 76, Internet search engine 100, results prioritizer 102, behaviour store 104, usage mapper 106, local event bus 108, prioritization listener 110 and prioritization learning module 112.

In operation, when a user begins typing in a search query on the touch screen 16, the partial search query is sent to the search manager 84. The search manager initiates a search using both local contacts manager 76 and Internet search engine 100. Results from the contacts manager 76 and the Internet search engine 100 are fed to the results prioritizer 102. The results prioritizer also obtains information regarding past behaviour of the user (for example previous searches and numbers called) from the behaviour store 104.

The behaviour store 104 stores information regarding past behaviour of the user, such as previous searches and numbers called. This information may be part of the user’s profile, and may be loaded into the behaviour store when the user logs on to the telephone set. In this way the behaviour store 104 may include usage information based on the user’s usage of multiple telephone sets.

The results prioritizer 102 prioritizes the results of the searches based on various factors, including the source of the search results, the degree of correlation with the search query, and past behaviour of the user. The results prioritizer sends the prioritized search results back to the search manager 84, together with the sources of the search results. The search manager then displays the search results on the touch screen 12. The search results are updated as the user types more characters into the search field on the screen 12. The user can select the required search result by touching the appropriate area on the touch screen.

The search manager 84 passes details of searches performed by the user to the usage mapper 106. The usage mapper 106 posts details of the searches to the local event bus 108. The local event bus 108 also receives events from other parts of the telephone set, as well as from the global event bus 50.

The prioritization listener 110 listens to the local event bus 108 and detects certain events including searches performed and calls made by the user. When the prioritization listener 110 detects such events, it passes them to the prioritization learning module 112. The prioritization learning module 112 learns the behaviour of the user over time, giving greater weight, for example, to events which have occurred more recently and/or more frequently. The learned behaviour of the user is stored in the behaviour store 104 for use by the results prioritizer 102 when prioritizing the search results.

The above arrangement allows all of the sources to be queried each time the user performs a search and the results mixed together, presenting the most relevant results to the user.

In the embodiments described above the various parts of the telephone set and the telephone system may be implemented as software modules running on one or more processors and/or as hardware components as appropriate.

It will be appreciated that embodiments of the invention have been described above by way of example only, and various modification will be apparent to the skilled person. Furthermore, for simplicity, different parts of the telephone system have been described separately, but it will be appreciated that the various parts may be used either separately or in combination as appropriate.

Claims

1. A telephone set comprising: a log on manager for logging a user on to the telephone set; a user profile store for storing a local copy of the user’s profile; and a local profile manager for managing the user profile store, wherein the local profile manager is arranged to obtain a copy of the user’s profile from a remote profile store when the user logs on to the telephone set.

2. A telephone set according to claim 1, wherein the remote profile store is a global profile store which stores multiple user profiles.

3. A telephone set according to claim 1 or 2, wherein the telephone set is part of an organisation’s telephone system, and the remote profile store is operated by a party external of the organisation

4. A telephone set according to any of the preceding claims, wherein the telephone set comprises a profile interface for interfacing with the remote profile store.

5. A telephone set according to any of the preceding claims, wherein the local profile manager is arranged to send an identification of the user to the remote profile store when the user logs on to the telephone set.

6. A telephone set according to any of the preceding claims, wherein the telephone set comprises a user profile updater for updating the user profile store.

7. A telephone set according to claim 6, wherein the telephone set comprises an event interface for interfacing the user profile updater with an event bus.

8. A telephone set according to claim 7, wherein the user profile updater is arranged to monitor events on the event bus and to update the user profile store when an event relates to the profile of a user currently logged on to the telephone set.

9. A telephone set according to claim 7 or 8, wherein the user profile updater is arranged to notify the event bus of an update in the user’s profile when the user’s profile is updated by the telephone set.

10. A telephone set according to any of the preceding claims, wherein the telephone set further comprises: a camera; a facial recognition processor; and an image store, wherein the facial recognition processor is arranged to compare an image from the camera with an image of a user stored in the image store, and the log on manager is arranged to log a user onto the telephone set when the facial recognition processor determines that an image from the camera matches an image of the user stored in the image store.

11. A telephone set according to claim 10, wherein the log on manager is arranged to present a log on screen to the user if the facial recognition processor does not recognise the user.

12. A telephone set according to claim 11, wherein the logon manager is arranged to store an image of the user in the image store when the user has logged on.

13. A telephone set according to any of the preceding claims, wherein the telephone set further comprises: a camera; a movement detection module; and a power management module, wherein the movement detection module is arranged to detect movement in an image from the camera, and the power management module is arranged to power the telephone set from a standby state to an on state when movement is detected.

14. A telephone set according to any of the preceding claims, further comprising a local contacts manager, wherein the local contacts manager is arranged to obtain user contacts from a plurality of sources, and to store the user contacts in a local contacts store.

15. A telephone set according to claim 14, wherein the local contacts manager is arranged to notify an event bus of an update in the user’s contacts when the user’s contacts are updated by the telephone set.

16. A telephone set according to any of the preceding claims, further comprising a search manager, wherein the search manager is arranged to search a plurality of sources in response to a search query input by the user.

17. A telephone set according to claim 16, further comprising a results prioritizer arranged to prioritize the search results.

18. A telephone set according to claim 17, further comprising a behaviour store which stores information relating to previous usage of a telephone set by the user, and the results prioritizer is arranged to prioritize the results at least in part based on information stored in the behaviour store.

19. A telephone set according to claim 18, further comprising a prioritization learning module arranged to learn behaviour of the user and to store behaviour of the user in the behaviour store.

20. A telephone set according to claim 19, wherein the prioritization learning module is arranged to receive usage events via an event bus.

21. A telephone set according to any of the preceding claims, wherein the user profile information includes one or more of user name, user number, user settings, user preferences, user contacts, call history, browsing history, and user media.

22. A telephone system comprising a telephone set according to any of the preceding claims and a global profile controller, the global profile controller comprising a global profile store which stores multiple user profiles.

23. A telephone system according to claim 22, wherein the global profile controller comprises a global profile manager arranged to receive an identification of the user from the local profile manager, to look up the user’s profile in the global profile store based on the identification of the user, and to send the user’s profile to the local profile manager.

24. A telephone system according to claim 23, wherein the global profile controller further comprises an event interface for interfacing with an event bus, wherein the global profile manager is arranged to receive user profile updates from the event bus, and to update the global profile store in response thereto.

25. A telephone system according to any of claims 22 to 24, further comprising a global contacts controller, the global contacts controller comprising a global contacts store which stores the contacts of multiple users.

26. A telephone system according to claim 25, wherein the global contacts controller further comprises: a global contacts manager; and an event interface for interfacing with an event bus, wherein the global contacts manager is arranged to receive user contact updates from the event bus, and to update the global contact store in response thereto.

27. A telephone system according to any of claims 22 to 26, comprising a plurality of telephone sets and a telephony switch.

28. A telephone system according to claim 27, wherein the telephony switch is arranged to notify events to an event bus.

29. A method of operating a telephone set, the method comprising: logging the user on to the telephone set using a log on manager; obtaining a copy of the user’s profile from a remote profile store when the user logs on to the telephone set; and storing a local copy of the user’s profile in a user profile store.

30. A telephone set or a telephone system substantially as described herein with reference to and as illustrated in the accompanying drawings.

31. A method of operating a telephone set substantially as described herein with reference to the accompanying drawings.