GB2548165A - A data transfer system and an interactive voice response system - Google Patents

Abstract

The invention provides an Interactive Voice Response system (IVR) of a host server of a first user upon which is stored the files of an interactive voice response system, the stored files representing a first set of questions of the IVR. A personal data exchange controlled by a second user where upon authorisation by a second user, personal data exchange of the second user is mapped to the first set of questions to provide answers to at least some of the questions of the first set and thereby produce a second reduced set of questions of the IVR. The reduced question set is then transferred to a device of the second user for interaction therewith. The invention also provides a data transfer system where a data exchange is arranged to store data within a graph structure. An input for receipt of an identification signal is arranged upon receipt of a user input to identify selected nodes within the graph, and an output only enables the selected node or nodes to be shared with an application or third party.

Description

A Data Transfer System and an Interactive Voice Response System

The present invention relates to a data transfer system, a method of data transfer and an interactive voice response system.

In the current environment, users of data transfer systems are familiar with managing access to their personal data. As the world becomes more online, the volume of personal data that is regularly transferred between different users, increases. Users in this context might be end users or customers of a provider. The provider itself would also be a user of the data transfer systems. In the present specification, “end users” will be used to refer to individuals or institutions that interact or engage with a business or provider of some products or services.

The protection of personal data is a significant current issue. Recent changes in privacy legislation within the European Union mean that the management of personal data is of increased importance to suppliers or businesses. One example is the EDPR EU Data Protection Regulation, described for example in the online article currently available at http://www.computerweekly.com/guides/Essential-guide-What-the-EU-Data-Protection-Regulation-changes-mean-to-you.

Some technical means for managing and controlling the security of data in this environment is needed.

Personal data exchanges that provide for the secure storage and distribution of personal data are known. One example includes US-A-7,587,366. This provides a system and method for providing an information vault so that individual owners of personal data may control and manage the access and dissemination of the personal data. The system and method also provide for the owner of the personal data to receive compensation for the use of the personal data. Thus, as the patent describes, the personal data becomes a valuable commodity controlled by the user.

Although in such systems, a user has some control over the access and dissemination of the personal data, the manner in which the data is transferred to and from a third party can still be quite complex, time consuming and prone to breach of security.

According to a first aspect of the present invention, there is provided a data transfer system, the system comprising: a data exchange arranged to store data within a graph structure; an input for receipt of an identification signal arranged upon receipt of a user input to identify selected nodes within the graph; an output enabling only the selected node or nodes to be shared with an application or third party.

Accordingly, in embodiments of the present invention, a data transfer system is provided including a personal data exchange in which a graph structure is used for controlling and organising the data. This enables identification and identifiable data within the personal data exchange to be “separated” from any selected subset of data items within the data store. This separation provides for an anonymization of the data within the data store and thereby enables anonymous interaction by a user with a third party.

In other words, customers or end users hold their own personal data within the personal data exchange and are able to grant appropriate access to selected third parties such as online businesses.

By enabling such selective anonymization of the data, it is possible for a user to quickly and efficiently provide population of data interfaces of a third party without having to separately provide individual answers to each of the requested fields of the interface. In other words, by use of the control and selected identification of data within the graph in the data store, a quick and efficient means for interacting with a third party supplier can be provided.

As will be explained below, the benefits from sharing personal data in this way are significant. For an end user, greater privacy and an improved and simplified user experience can be provided. For the third party, i.e. the businesses or suppliers with whom the user is interacting, a reduction in cost can be achieved by the simplification of the digital exchange of data. In addition a reduction in risk is achieved since the third party no longer needs to host and store the private data of its customers.

The use of the graph structured personal data exchange will therefore enable a means for quick and efficient interaction by a user, in a secure manner with a third party.

In an embodiment, the data transfer system comprises an application server arranged in communication with the data exchange, the application server being arranged to run one or more applications and to access selected data nodes within the graph.

In an embodiment, the application or third party is provided with a selected degree of authentication to control access to the data within the data store.

In an embodiment, the controlled levels of access to the data include one or more of, prevention of read access to the third party and permission to the third party to retrieve the selected data.

In an embodiment, the controlled level of access to the data includes permission to the application to read data from the data exchange.

In an embodiment, identification and selection of data is achieved so as to ensure that anonymisation of the identified data.

In an embodiment, anonymisation of the identified data is achieved by identifying an identity data node or any identifying or identifiable data node and excluding said identified node from the set of selected data nodes.

In an embodiment, the data transfer system comprises a unique identifier generator, arranged to generate a unique identifier associated with a selected plurality of nodes.

In an embodiment, the data transfer system is arranged to provide the unique identifier to a plurality of third parties thereby enabling access to the selected plurality of nodes either directly to the third parties or to applications of the third parties running on an application server.

In an embodiment, the data transfer system comprises a sandbox associated the data exchange for the running of application processing logic under control of the user.

Interactive voice response (IVR) systems are well known and in general relate to technology that allows a computer to interact with humans through the use of voice and DTMF tones input via a keypad.

According to a second aspect of the present invention, there is provided a method of operating a data transfer system, wherein the system comprises a data exchange arranged to store data within a graph structure, the method comprising: receiving an identification signal to identify selected nodes within the graph; and generating an output of only the selected node or nodes for sharing shared with an application or third party. IVR systems are a standard telephony system/function, however there are some disadvantages associated with them. In particular, the typical central location of an IVR or its control centre means that a voice channel to a user device is required and a voice port is required per connected user. Though not necessarily high bandwidth, use of a voice port is an expensive and inefficient use of resource, given its primary function is to convey voice encoded data. The lack of useability and convenience associated with navigation through the entirety of a centrally hosted and controlled IVR can be significant. Changing the location of the hosting or storage of the IVR, although in theory possible, is difficult again due to the amount of data involved. However, if there are failures of a communication link between a user engaged with the IVR and the host, e.g. a third party enterprise, during a user’s interaction with the IVR, then the already-stored data at the host can be lost. In other words, answers to questions within the IVR that have already been recorded at the host can be lost.

According to a third aspect of the present invention, there is provided a method of operating an interactive voice response system (IVR), the method comprising: storing upon a host server of a first user the files of an interactive voice response system, the stored files representing a first set of questions of the IVR; mapping data from a second user’s personal data exchange to at least some of the questions of the IVR, and in dependence on the mapped data, generating a second reduced set of questions of the IVR; presenting the reduced question set to the second user for interaction with the interactive voice response system.

In an embodiment, the second user interacts with the IVR by engaging with the IVR using a telephone or computing device.

In an embodiment, the host server stores the IVR as VXML or audio files.

In an embodiment, once the reduced question set has been established, the reduced set is provided to the second user for local storage.

In an embodiment, the second user’s interaction with the IVR is done locally without requiring a voice channel or voice port to the host server of the first user.

In an embodiment, local authentication is performed prior to engagement of the second user with the IVR.

In an embodiment, upon completion of interaction with the IVR an authenticated call is made from the first user to the second user.

According to a fourth aspect of the present invention, there is provided an Interactive Voice Response system (IVR), comprising: a host server of a first user upon which is stored the files of an interactive voice response system, the stored files representing a first set of questions of the IVR; a personal data exchange controlled by a second user; a controller arranged, upon authorisation by a second user, to map data from the personal data exchange of the second user to the first set of questions to provide answers to at least some of the questions of the first set and thereby produce a second reduced set of questions of the IVR; a transfer unit to transfer the reduced question set to a device of the second user for interaction therewith.

In an embodiment, the stored files of the interactive voice response system representing the questions of the IVR, are stored as VXML and/or other appropriate format files and/or audio files by the first user.

In an embodiment, the interactive voice response system is arranged such that transfer of the VXML and/or audio files to the second user’s device enables interaction with the IVR by the second user locally with the VXML and/or audio files.

According to a fifth aspect of the present invention, there is provided an Interactive Voice Response system (IVR), comprising: a host server of a first user upon which is stored the files of an interactive voice response system, the stored files representing a first set of questions of the IVR, the host server being arranged to receive data from a personal data exchange of a second user and map the received data to the first set of questions to provide answers to at least some of the questions of the first set and thereby produce a second reduced set of questions of the IVR; and a transfer unit to transfer the reduced question set to the second user for interaction therewith.

In an embodiment, transfer of VXML and/or audio files is done as a data transfer using IP or other data protocol.

Embodiments of the present invention will now be described in detail with reference to the accompanying drawings, in which:

Figure 1A is a schematic representation of a component view of a data transfer system including a personal data exchange or store;

Figure 1B is a schematic representation of a data structure and management thereof within a personal data exchange;

Figure 2 (incorporating Figures 2A to 2F) is a schematic representation of data processing stages using a personal data exchange;

Figure 3A is a schematic representation of the stages of porting an enterprise using an interactive voice response system;

Figure 3B shows schematically the structure of questions within an IVR and the mapping of data from a data graph on to it;

Figure 4 is a schematic representation of the stages of data transfer in a digital “virtual assistant service” using a personal data exchange for secure anonymised data interactions;

Figure 5 (incorporating Figures 5A to 5H) is a schematic representation of the stages of processing of a credit card payment using a personal data exchange; and

Figure 6 is a schematic representation of a mobile device with a dedicated app running on it for control of a personal data exchange.

Figure 1A is a schematic representation of a component view of a personal data exchange (sometimes referred to herein as a “PDX”) within a larger data transfer system 2. The system 2 is shown as a distributed system which might be arranged over a data transfer network such as the internet. Various components could be provided within interconnecting servers.

The data transfer system 2 includes a personal data exchange PDX 4 arranged in communication with an application server 6 and a hardware security module that hosts a key management system 8. The hardware security module and key management system 8 serve to allocate and manage encryption keys used to secure data within the personal data exchange 4. As will be explained below, in general, the personal data exchange is a means for a user such as a customer or end user to hold and manage their own personal data. Instead, as in the conventional model, of businesses holding personal data regarding their customers, in the present system, the personal data exchange 4 is controlled and managed by an end user. The end user is given the ability to grant or refuse appropriate access to the data to selected third parties. As will further be explained below, this could be a selected business which is running an interface for retrieving personal data. A user, without directly having to interact with the third party supplier, is able to control the data within their PDX 4 to which, the third party supplier is granted access.

As mentioned above, personal data exchanges perse that provide for the secure storage and distribution of personal data are known. However, the present personal data exchange is arranged for combination with other hardware and software components in such a way as to provide a technically new arrangement for the secure storage and exchange of personal data.

Referring again to Figure 1, a user terminal 10 is provided which might be a smart phone or personal computer. Software will run on it, typically in the form of a dedicated app, which, as will be described below (particularly with reference to Figure 6), provides an end user with a convenient, intuitive and secure interface for managing relationships with third parties using both voice and data. Via interaction with the dedicated app 10, a user can authorise the release of data from their PDX 4.

As will be further explained below, the data structure used within the PDX 4 will be that of a graph database. The use of a graph for structuring the data within the PDX 4 enables selective control and anonymization of the data which can be used both to simplify interactions with third party suppliers and also to do so in a manner with enhanced security. As will also be explained below, the system 2 operates based on the establishment of trust relationships between users. An end user is able to define the status of a trust relationship with a 3'"^ party such that, combined with the use of the PDX 4, simplified and efficient communication of selected data is enabled. A trust relationship is essentially an indication of the fact that an end user “trusts” a third party to the extent that the sharing of certain data within the PDX 4 with the third party is enabled. The 3'"^ party will not typically have direct write access to a user’s PDX but may be able to submit data to the user with a request for inclusion in their PDX.

Looking again at Figure 1, the system comprises a messaging server 12 for the control and propagation of messages within the system 2. A web server 14 is provided associated with a third party 16 such as a business or enterprise with which an end user such as a customer might want to engage. A web/app server 18 is provided through which data communications from the user device 10 are channelled.

The present system provides a number of technical improvements in security and speed of engagement with an interface for an end user. Over and above these improvements, the holding of personal data presents risks to institutions. These include the direct financial risk associated with payments that might be due to individuals or other institutions if the security of data on their behalves is breached. There is also the reputational risk to an enterprise holding personal data in the event that the security of the data is breached. The present system of providing a user-control personal data exchange PDX 4 addresses these problems.

The management of data within the personal data exchange 4 will now be described with reference to Figure IB. The PDX 4 is shown schematically as it would be arranged within the overall data transfer system 2 shown in Figure 1. As can be seen, data within the PDX is stored within a graph structure. Typically, the storage of data within the PDX 4 can be based upon a commercial off the shelf graph database technology. However, used within a personal data exchange of the present type, a number of significant technical advantages are derived.

The data within the PDX is represented as nodes 20. Each of the data nodes 20 represents an item of data that could be stored within a database as a data element. The data could include any typically useful personal data but would include items such as. amongst others, name, age, address and health information. The data would be uploaded to the PDX via a user’s device such as the mobile telephone 10 running the mobile app shown in and mentioned above with reference to Figure 1. In one example, the PDX stores some data in the graph database but is associated or provided with a separate database for storage of large data items. These would still have a reference in the graph database but the actual data would be stored, encrypted, in the storage database.

Input/output interfaces 22 and 24 are provided which enable either control data or payload data itself to flow to and from the PDX 4. Control and manipulation of the data is achieved by applications which are granted access to the PDX. The applications would typically be running on the application server 6.

Referring again to Figure 1, the application server 6 is provided in communication with the PDX 4 via a data channel 24. The data channel could be a hard wired communication channel or it could simply represent a data flow within a larger communication network such as the internet. The application server 6 is arranged to host applications that have been granted access to a specific data item or selection of data items in a user’s PDX 4.

Any such applications are able to process the data, the results of which can be submitted back to the user for storage in their PDX 4. A user may elect to share the processed data with a third party enterprise or may choose to share a selected subset of the data with the enterprise, dependent upon the application. In one example, data derived from a car’s telematics systems may be stored within a user’s PDX 4. This data could be used as proof that a user has not broken a speed limit. By choosing to enable the sharing of that specific data with, say, the provider of car insurance, a user can avoid having to manually provide that data to the insurance provider. In other words, by selectively identifying items within a PDX for sharing, a user’s interaction with a third party can be significantly simplified and speeded up. Furthermore, once this subset of a user’s data has been identified it can easily be shared with multiple third parties, without requiring repeated manual input of the data by the user.

Further description will be provided below regarding the grouping of data items within the PDX and how this might be used to enable efficient and secure communication with an enterprise.

Referring again to Figure 1, a key management solution/hardware security module 8 is provided. The use of the PDX 4 within the data transfer system will require a significant number of encryption keys to be generated, stored and managed. It will further require a significant number of public/private encryption keys and associated certificates to be generated, stored and managed. The HSM 8 can be used to run data encryption/decryption algorithms in a secure environment.

An important aspect of use of the PDX 4 within the data transfer system 2 is the ability to anonymise data by selectively grouping data and marking for sharing. Referring to Figure 1B again, an enterprise 26 is shown. The enterprise 26 might, for example, be a third party supplier of a service such as air tickets. A user might want to share with the enterprise 26 details of ages and number of children for the purpose of obtaining a cost estimate and scheduling information for a particular flight. However, it might also be that the user does not want to disclose the precise identities (e.g. names and addresses) of the individuals or indeed of the individual whose PDX is involved. This is achieved by a user identifying the particular nodes in the graph which represent the required data and marking only these nodes as being good for transfer. In the example shown, node 20i, 2O2 and 2O3 are therefore collectively identified as a group 28 of data nodes for sharing with the enterprise 26. The required data could therefore be shared with the enterprise 26.

The data entity nodes themselves would be included in one (or more) packages which were shared with the 3'^^ parties via a trust relationship (one TR per package per 3*^ party).

Thus, the process of communicating with a third party might typically involve the following steps. It is assumed that a trust relationship has been established between the user and the third party enterprise. A trust relationship is established with a third party such as a business or enterprise. Initially, a user authenticates using an interface on the mobile device 10. This could be achieved using a PIN or some biometric authentication.

Identification signal is sent from the mobile device to the PDX 4, to identify data nodes for use in a data transfer. The selected nodes are marked in the PDX 4. Next a request for authenticated secure communication with the enterprise would be sent from the mobile device 10 to the enterprise. This could be communicated to the enterprise 16 by the messaging server 12, i.e. independently of the PDX4. Thus, a first user (the owner or user of the mobile device 10) communicates with the trusted third party via the messaging server 12. Next, a second user, such as an enterprise, provides an application for running on the application server 6. The application is verified and installed. A user, having identified the selected nodes for exchange, then authorises the application to process the identified nodes. It is important to note that during this exchange at no point does the enterprise, as a third party, have ownership of the user’s personal data. It has simply provided an authenticated application for running on the application server and to which the user has granted access to selected data.

The data nodes within the PDX 4 each exists as a single instantiation. Even though certain data points might well be needed and/or used in various applications and shared with a plurality of third parties, the data store is efficient since it does not need to replicate any data items. The identification and marking of data nodes enables a single node easily to be marked as simultaneously being a member of a plurality of subsets.

In a preferred embodiment, the PDX 4 includes a sandbox (not shown) associated with its data storage regions. The sandbox is an area in which enterprise data processing logic may be run under control of the user. The passing of data from this processing logic back to an enterprise is achieved in a manner controller by the user.

The application server 6 provided within the system is a server arranged in communication with the personal data exchange 4 and is a secure environment within which applications provided either by the end user himself or by a third party can be installed and run. Furthermore, it is a location within which data from the personal data exchange 4 can be stored and processed assuming the required permissions and authentications have been provided, as will be described below.

Referring to Figure 2, a system and method using the personal data exchange will now be described by which staged data processing can be achieved.

Initially, an enterprise requests 33 establishment of a trust relationship if one does not exist already (Fig.2A). The trust relationship will allow the enterprise 32 access to the set of user data required for processing. A user 44 opens a dedicated app on his PDA or mobile telephone 46 and goes through required authentication,.e.g. biometric or PIN authentication. The user 44 creates a suitable data package, e.g. by identifying data elements within the PDX that will go into the set of user data. Read permission is granted to the enterprise 32 and the trust relationship is limited to internal read access.

Next (Fig 2B) an App of the enterprise running on the user’s mobile telephone 46 generates personal data such as telematics data. The App uploads this 34 to a user’s PDX with a request that it be included and shared with the enterprise. Again a user (Fig 2C) is required to authenticate and to authorise this uploading and sharing.

An enterprise provides 38 a processing application (Fig 2D). This is verified and installed on the application server. The application server 6 itself can be provided in a sand-box,wil as shown schematically in Figure 2D. The processing application analyses the data and generates analysis data. The analysis data is again submitted to a user for inclusion in the user’s PDX. In Fig 2E, a user authenticates and accepts the analysis data into the personal vault or PDX as a new data entity. The user then (Fig 2F) makes this data entity available to the enterprise.

The end user, via the authentication and/or using additional specific steps, creates the data entity, and grants a party rights to access the data entity within the user’s PDX. The trust relationship that is established is limited to internal read access. This is a significant feature and will be described in greater detail below.

Importantly, the presence of the application server 6 together with the personal data exchange enables a number of levels of authentication to be achieved. A first level is the highest level in which read access to a data entity within the personal data exchange 4 is prevented from the enterprise. In other words, data that is stored within the PDX is specified as not being readable by an enterprise. A next level relates to an application owned by an enterprise but running on the application server 6 which is granted read access to a data entity within the PDX 4. This is classified as “internal read access”. A third level is one in which a remote entity 16 or 26 is directly provided with read access and thereby is able to retrieve and download a data entity from the PDX 4.

The enterprise app which might be provided on the user device 10 generates some personal data such as telematics data. This data is transferred 34 to the end user’s writeable data entity 30 as part of the PDX. The enterprise 36 processing application 38 which is verified and installed on the application server 6 can access this data entity and process or analys identified data to which it has been granted access for the purposes of running a particular app. Analysis or product data is thereby generated. The analysis data is then submitted for storage within the user’s PDX 4. A notification can be sent to the end user who would then open the appropriate app on their device 10 and authenticate the data thereby accepting the analysis data into the personal vault as a new data entity 40. At this stage, the user 42 may choose to make the new data entity, i.e. the analysis data, available to the enterprise directly via a trust relationship.

It is to be noted that herein when the term “vault” is used it signifies an area on a data storage device that functions as the user’s PDX. The PDX may typically be provided as a data storage server and be arranged to store the data of a plurality of users. Each user would consider the data as being stored in their PDX, but in practice it may be a physical or logical area within a data storage server arranged securely to store the data for many users.

Description will now be provided of a specific non-limiting example. An enterprise application such as a health app installed on an end user’s smart device generates personal data relating to the end user and uploads the data to the end user’s PDX. The end user can allow internal read access to this data, allowing an enterprise processing application running on the application server 6 to access the data. The processing application is prevented from exposing any data outside the application server 6 but is able to communicate with the end user, requesting that the generated data be stored within the end user’s personal vault. In other words, the end user has complete control over data transfer within its personal data exchange. The application server 6 does not have the ability to write the analysed data into the personal data exchange 4 without first receiving authorisation from the end user to do so.

Assuming the end user does indeed accept the data into their personal vault, they may choose to allow the enterprise access to the data if appropriate. Thus, the system provides the ability for a user to control access to sensitive personal data, but allow restricted access to the data by a processing application within a controlled environment. This secure system would find utility within a number of applications including, for example, the processing of personal health or medical data, verification of contractual data including the monitoring of car insurance policy stipulations and the like.

Interactive Voice Response (IVR) systems in general relate to technology that allows a computer to interact with humans through the use of voice and dual tone multiple frequency (DTMF) tones input via a keypad. IVR systems are well known, however there are some disadvantages associated with them. In particular, within the internet-connected world, the typical central location of IVR means that voice porting with a user device is always required and high volumes of data can be required for navigation through the entirety of the IVR. Voice porting typically requires dedicated hardware and/or software, thereby increasing the cost and complexity of devices that provide it.

Furthermore, if there are failures of a communication link during a user’s interaction with an existing IVR stored by a third party enterprise, then the already-stored data can be lost. In other words, in interacting with a conventional IVR a user provides answers in the form of voice or button activations. These are stored by the systems or servers of the third party enterprise. If there is a failure of the communication link (or hardware at either end) at some point midway through a user’s navigation through an IVR any already-stored data can be lost. This is clearly undesirable.

Figure 3 is a schematic representation of the stages in establishment of and use and engagement with a distributed IVR making use of a personal data exchange 4 similar to that described above with reference to Figures 1A and 1B.

In particular, the present system enables support for a distributed IVR system that simplifies the end user experience and provides a secure and authenticated means for an enterprise to communicate with their customers.

Figure 3A shows the stages for porting an enterprise IVR system to the current secure data storage system. Porting typically includes reuse of an enterprise’s VXML and audio files making up or forming part of its IVR, in order to maintain enterprise brand adherence for the ported IVR service. The IVR would typically be implemented using VXML files, being the standard for specifying interactive media and voice dialogs between humans and computers. VXML is well known for use in voice response applications such as IVRs.

As will be explained below, the present system provides a number of advantages over conventional IVRs. Indeed, the authentication possible using the combination of the PDX with a user device 10, allows the enterprise to be aware that they are in communication with a confirmed caller.

An enterprise is typically provided with access to end user data held within the PDX 4, wherein the permission is either granted prior to the call or requested during the call.

This, importantly, removes the need for an end user to provide the data as part of the IVR dialogue. The amount of voice data thereby that is need to be transferred between an IVR server and a user’s device is therefore significantly reduced. In particular, by using data stored within a user’s PDX, it is possible for a number of the questions that might originally have been present within an IVR structure, to be “pre-answered” such that they do not need to be asked again within the IVR interaction. This therefore means that fewer questions need to be asked and enables a reduction in the volume of data transfer.

Importantly, the IVR solution can be distributed, with voice prompts to an end user being provided by an end user’s smart device. This removes the need for IVR voice ports and hence reduces costs. This is achieved specifically because via an initial interaction between data stored within the PDX and a VXML or audio file at an enterprise, it can be determined that a smaller number of VXML or audio files are actually needed to complete the IVR interaction. Given the reduced number of questions that will need answering, it becomes feasible to transfer these via a data transfer protocol such as TCP/IP directly to a user’s device. The IVR interaction as far as a user is concerned is then no different from that which would have occurred using a conventional system (apart from the fact that it will be shorter since it will contain fewer questions). However in reality, there has been no actual transfer of voice data over a telephony channel, and hence no need for voice porting.

Rather, simply data has been transferred which is then played back as an audio file on a user’s device. The need for IVR voice ports is therefore reduced and costs can be correspondingly reduced.

The authentication provided by the present system allows an enterprise to provide an authenticated voice call-back to end users. Mutual authentication of end user and enterprise agents helps mitigate against vishing and malicious voice call attacks.

Voice ports are typically found at the intersections of packet-based networks and traditional telephony networks. They facilitate the passing of voice and call signals between the two networks. Physically, voice ports typically connect a router or access server to a line from a circuit switched telephony device in a telephone network such as a public switched telephone network. Typically, voice ports serve to emulate the physical telephony switch connections so that voice calls and their associated signalling can be transferred intact between a packet network and a circuit-switched network or device. The ability to dispense with such complex hardware is advantageous.

The process by which an IVR can be implemented using the present system will now be described with reference to Figure 3A. Initially, an enterprise 32 IVR is ported to the application server 6. The IVR is ported as VXML and voice files. Next, an end user 44 via a mobile phone or computing device 46 authenticates the IVR using the present system.

The end user 44 then navigates to the enterprise IVR. The enterprise VXML and voice files are then downloaded to a user’s device 46. An end user then navigates through the IVR options and the locally stored app captures the end user key selections. The key selections are communicated 48 at completion of the call. The end user may have requested a call back from the enterprise or indeed could elect to add data to the existing enterprise trust relationship to provide requested information. The user’s data store is then able to provide the IVR request to the enterprise along with authenticated end user identity.

If the enterprise requires additional end user data, it is able to request additional end user data using an existing trust relationship.

Next, the enterprise requests an authenticated call back to the end user and provides a call back time and window. The end user may be messaged via his device 46 with the enterprise information and a pair of authentication tokens 50.

The enterprise is also messaged with authentication tokens. Thus, the HSM/KMS 8 serves to provide authentication tokens to both the enterprise 32 and the end user 44 for future use.

Finally, a representative from the enterprise can call the user 52 and quote one of the authentication tokens. The end user can check the token is correct and then quote a second token back to the enterprise to complete the authentication process 54. Thus, by use of the personal data exchange, an efficient and simplified use of an IVR is achieved without the need to provide significant voice porting.

The number of IVR dialogue turns can be reduced, as described above, since some of the user information normally gathered by the IVR is available from the PDX. This reduces IVR call durations and improves end user experiences. This is shown schematically in Figure 3B. On the left of the figure the data structure within a typical PDX 4 is shown.

This is similar to that shown in Figure 1B. However, in this case four data items are marked (crossed) to indicate haring with an IVR. The taxonomy or structure of the questions within the IVR is shown in the right hand section of Figure 3B. Ordinarily, a user would have to answer a question at each branching point during interaction with and passage through the IVR.

For example, the first question 33 might be “What is your age?”. This could be represented by a data point 35 within the PDX. Assuming it has been marked for sharing with the IVR the data is mapped to the IVR and therefore the question 33 of the IVR is effectively pre-answered. The same goes for each of the questions 37, 41 and 45 and corresponding data points 39, 43 and 47. This means that all the other questions forming part of the IVR taxonomy, apart from the final three options 49 are pre-answered or not needed to enable navigation to the very end of the IVR. Instead therefore of having to have VXML or voice files for all questions and branches within the IVR, the only question a user has to actually answer is to make the selection at question 45. In other words, upon receipt of selected data items by a user, those data items that are answers to questions within the IVR taxonomy are processed as answers to questions such that the questions do not need to be asked of a user whilst still enabling progress through the taxonomy to be made. A reduced question set is thus generated out of the remaining questions for which there are no answers provided from the PDX.

Figure 4 is a schematic representation of the stages of data transfer in a digital virtual assistant service, using a personal data source for secure anonymised data interactions.

The general idea behind the virtual assistant service is that by the secure anonymization of data within the personal data exchange 4, it is possible for a user to selectively transfer the same data (e.g. the same instantiation of each data item) to plurai 3'"'' parties such as potential suppliers and thereby generate a number of options for provision of a certain service or product. In other words, the anonymised data within the personal data exchange running on the system is able to act as a “virtual assistant” for the user by independently, anonymously and securely obtaining data from a number of potential suppliers. The method relies upon the granting of access by the end user from a first device to specific data items within a PDX4, to second devices belonging to, or under the control, of independent third parties, in order to provide a service. Examples include the obtaining of insurance quotes from a number of insurance providers and the identification of potential energy suppliers and obtaining of quotes for this service based upon actual energy consumption.

The virtual assistant service thus provides an end user with some “service” using data supplied from the end user’s PDX data. Furthermore, it functions to enable the release of anonymised data to one or more 3'"^ parties.

The initiation of the virtual assistant service preferably starts from an end user. Alternatively, the personal data exchange itself could generate a reminder for the forthcoming expiry of an existing insurance policy. In either case, the end user creates a trust relationship with the virtual assistant service to share the information required. The information could include, for example, the house postcode, a figure for the cover required for a contents insurance quote, details of any other required data element can be included. The virtual assistant service will then use this information to provide the requested service.

In the case of a house contents renewal quote, the virtual assistant service will share the end user’s information with a number of potential insurance providers, either by messaging or using a trust relationship with the provider if such relationship already exists. Importantly, the virtual assistant service will only release the data that is required to achieve the service request. For example, in the case of an insurance quote, the identity of the end user would not need to be passed to the insurance company at this stage. Thus, anonymization of the user is enabled by this service. Having received one or more quotes from the potential suppliers, the virtual assistant service is arranged to forward these to the end user. If the end user wishes to take up one of the offers they are able to accept the offer by messaging back to the selected provider and establishing a trust relationship with the selected provider so as to allow access to any additional information required.

Thus the virtual assistant service is achieved by the Application server hosting virtual assistant processes, instigated by an end user and data processing processes that will generally be instigated by a party.

Figure 4 shows an example of the possible stages of data transfer within the present system required for implementing a virtual assistant service as described above. Initially, in the example shown, the personal data exchange will send a message to an end user to offer to obtain a set of competitive quotes for an end user, such as renewal of house contents insurance. In the example shown, the initiation of the process starts with the personal data exchange, however it could be initiated by the end user himself.

Next, the end user 58 opens the dedicated app on his personal digital assistant or mobile telephone and provides the required authentication, e.g. with the use of a PIN, use of some biometric authentication or any other desired means of providing authentication. The end user then accepts the offer to obtain competitive service quotes. Next, the PDX communicates 62 with the user 58 requesting access to a particular data set required to obtain the various estimates or quotes. If a defined data package, i.e. selected group of data items within the PDX 4, does not already exist the end user at this stage defines it by communication 64 with the personal data exchange or application server 6. Simultaneously, a trust relationship is established with the virtual assistant service within the application server 6. The data set does not identify the end user and so in the next step when the data set is sent 66 to various potential enterprises or suppliers, there is no explicit identification of the user 58. Thus, the information is conveyed to the suppliers whilst maintaining anonymity of the user.

Next, the enterprises submit quotes or estimates 68 to the application server 6. The virtual assistant service running on the application server 6 then provides the details of the quotes to the user 58. Alternatively, or in addition, the estimates can be submitted to a user as messages via the messaging server 12. The user 58 can then make a selection of a desired provider and either via the application server 6 or directly communicate with the provider 72 to complete the transaction. Furthermore, the additional personal information that is required by the enterprise is at this stage authorised by the end user 58 and provided by the virtual assistant service running on the application server to the enterprise 72. A user therefore is able to securely transfer anonymised data simultaneously to a plurality of potential providers obtaining various quotes in a secure and efficient manner. A two stage data transfer is achieved. A first anonymous data set is sent via the data exchange 4 to a number of suppliers or enterprises. The suppliers or enterprises then provide requested response which could be an estimate or any other type of parameter dependent data response. These are then communicated to the user and upon acceptance by the user of one specific estimate from one particular supplier or enterprise, a second level of data transfer is actioned whereby the user is identified so as to enable completion of the transaction.

In one embodiment, temporary identifiers are used in situations when an end-user wishes to share a set of anonymised data. A temporary identifier provides a means of anonymously “identifying” the sender to enable subsequent the collection and collating of responses. This anonymous “identification” provides a means by which association of a user with a particuiar data set can be achieved without actuai personai identification. For exampie, an end-user desires to use the virtuai assistant to request competitive insurance quotes. The virtuai assistant creates a temporary id for the end-user which is stored in the end-user’s PDX and shared back to the user device app via a trust reiationship. The temporary id is inciuded in the data sent to the insurance companies. This aiiows the insurance company to respond with quotes or estimates that inciude the identifier. The Messaging Server 12 iooks up the temporary identifier and directs the quotes to the correct end-user for their consideration. Temporary identifiers can be discarded by an end-user once no ionger required.

Figure 5 shows a schematic representation of the stages of processing of a credit card payment using a personai data exchange or store such as that shown in Figure IB.

The structure of the data exchange 4 and its position within a iarger data transfer system such as that shown in Figure 1 is as previousiy described. However the specific steps that might be invoived in the use of such an exchange in making a payment for an articie wiii now be described.

Starting at Figure 5A, initiaiiy a user 58 having made a seiection from a merchant’s website, then seiects the use of a dedicated app on his mobiie phone (as the means for making the payment) so as to make use of his PDX 56. A merchant then requests payment for the purchase and required data from the application server 6 and PDX 56. This data might include delivery address and payment details.

The application server 6 requests payment information from the end user (Fig. 5B). The end user opens the dedicated app on his personal device 60 if it is not already open and provides the required authentication. As previously, this can be via the input of a PIN or biometric identification. The dedicated app running on the device 60 then connects 61 to the PDX 56, e.g. via the application server 6 (not shown in Figure 5). The application server 6 requests credit card information to be used for merchant payment and once it is received, the application server 6 (in Fig. 5C) passes the merchant and card details to a payment gateway (Fig 5C).

The payment gateway 63 subsequently (Fig. 5D) passes 65 durable credit card tokens for merchant payments back to the application server 6 or PDX 56. The application server 6 or PDX 56 provides the end user with merchant payment token 67 for acceptance into the end user’s PDX 56. The end user accepts this and stores 69 the tokens accordingly within the PDX 56. The tokens themselves need not actually be communicated to the user 60, but the communications referred to may be any of requests for transfer, requests for storage and authorisations.

Next (Fig 5E), the end user creates a data package within the PDX 56 and establishes a trust relationship with a merchant. The application server 6 requests an end user to authorise payment. This is done, via appropriate authentication steps, and in doing so the end user authorises the sharing of any additional data required by the merchant via a trust relationship.

Next (Fig. 5G), the application server requests payment to the merchant from the payment gateway using the credit card token and the merchant is notified of a successful transaction. Finally (Fig. 5H), the merchant can retrieve any additional data required for delivery of the product to the end user, via the application server 6 and/or the PDX 56.

The service running on the application server 6 will include the ability to handle a credit card payment between an enterprise and an end user. External payment gateway service providers can be used, e.g. PayPal, ora dedicated payment gateway service could be established and provided as part of the system.

When an end user makes a purchase from a merchant that is an authorised enterprise, they are able to select the making of payments using the dedicated app. If the end user has previously made payments to the merchant using the dedicated app, there will be a tokenised credit card stored in the personal data exchange that can be used for the purchase. If this is the first time that the end user has used the dedicated app to make a payment to the merchant, the end user will be prompted to provide credit card details for the purchase. However these may already be stored in the end user’s personal data exchange 4 in which case they can be shared from there under a trust relationship.

The credit card details will be passed to a payment gateway service which will securely lodge the details and send a tokenised version of the credit card back to the application server. The application server will then forward the token to the end user, requesting that it is stored in their PDX 4 as described above.

Using marking and identification of data within their personal data exchange, an end user may elect to share personal data with a merchant using an appropriate package of data. The personal data exchange provides the token to the end user, requesting that it is stored in the personal vault. The application server will forward the token to the end user, requesting that it is stored in their personal vault. The end user may elect to share personal data with the merchant using an appropriate package of data and the establishment of a trust relationship such as name, delivery address and the like. The application server will request authorisation from the end user for payment to the merchant. Providing this is granted, a tokenised credit card wiii be sent aiong with the payment detaiis to the payment gateway and the merchant notified that the payment has been made.

Thus, the architecture of the system with the personai data exchange and appiication server enabies secure and efficient payments to be made and interactions between customers and suppiiers to be achieved.

Reference has been made above to a dedicated app for use on a user’s mobiie device such as a mobiie teiephone, tabiet computer or PDA. An exampie of a graphicai user interface (GUi) for use within such an app wiii now be described with reference to Figure 6.

The interface is shown in a state as it might appear on a user’s mobiie teiephone.

The interface 74 has a number of message regions 76 each representing a request or caii for action or response from the user. As indicted the requests in this exampie inciude each of a request for a revised Trust Reiationship, a request for a caii back to a suppiier, a request for information, such as a meter reading on a eiectricity or gas meter from a utiiity suppiier and an update on flight status, such as a flight arrivai. in addition navigation keys 78 are provided which enabie a user to navigate the app. These inciude keys to take a user to a message screen or a graphicai dispiay of the user’s personai vauit.

Embodiments of the present invention have been described with particuiar reference to the exampies iiiustrated. However, it wiii be appreciated that variations and modifications may be made to the exampies described within the scope of the present invention.

Claims (31)

Claims

1. An Interactive Voice Response system (IVR), comprising: a host server of a first user upon which is stored the files of an interactive voice response system, the stored files representing a first set of questions of the IVR; a personal data exchange controlled by a second user; a controller arranged, upon authorisation by a second user, to map data from a personal data exchange of the second user to the first set of questions to provide answers to at least some of the questions of the first set and thereby produce a second reduced set of questions of the IVR; a transfer unit to transfer the reduced question set to a device of the second user for interaction therewith.

2. An interactive voice response system according to claim 1, wherein the stored files of the interactive voice response system representing the questions of the IVR, are stored as VXML and/or other appropriate format files and/or audio files by the first user.

3. An interactive voice response system according to claim 1 or 2, arranged such that transfer of the VXML and/or audio files to the second user’s device enables interaction with the IVR by the second user locally with the VXML and/or audio files.

4. An interactive voice response system according to claim 1 or 2, wherein transfer of VXML and/or audio files is done as a data transfer using IP or other data protocol.

5. An Interactive Voice Response system (IVR), comprising: a host server of a first user upon which is stored the files of an interactive voice response system, the stored files representing a first set of questions of the IVR, the host server being arranged to receive data from a personal data exchange of a second user and map the received data to the first set of questions to provide answers to at least some of the questions of the first set and thereby produce a second reduced set of questions of the IVR; a transfer unit to transfer the reduced question set to a device of the second user for interaction therewith.

6. A method of operating an interactive voice response system (IVR), the method comprising: storing upon a host server of a first user the files of an interactive voice response system, the stored files representing a first set of questions of the IVR; receiving and mapping data from a second user’s personal data exchange to at least some of the questions of the IVR, and in dependence on the mapped data, generating a second reduced set of questions of the IVR; providing the reduced question set to the second user for interaction with the interactive voice response system.

7. A method according to claim 6, in which the second user interacts with the IVR by engaging with the IVR using a telephone or computing device.

8. A method according to claim 6 or 7, in which the host server stores the IVR as VXML or audio files.

9. A method according to any of claims 6 to 8, in which once the reduced question set has been established, the reduced set is provided to the second user for local storage.

10. A method according to any of claims 6 to 9, in which the second user’s interaction with the IVR is done locally without requiring a voice channel or voice port to the host server of the first user.

11. A method according to any of claims 6 to 10, in which local authentication is performed prior to engagement of the second user with the IVR.

12. A method according to claim 11, in which upon completion of interaction with the IVR an authenticated call is made from the first user to the second user.

13. A method according to any of claims 6 to 12, in which the data for mapping is stored within the personal data exchange in a graph structure and selection is achieved by a user identifying graph nodes for transfer and mapping.

14. A method according to any of claim 13, in which upon receipt of the selected data, data items that have answers are processed as answers to questions and the reduced question set is generated out of the remaining questions.

15. A data transfer system, the system comprising: a data exchange arranged to store data within a graph structure, an input for receipt of an identification signal arranged upon receipt of a user input to identify selected nodes within the graph, an output enabling only the selected node or nodes to be shared with an application or third party.

16. A data transfer system according to claim 15, comprising an application server arranged in communication with the data exchange, the application server being arranged to run one or more applications and to access selected data nodes within the graph.

17. A data transfer system according to claim 16, wherein the application or third party is provided with a selected degree of authentication to control access to the data within the data store.

18. A data transfer system according to claim 17, wherein the controlled levels of access to the data include one or more of, prevention of read access to the third party and permission to the third party to retrieve the selected data.

19. A data transfer system according to claim 17, wherein the controlled level of access to the data includes permission to the application to read data from the data exchange.

20. A data transfer system according to any of claims 15 to 19, in which identification and selection of data is achieved so as to ensure that anonymisation of the identified data.

21. A data transfer system according to claim 20, wherein anonymisation of the identified data is achieved by identifying an identity data node or any identifying or identifiable data node and excluding said identified node from the set of selected data nodes.

22. A data transfer system according to any of claims 15 to 21, comprising a unique identifier generator, arranged to generate a unique identifier associated with a selected plurality of nodes.

23. A data transfer system according to claim 22, arranged to provide the unique identifier to a plurality of third parties thereby enabling access to the selected plurality of nodes either directly to the third parties or to applications of the third parties running on an application server.

24. A data transfer system according to any of claims 15 to 23, comprising a sandbox associated the data exchange for the running of application processing logic under control of the user.

25. A method of operating a data transfer system, wherein the system comprises a data exchange arranged to store data within a graph structure, the method comprising: receiving an identification signal to identify selected nodes within the graph, generating an output of only the selected node or nodes for sharing shared with an application or third party.

26. A method according to claim 25, wherein the data transfer system is a data transfer a system according to any of claims 15 to 24.

27. Computer readable code, optionally stored on a medium, which, when executed by a computer causes the computer to perform the method of any of claims 6 to 14.

28. A computer, comprising a processor and memory, the memory having stored thereon computer readable code, which, when executed by a computer causes the computer to perform the method of any of claims 6 to 14.

29. An Interactive Voice Response system (IVR) substantially as shown in and/or described with reference to any one or more of Figures 1 to 6 of the accompanying drawings.

30. A method of operating an interactive voice response system (IVR), the method being substantially as shown in and/or described with reference to any one or more of Figures 1 to 6 of the accompanying drawings.

31. A data transfer system, the system being substantially as shown in and/or described with reference to any one or more of Figures 1 to 6 of the accompanying drawings.