GB2572323A - Systems and methods for an identity-centri application layer protocol to HTTP gateway - Google Patents

Abstract

An identity-centric application layer protocol to HTTP gateway provided between a client entity 7 and plural servers 5. A gateway device 25 receives an identity-centric application layer protocol query identifying an entity associated with the query. One of plural devices 25 providing the gateway service is assigned to the entity and a communication session is established by the client responsive to receiving the network address of the assigned device. The device identifies a first data attribute based on the received query and determines a second data attribute with a relationship 27 to the first data attribute, the second data attribute associated with a server of the plurality of servers from which information is obtained. The device generates an HTTP request that identifies the determined second data attribute and the entity associated with the query, for transmission to the associated server. An entity (e.g. user) may be assigned to more than one gateway device with queries having different contexts being directed to respective different devices. A name server 29 may be provided to supply the client entity with the network (IP) address of the assigned gateway device.

Description

[0001] This invention relates generally to data communication networks, and more particularly to systems and methods for an identity-centric application layer protocol to HTTP gateway.

Background [0002] In conventional client-server environments, a client and server may communicate requests for and provision of data using application layer protocols and session layer protocols over various transport layer connections. Current tools and solutions in the particular context of Internet data services are typically based on the established HyperText Transfer Protocol (HTTP), which enables device independent use across multi-platforms. However, the disparate data service providers are typically not linked, as each entity owns and maintains user personal data effectively within a walled garden, with controlled access provided via application programming interfaces (APIs). Consequently, users of such conventional systems are required to establish separate network sessions with each of a plurality of data service providers, which is tedious and inefficient. Moreover, the users often receive sub-optimal information from each one of the individual data sources, leaving the user to manually connect the dots between received information in order to resolve a complex query.

[0003] Various forms of systems have been explored to provide better handling of data requests, for example to respond to more general requests for data related to a context. For example, US2009/0325602 discussing a system for selecting and presenting media which relates to a specific topic or context. US2016/0179940 discusses a system for responding to data requests related to constrained natural language vocabulary terms. US2016/0378854 discusses a system for supporting natural language queries and requests against a user’s personal data cloud. EP2020796 discusses a system for accessing user data and profile management. However, such systems still suffer from the problem of providing sub-optimal information since the individual data sources remain as separate data service providers.

[0004] Figure 1 schematically illustrates the typical network architecture of such conventional systems 1 for handling queries that are directly or indirectly related to personal data stored in respective third party data stores 3 of individual and separate data service providers 5. Requests for retrieval or action servicing of personal data assets are transmitted from client computing devices 7 to respective processing servers 9 of each data service provider 5, for example over a data network 11 (e.g. the Internet) via respective application programming interfaces (APIs) 13 implemented by the data service providers 5. As is well-known in the art, a domain name server (DNS) 15 is an Internet service that translates human readable domain names, for example of the data service providers 5, into IP addresses. Typically, when a client requests access to a resource on a server 9, the client 7 contacts a DNS 15 to request an IP address corresponding to a given domain name. The DNS 15 generally responds by providing the IP address for the domain name or a forwarding address for another DNS 15 to resolve the DNS request.

[0005] Some of the data service providers 5-3 may be configured with additional functionality to act as a “majordomo” of personal data collected from other data stores 3, and to build and maintain person-centric data relationship models 17 that define associations between information in the collected personal data that is stored centrally by the personal data majordomo 5-3. A query processing server 9-3 of the personal data majordomo 5-3 can then utilise the centralised data relationship models 17 in order to predict appropriate responses to received queries. Examples of such personal data majordomos can be found in US2017097939, US2014280107, US2011320441, US2014108445 and US2017308583. Users can be wary of such majordomo-based platforms, with reluctance to give ownership of all their personal data to a central entity. [0006] What is desired is an efficient and effective network protocol and architecture that addresses modelling data inter-relationships, rather than issues with latency and linkage as tackled by existing web protocols. As a further benefit, it is greatly desirable to allow users to decide and control what services to use for predictive query handling, and to have sovereignty over their own personal data.

Summary of the Invention [0007] Aspects of the present invention are set out in the accompanying claims.

[0008] According to one aspect, the present invention provides a method for providing an identity-centric application layer protocol to HyperText Transfer Protocol (HTTP) gateway via a network system between a client and a plurality of servers, the method comprising: receiving, by a device of a plurality of devices in the network system, an identity-centric application layer protocol query via a communication session with the client, wherein the identity-centric application layer protocol query identifies an entity associated with the query, and wherein the communication session is established by the client responsive to receiving a network address of the device that is associated with the entity; identifying, by the device, a first data attribute based on the received query; determining, by the device, a second data attribute with a relationship to the first data attribute, the second data attribute associated with a server of the plurality of servers; and generating, by the device responsive to the determining of the second data attribute and for transmission to the associated server via HTTP, an HTTP request that identifies the determined second data attribute and the entity associated with the identity-centric application layer protocol query.

[0009] The method may further comprise transmitting, by the client to a name server, a request to lookup the network address of the device that is associated with the entity, the request including the entity identifier.

[0010] The device may determine a plurality of related query parameters, each associated with a corresponding server of the plurality of servers, and generate a plurality of HTTP requests, each comprising a corresponding determined related query parameter and the identifier of the entity associated with the identity-centric application layer protocol query. The device may combine information from incoming responses to the plurality of HTTP requests received from the servers, to form an identity-centric application layer protocol response.

[0011] The method may further comprise inserting, by the device, an entity identifier in an HTTP header of the generated HTTP request, the entity identifier indicating that the HTTP request is created from an identity-centric application layer protocol query.

[0012] The device may determine a second data attribute with a relationship to the first data attribute using an identity-centric data relationship model. The model may comprise data defining a rules engine or a trained neural network that encapsulates rules of relationships between data assets. The model may be trained from a data set of historical queries and responses, using a machine learning algorithm, and updated based on new queries and processed responses.

[0013] According to another aspect, the present invention provides a method of implementing people as application layer objects in a computing environment, the method comprising for an entity identified in an application layer protocol query, identifying a network address of a server storing data defining an identity-centric data relationship model of the identity; receiving, at the server identified by the network address, the application layer protocol query; for a first data attribute identified in the query, identifying, by the server, a second data attribute with a relationship to the first data attribute as defined by the identity-centric data relationship model; retrieving, from a data store, information related to the identity and the identified second data attribute, such that the information related to the entity is not stored in the identity-centric data relationship model of the entity; using the retrieved information to resolve the application layer protocol query; and displaying in a user interface for the entity a result of the resolved query.

[0014] In another aspect, the present invention provides a computer implemented method of querying an identity-centric lookup table at a device in a computer network, the identity-centric lookup table having entries which are accessible using an entity identifier, the method comprising identifying a network address by querying the identity-centric lookup table for an entity identifier, and transmitting an identity-centric application layer protocol request to a server at the identified network address, wherein the request is resolved using an identity-centric data relationship model at the server.

[0015] In another aspect, the present invention provides a system comprising a plurality of servers, each server associated with a respective entity and having a unique network address; and at least one name server stores an address book of server IP addresses mapped to corresponding unique entity identifiers; wherein each server is configured to receive a query identifying an entity and at least one data asset, and determine one or more related assets using a data model stored on the individual server, the data model defining relationships between related assets for the associated entity.

[0016] Each server may be assigned a unique IP address, and a private namespace server stores an address book of server IP addresses mapped to corresponding unique entity identifiers. Each server may respond with a list of respective addresses of additional servers for each related assets, where each additional server is configured to retrieve that entity’s personal data via an API. The determined related assets may be used to generate customised or related queries.

[0017] The data relationship model may be trained from historical data defining previous interactions with the system, and/or user input defining a relationship between at least two data assets. The resolved query may include one or more network addresses representing where information for the resolved query is stored or retrievable.

[0018] In other aspects, there are provided systems and devices configured to perform the methods as described above. In a further aspect, there is provided a computer program comprising machine readable instructions arranged to cause a programmable device to carry out the any one of the methods as described above.

Brief Description of the Drawings [0019] There now follows, by way of example only, a detailed description of embodiments of the present invention, with references to the figures identified below.

[0020] Figure 1 (prior art) is a schematic diagram showing a traditional system of retrieval and organisation of personal information from different data stores.

[0021] Figure 2 is a block diagram showing the exemplary components of an identitycentric data processing system, according to an embodiment of the invention.

[0022] Figure 3 is a block flow diagram showing functional components of entities in the system of Figure 2, according to an embodiment of the invention.

[0023] Figure 4 is a block flow diagram showing functional components of entities in the system of Figure 2, according to another embodiment of the invention.

[0024] Figure 5 is a flow diagram illustrating the exemplary processing steps performed by the system of Figure 2 to register a new identity-centric server, according to an embodiment.

[0025] Figure 6, which comprises Figures 6A to 6D, is a flow diagram illustrating exemplary processing steps performed by the system of Figure 1 to process a query, according to an embodiment.

[0026] Figure 7, which comprises Figures 7A to 7F, are exemplary user interface screens output by a client computing device.

[0027] Figure 8 is a block diagram showing the exemplary components of another identity-centric data processing system, according to an alternative embodiment of the invention.

[0028] Figure 9 is a diagram of an example of a computer system on which one or more of the functions of the embodiments may be implemented.

Description of Embodiments [0029] A specific embodiment of the invention will now be described, using corresponding reference numerals to those of Figure 1 where appropriate for corresponding elements, for a process of implementing identity (e.g. of a person or entity) as an application layer construct, such that an application layer query identifying the person or entity is processed in a novel way, by a novel network protocol and system architecture. Unlike the traditional approach to retrieve personal or private data from a plurality of data stores and organise information in a centralised personal data majordomo, as illustrated in Figure 1, the identity-centric data processing system 21 shown in Figure 2 provides a network 23 of individual identity-centric servers 251.. ,25-n forming a dynamically evolving cognitive response system that can be used for query suggestions based on personal information retained in the third party data stores 3. Each identity-centric server 25 is associated with a respective entity of the system 21 having a corresponding unique entity identifier, and can respond to queries using a corresponding trained identity-centric data relationship model 27 that defines relationships between abstractions of the personal data 3. The identity-centric servers 25 may be implemented as respective individual physical or virtual servers, or combinations thereof.

[0030] In this embodiment, each data relationship model 27 defines relationships between related assets for the associated entity, for example based on abstracted attributes of the personal data such as a data source (e.g. identity of the associated data service provider 5) and/or asset type, instead of the personal data 3 values themselves. Each data relationship model 27 may be trained and updated based on historical data defining previous interactions with the system such as past queries and responses, and/or user input defining or modifying a relationship between data assets. The identitycentric servers 25, in conjunction with the corresponding data relationship models 27, utilise rules engines and/or neural networks to encapsulate rules of relationships between assets.

[0031] Each identity-centric server 25 is assigned a unique network address, typically an IP address. The unique network address of each identity-centric server 25 may be calculated based on the corresponding entity’s identifier and data relationship model 27, using a defined algorithm. A plurality of entity name servers 29, distinct from the conventional DNSs 25 in the network 11, collectively store data defining an address book of identity-centric server network addresses mapped to the corresponding unique entity identifiers, for example as a lookup table. Each identity-centric server 25 is configured to receive a query from an application running on a client computing device 7, via the network 11. Each query is an identity-centric application layer protocol request for an action in relation to one or more specified query parameters, the identitycentric application layer protocol defining how the entity identifier is to be included in the identity-centric request. In this embodiment, the received query also includes data identifying an intended command or request type, and one or more query parameters, such as a target data type, data source, etc. Responsive to the received request, the identity-centric server 25 determines one or more related assets based on elements identified in the request, using the corresponding data relationship model 27 of the entity who is making the request, as stored at the server 25.

[0032] Advantageously, this means that the identity of the entity who requests an asset determines the data relationship model 27 that is used to determine what relationship that asset has to other related assets. Furthermore, the identity-centric network 23 does not itself retain the entities’ personal data in data stores. Instead, each identity-centric server 25 interacts with the data service providers 5 via respective ones of a plurality of interface servers 31-1...31-m in the identity-centric network 23. Each interface server is configured to request information from a personal database 3 and/or issue action service requests to a data service provider 5, for example as identified by the output of a data relationship model 27, via APIs 13 provided by the respective data service provider

5. One or more interface servers 31 may be provided to access personal data stored on an entity’s computing device 7, for example via an API of an application running on the device 7 (e.g. the entity’s local calendar, mail, health data tracking app, contact list, etc.).

[0033] The identity-centric network 23 can include a network management server 45, having processing modules for example to provide for registration of new entities and corresponding individual identity-centric servers 25, and to create new interface servers 31 for connection to personal data 3 at a new data service provider 5 via corresponding APIs 13. The data service provider servers 9 may be referred to as one or more of a file server, application server, web server, proxy server, or gateway server. Each data service provider server 9 may have the capacity to function as either an application server or as a master application server. The client computing devices 7 may be referred to as client nodes or endpoints. Each client 7 may be configured to function as both a client node seeking access to applications on a server and as an application server itself providing access to hosted applications for other clients 7. It should be appreciated that the system 21 may include other components, sub-components, modules, and devices commonly found in a computing system/server, which are not illustrated in the Figures for clarity of the description.

[0034] The network 11 may be any type and/or form of network and may include any one or more of the following: a point to point network, a broadcast network, a wide area network, a local area network, a telecommunications network, a data communication network, a computer network, an ATM (Asynchronous Transfer Mode) network, a SONET (Synchronous Optical Network) network, a SDH (Synchronous Digital Hierarchy) network, a wireless network and a wireline network. The topology of the network 11 may be. The network topology may be of any such network topology as known to those ordinarily skilled in the art capable of supporting the operations described herein, such as a bus, star, or ring network topology. Although the servers of the identity-centric network 23 are shown as connected to the same network 11, the identity-centric servers 25 and interface servers 31 may be on a separate network 1Γ, such as a local-area network (LAN), a metropolitan area network (MAN) or a wide area network (WAN), in communication with the network 11, which may be the Internet or the World Wide Web.

[0035] The main components in the identity-centric data processing system 21 will now be described in more detail with reference to Figure 3, which shows the processing elements of an exemplary identity-centric server 25 used to process and respond to a received query from a client computing device 7, according to an embodiment of the present invention. As shown, the identity-centric server 25 includes a query handler module 33 that receives a query from a client computing device 7 and processes the received query, in conjunction with a prediction engine 35 and the data relationship model 27 of the entity who is making the request. The query handler 33 can process the query to identify one or more action objects (e.g. intended commands or request types), and at least one query parameter. In this embodiment, the query parameter is a data attribute associated with a data service provider 5, such as a target data asset type, an identifier of the data asset source, etc. The query parameters may additionally include data from the client computing device 7 relating to the contextual environment (e.g. geolocation and activity data indicative of where a user is and what they’re doing), state of self (e.g. captured biometric data indicative of how the user is feeling), utilisation (e.g. device and software metadata indicative of what tools the entity is using to carry out a task), and dynamic and static preferences (e.g. as defined or stated by the entity, or preference data that the client knows or stores for the entity).

[0036] The prediction engine 35 can determine related query parameters and/or related query suggestions, based on the action objects and query parameters identified from the request, using the corresponding data relationship model 27 that defines relationships between abstractions of the corresponding entity’s personal data 3. The query handler 33 can respond to a received query based on the related query parameters and/or related query suggestions determined by the prediction engine 35. For example, in order to complete the task of resolving a search query or executing a data service instruction, the query handler 33 can use the prediction engine 35 to determine one or more related query parameters, such as a related data asset or asset type associated with a respective data service provider 5, then retrieve the entity’s personal information associated with the related data asset(s) from the data service provider 5, using a data collector module 37 of the corresponding interface server 31. The query handler 33 can also use the prediction engine 35 to determine one or more related queries or action service requests associated with a respective data service provider 5, then use an action service module 39 of the corresponding interface server 31 to execute the related queries or action service requests. The data collector modules 37 and the action service modules 39 can each implement respective APIs of the corresponding data service provider 5.

[0037] The defined data relationships in the identity-centric model 27 can be updated using an updater module 41, for example responsive to historical data from the query handler 33 defining previous interactions with the server 25 such as past queries and responses, and/or user input defining or modifying relationships between data assets received through a user interface to the identity-centric model updater 41. As the identity-centric data relationship model 27 is updated, an updated network address of the corresponding identity-centric server 25 may be calculated using a network address calculator 43 that implements the defined calculation algorithm. It is appreciated that the specific algorithm for calculating a network address will depend on the data structure of the trained models 27. The network address calculator 43 can send the updated network address for the associated entity identifier as a server address update to the identity-centric namespace servers 29. Although the identity-centric model updater 41 and the network address calculator 43 are shown as components of each identitycentric server 25, it is appreciated that these components could be implemented as processing modules of the network management server 45.

[0038] The system 21 may also include a network management server 45 that can be used to create a new identity-centric server 25, for example in response to registration of a new entity via a registration module 47. The network management server 45 can also maintain a global data relationship model 49, defining a set of core relationships between abstractions of personal data 3 across all registered entities of the system 21. The defined data relationships in the global model 49 can be updated using a global model updater module 51, for example responsive to data relating to updates to a trained identity-centric data relationship model 27, which can be received from the model updater module 41 of the corresponding identity-centric server 25. For example, the global data relationship model 49 may capture learned or identified trends in abstractions of entity behavior, for example a trend of searching for a hotel then flight then preference due to flight loyalty scheme. Identified trends can then be used by a prediction engine 35 to determine a propensity for the next entity who wants to book a holiday.

[0039] Figure 4 is a block diagram illustrating an alternative embodiment, using corresponding reference numerals to those of preceding figures where appropriate for corresponding elements. In this embodiment, the functionality of the prediction engine 35 is provided by a prediction server 35’ of the identity-centric network 23, and accessible to each identity-centric server 25 via a prediction server interface 35a to a prediction engine API 35b. Additionally, the functionality of the individual interface servers 31 can instead be provided as respective interface modules 31’ of the prediction server 31’.

[0040] Advantageously, the network and system architecture of the present embodiments enables the identity-centric server to resolve queries with a complex combination of derived related query parameters, as well as deriving suggested related queries and action services, all of direct and unique relevance to the entity making the original query. For example, the identity-centric server 25 responding to the query “Where can we go as a short break that is good for walking and is relatively near a good pub lunch venue? ”, is able to determine a suggested venue that meets the identified query parameters, and then use the action service module 39 of the interface server 31 corresponding to a venue booking data service provider, to determine and execute suggested action services to query what times are busiest, identify an available table meeting the entity’s timing preference (e.g. in quieter times), then reserve the table for the entity (e.g. taking into account venue preferences such as the type of table they like, by a window if possible).

[0041] Throughout the interaction process, the entity's identity-centric data relationship model 27 can be updated and re-trained, for example based on user input responses to confirm or reject suggested queries, query parameters and predicted responses, using machine learning to create other observations and questions in the background, for example based on inferences from the new data points within the identity-centric network 23. By updating and re-training a global model 49, the identity-centric network 23 additionally provides for improved query handling with more accurate and entityrelevant suggestions and predictions, that is based not just from one profile but from many, all of which can dynamically update each other depending on the new observations and questions.

[0042] As another example query and response case, where a particular entity hasn’t yet expressed a preference for vegetarian food, but has mentioned a concern over their own blood pressure, that entity’s identity-centric server 25 could start building an observation in the corresponding model 27 that there may be a link between the entity’s food preferences and their blood pressure. A few weeks later the entity may start a health kick and one of the data points communicated to the entity’s identity-centric server 25 is that they would like to have a nutritional plan created that may reduce blood pressure. Responsive to such a query, the identity-centric server 25 will be a few steps ahead and not only can suggest that plan, but also populate the entity's supermarket order. A few months later, when the entity is looking at their next short break, entity’s identity-centric server 25 can suggest eating venues that serve the type of food that suits the entity’s new diet, within the walking vicinity known to be preferred (unless the entity changes their preference, either by observed behaviour or by answering a prompted question).

[0043] As yet another exemplary use case, the query could be for an entity to use their identity-centric server 25 to look for a new job, and the server 25 can not only identify and execute a search request to a job listing data service provider, but then additionally predict related attributes of relevance to the query, for example based on that entity’s past preferences to identify and add to the list of suggested employment opportunities found, in order to suggest job openings that are more likely relevant to that entity, such as those listings that are in locations with excellent transport links to the short break venues the entity prefers, and employers who have in-house medical check-ups and great chefs who cater for all types of nutritional plans.

[0044] Figure 5 is a flow diagram of an example computer-implemented process of registering a new identity-centric server 25, according to an embodiment. At step S5-1, the client computing device 7 establishes a network session with the network management server 45, for example via a user interface to the registration module 47. At step S5-3, the client computing device 7 receives user input of profile data associated with a unique entity identifier, and transmits the input profile data to the network management server 45. The entity identifier may be defined by the user at the client computing device 7 and checked for validity by the registration module 47 against a database of other registered entity identifiers, or may be generated by the registration module 47.

[0045] The user interface to the registration module 47 may be configured to present a sequence of registration questions to the user and prompt for input of entity profile information by way of responses. The questions may include defining questions that depend on their earlier answers. Defining questions and the corresponding user input responses can provide for improved training and use of that entity’s identity-centric data relationship model 27, encapsulating a greater understanding about the criteria an entity prefers. For example, in the context of learning to predict venue-related query parameters and related queries, the defining questions may capture user input relating to the entity’s preferred minimum venue rating (e.g. as used by a venue booking data service provider), dietary requirements and preferences (e.g. vegetarian menu), venuespecific variables (e.g. dog friendly), etc. Other exemplary defining questions may be directed at establishing a vicinity to a venue parameter, for example establishing a minimum or maximum walking time/distance.

[0046] At step S5-5, the registration module 47 of the network management server 45 registers a new identity-centric server 25 associated with the unique entity identifier. For example, this can involve creation of a new instance of a template identity-centric server 25 that does not yet have an identity-centric data relationship model 27. At step S5-7, the network management server 45 generates a new identity-centric data relationship model 27 for the new server 25, based on the input profile data received from the client computing device 7, and the global data relationship model 47 if implemented. At step S5-9, the network management server 45 transmits the new identity-centric data relationship model 27 to the identity-centric server 25, which stores the received model 27 at step S5-11. At step S5-13, the identity-centric server 25 uses the network address calculator module 39 to calculate a unique network address for the new identity-centric server 25, based on the unique entity identifier and the identitycentric abstract data model, or predefined attributes of the identity-centric abstract data model. At step S5-15, the network address calculator module 43 updates the address books stored by the plurality of identity-centric namespace servers 29 with the calculated network address and the corresponding unique entity identifier.

[0047] Figure 6 which comprises Figures 6A to 6D, is a flow diagram of an example computer-implemented process of processing an application layer request using an identity-centric server 25, according to an embodiment. Reference is also made to Figure 7, which comprises Figures 7A to 7F, schematically illustrating exemplary display screens output by an entity’s computing device 7 in this process. As shown in Figure 6, the process begins at step S6-1 where the client computing device 7 receive user input defining a new query. The query may take any form, such as voice, text, gestures, etc. as input by a user at the client computing device 7, for example via a user interface of a program/app or a website form output by a web browser. Each input query will typically define an action object and at least one query parameter, such as a data attribute.

[0048] For example, a user at a client computing device 7 can interact with the identitycentric server 25 in a number of different ways:

“SOLUTIONS”: the entity needs their identity-centric server 25 to solve something for them, such as “What is the fastest way for someone with my working hours to learn Russian without leaving my house?”, “What is the likeliest way for me score a job interview as Head of Sales at CompanyX, considering their employee profiles on WebsiteY and my online personality test results? ”, and “Where can we go as a short break that is good for walking and is relatively near a good pub lunch venue?”. Figure 7A shows an exemplary user interface with the user input SOLUTIONS-type query “What options do I have for a holiday to LA in August?” Also shown are a plurality of user selectable processing options for the entity to control corresponding processing steps of the query handler 33 and prediction engine 35.

“ASK”: the entity asks their identity-centric server 25 for advice based on information that the identity-centric server 25 has learned about that entity, such as “Based on my target weight, what should I search for on Recipe WebsiteX that SupermarketY has in stock today? ”, or “Should I add apples to my shopping list? ”, as shown in the exemplary user interface of Figure 7C.

“CONNECT”: the entity wishes to connect two or more data service providers together, thereby defining an abstracted data relationship between personal data assets 3 stored by the connected data service providers, such as “Id like ProviderX to link with my calendar so I can tell which gigs I can go to when my favourite artists are performing nearby. ”, as shown in the exemplary user interface of Figure 7E.

“WISHLIST”: the entity has one or more aspirations for the future, which can be defined in terms of abstracted data assets, such as “Go to a basketball game in America”, as shown in the exemplary user interface of Figure 7F.

[0049] At step S6-3, the client computing device 7 generates an identity-centric application layer protocol query based on the user input including the action object and data attribute(s), the query including the entity’s unique identifier according to the identity-centric application layer protocol. Preferably, the implemented identity-centric application layer protocol is based on HTTP, extended to define a standardised format and structure of an entity identifier data object as part of the identity-centric request. For example, the entity identifier object may be defined as a header field of the identitycentric request, which must be a combination of a globally unique value in the format of a GUID followed by an increasing decimal counter which must increase with every new HTTP request, such as {E2EA6C1C-E61B-49E9-9CFB-38184F907552}:123456). The GUID portion of this header field must be unique across all session contexts and must not change for the life of a particular session context. The client needs to send this header on every request and the server needs return this header with the same information in the response back to the client. The identity-centric server 25 can insert the entity identifier in an HTTP header of the or each generated HTTP request to a data service provider 5, the entity identifier indicating that the HTTP request is created from an identity-centric application layer protocol query.

[0050] At step S6-5, the client computing device 7 sends a lookup query to an identitycentric namespace server 29. At step S6-7, the identity-centric namespace server 29 provides the network address of the identity-centric server 25 associated with the specific entity identifier, responsive to received lookup query. For example, the identity-centric namespace server 29 can perform a lookup of the received entity identifier in the stored address book lookup table, to retrieve the corresponding unique network address that was calculated for the entity’s identity-centric server 25. At step S6-9, the client computing device 7 receives the network address of the identity-centric server 25 associated with entity’s identifier, and establishes a network session with the entity’s identity-centric server 25, at step S6-11. At step S6-13, the client computing device 7 transmits the identity-centric query to the entity’s identity-centric server 25 at the identified network address, wherein the application layer request is resolved using the identity-centric data relationship model 27 at the server 25.

[0051] Thus, the conventional lookup call to a traditional DNS server is replaced with a lookup call to an identity-centric namespace server 29, including the entity ID that is used to retrieve a corresponding IP address of that entity’s identity-centric server. Thereafter, the input query (from the client computing device 7) is communicated directly to that entity’s identity-centric server 25, for processing by that server 25 for example to carry out prediction of related data points, access a data service provider’s search functionality based on predicted data, issue action service requests for a data service provider to book a room or flight, etc.

[0052] Accordingly, at step S6-15, the query handler 33 of the identity-centric server 25 receives the application layer query identifying the registered entity, and processes the received identity-centric query to determine the action object and the data object(s). At step S6-17, the prediction engine 35 of the identity-centric server 25 determines predicted query parameters or data objects related to the query action object and/or data objects, using identity-centric data relationship model 27. Each query parameter or data attribute is associated with a respective one of the data service providers 5. Known associations may be defined by the network management server 45 when creating or establishing a new interface server 31 for a data service provider 5. Additionally, the identity-centric server 25 may store user-defined or learned preferences of a preferred associated data service provider. The identity-centric server 25 may also be updated with rules or data associations defined in the global model 49, such as learned trends in behaviour across the corpus of registered entities that can be used by the prediction engine 35. Further optionally, the identity-centric server 25 may be further configured to 5 access a database of historical queries to find any past records of queries that have involved the same or similar action objects and data objects, for example to determine or suggest a last used associated data service provider 5 and/or related query parameters. [0053] For example, referring to the exemplary complex input queries in the table below, the query handler 33 may identify associated data service providers 5 for each 10 action/data objects found in the query:

Query (with identified objects highlighted with underline)	Associated data service provider(s)
“Of my favourite bands to listen to on MusicService, which ones are playing near where I’ll be over the next few weekends (unless I’m already busy)? ”	MusicService -> MusicServiceA; near, next few weekends -> C al endar S ervi ceB
“Based on my target weight, what should I search for on RecipeWebsite that Supermarket has in stock today? ”	target weight -> FitnessServiceC; RecipeWebsite -> RecipeWebsiteD; Supermarket -> SupermarketE
“Because of the type of food I love, where and when should I go on holiday? ”	type of food -> RecipeWeb siteD, SupermarketE; where -> HolidayBookingServiceF; when -> C al endar S ervi ceB
“Based on my recent holiday booking, what songs should I put on my playlist to motivate me to exercise more and eat better so I can reach my target holiday weight? ” “... and set my home controls so the heating is turned onto holiday mode for that period”	recent -> CalendarServiceB; songs, playlist -> MusicServiceA; exercise, weight -> FitnessServiceC; eat -> RecipeWeb siteD, SupermarketE heating -> HomeAutomationServiceG; that period -> Historical Query DB

“... and order currency from a bureau de change offering the best commission rates. ”

order currency -> SearchEngineH

[0054] At step S6-19, the query handler 33 may request the entity’s personal information for one or more of the determined data attributes, using the data collector module 37 of the interface server 11 corresponding to the or each data service provider 5 associated with the determined data attribute(s). At step S6-21, the or each interface server 31 retrieves the requested personal information for the associated data attribute based on the entity identifier, using the data collector module 37. In this way, the entity’s personal information itself is not stored in the entity’s identity-centric data relationship model 27.

[0055] At step S6-23, the prediction engine 35 of the identity-centric server 25 can determine one or more predicted parameters for the action object, using the entity’s identity-centric data representation model 27, and taking into account for example the determined data object(s) and the retrieved personal information. More particularly, for a first data attribute of a data object identified in the query, the prediction engine 35 can determine a second data attribute with a relationship to the first data attribute as defined by the identity-centric data relationship model 27. The identity-centric server 25 can then generate, responsive to the determining of the second data attribute and for transmission to the associated data service provider via HTTP, an HTTP request that identifies the determined second data attribute and the entity associated with the identity-centric query.

[0056] At step S6-25, the query handler 33, in conjunction with a corresponding interface server 31, can generate an HTTP request defining a predicted action request for transmission to a data service provider 5 associated with the predicted parameters. At step S6-27, the interface server 31 transmits the predicted action HTTP request to the corresponding data service provider 5, using the action service module 39 that implements the appropriate API 13 of the data service provider 5. At step S6-29, the interface server 31 receives an HTTP response from the data service provider 5, for example to seek confirmation to proceed with the requested action, and passes the response to the identity-centric server 25.

[0057] At step S6-31, the identity-centric server 25 may prompt the user to confirm the predicted action request based on returned response. At step S6-33, the client computing device 7 can receive user input confirmation in response to the prompt and pass the user confirmation back to the identity-centric server 25. At step S6-35, the query handler 33 of the identity-centric server 25 generates and passes a confirmed action request to the corresponding interface server 31, responsive to the received user confirmation. At step S6-37, the interface server 31 transmits the confirmed action request to the data service provider 5, using the action service module 39. Preferably although not necessarily, the identity-centric server 25 can be updated responsive to confirmation of the suggested query. For example, the identity-centric model updater 41 can update the entity’s data relationship model 27 based on the data attributes of the confirmed query, such as adding, removing, modifying strength of connections between corresponding abstracted data objects in the model 27. The global model updater 51 in the network management server 45 may also update the global data relationship model 49, for example based on abstraction of the data attributes of the confirmed query. The identity-centric server 25 may also store the confirmed query as a new data record in a historical query database, thus creating a new set of data points which are related to each other in the associated context.

[0058] At step S6-39, the prediction engine 35 of the identity-centric server 25 uses the identity-centric data relationship model to determine if there is a predicted action object to be processed, based on the data object(s) identified in the original request, and for example any personal information retrieved at step S6-21. Referring to the above exemplary input queries, each original received query may comprise a natural language span which corresponds to at least one action object and at least one query object. The query handler 33 can process the received query to form an intent based on the query data as input by the user, where forming the intent enables executing the action object to transform the action object into a related action object based on the query object and the entity’s trained identity-centric data representation model 27.

[0059] If it is determined that there is a related action object to be processed, then at step S6-41, the prediction engine 35 generates and outputs an application layer query identifying the registered entity and the predicted action object. Processing then returns to step S6-15 where the identity-centric server 25 processes the related identity-centric query as described above. For example, the entity’s identity-centric server 25 may determine that presence in the received query of the term 'holiday' and the mention of a non-domestic country means that the user is likely to require a flight. Consequently, the prediction engine 35 may retrieve stored information about the user's airline preferences or any stated requirement in past interactions, then access an associated flight booking data service provider 5 via the corresponding interface server 31, to check available options. The identity-centric server 25 may also know that the user is a member of an airline loyalty scheme, so uses that corresponding interface server 31 to access the loyalty scheme data service provider 5, for example to check what the loyalty points benefit would be for the user. The query handler 33 can combine information from incoming responses to the plurality of HTTP requests received from the respective data service providers, to form an identity-centric application layer protocol response that is transmitted back to the client computing device 7 for display to the user. Figure 7D shows an exemplary user interface with one such complex response to an identitycentric Ask-type query, including a combination of personal information retrieved from different data sources.

[0060] A further related query may be an instruction to book a selected flight using the interface server 31 associated with the flight booking data service provider 5. Figure 7B shows an exemplary user interface with one such suggested complex query, again based on a combination of personal information retrieved from different data sources. Also shown are a plurality of user selectable options to confirm further predicted queries determined by the prediction engine 35, such as purchasing airport transfers, booking restaurant reservations, and searching for event tickets. Yet further exemplary related HTTP queries generated by the prediction engine 35 include setting a new goal to the entity’s personal data 3 at their specified fitness data service provider 3, adding new workout dates and times to the entity’s personal data 3 at their calendar data service provider 5, creating a new playlist in the entity’s personal data 3 at their music data service provider 5, adding a new diet mode or shopping list to the entity’s personal data 3 at their online supermarket data service provider 5, etc.

[0061] On the other hand, when it is determined that there are no further predicted action objects to be processed, then processing proceeds to step S6-43 where the query handler 33 of the identity-centric server 25 transmits an identity-centric application layer protocol success response back to the client computing device 7, which displays confirmation of completed action requests to the user at step S6-45.

Alternative Embodiment [0062] A further embodiment will now be described with reference to Figure 8, using corresponding reference numerals to those of preceding figures where appropriate for corresponding elements. As shown in Figure 8, a plurality of identity-centric servers 25 forming an identity-centric sub-network 83-1 are provided for each registered entity in the system 81. In this alternative embodiment, each of the plurality of identity-centric servers 25 in an identity-centric sub-network 83-1 is associated with a respective different identity-centric query context, and stores a respective identity-centric data relationship model 27-1 for the associated query context. Additionally, the identitycentric namespace servers 29’ is this embodiment collectively store data defining an address book of identity-centric server network addresses mapped to the corresponding unique entity identifiers and defined query contexts. An example lookup table data structure is set out in the table below:

Entity Identifier	Query Context	IP Address
E2EA6C1C-E61B-49E9-9CFB-3 8184F9075 52	Plan	xxx.xxx.xxx.l
E2EA6C1C-E61B-49E9-9CFB-3 8184F9075 52	Riskupdate	xxx.xxx.xxx2

[0063] Consequently, the implemented identity-centric application layer protocol in one example is based on HTTP and extended to define a standardised format and structure of both an entity identifier data object and a query context string, as part of the identity centric request. For example, the entity identifier object and the query context string may be defined as respective header fields of the identity-centric request. The query context string may be defined by a requesting entity, such as the client computing device 7 transmitting an identity-centric query or a related identity-centric query for handling by a respective identity-centric server 25, or an identity-centric server 25 transmitting the related identity-centric query for handling by a different identity-centric server 25. Alternatively or additionally, each identity-centric namespace server 29’ may be configured with functionality to determine a query context from the one or more query parameters specified in an identity-centric request.

[0064] For example, a requesting client computing device 7 in this embodiment can determine and specify that the exemplary solutions-type queries set out above are related to a “plan” context. The identity-centric namespace server 29’ would then provide the network address of the identity-centric server 25 associated with the entity identifier and specific query context, responsive to received lookup query. The client computing device 7 then transmits the identity-centric query to the entity’s identitycentric server 25 at the identified network address, wherein the “plan” application layer request is resolved using the identity-centric data relationship model 27 that is generated and trained for that particular query context.

[0065] Subsequently, the client computing device 7 or the handling identity-centric server 25 can determine a related identity-centric query having a different query context, and transmit the related query to a different one of the entity’s identity-centric servers 25 identified by a respective different network address. For example, the prediction engine 35 of the handling identity-centric server 25 may determine that a related query is to inform and/or instruct one or more of the user’s associated data service providers 5 with information from the resolved “plan” application layer request. The related query in this example may be associated with a “risk-update” query context and directed to data service providers 5 that the registered entity has approved for sharing of information. The related query can then be transmitted to a different identitycentric server 25 in that entity’s sub-network 83, as identified by a network address provided by the identity-centric namespace server 29’ in the present embodiment. As a result, the “risk-update” application layer request is resolved using a different identity centric data relationship model 27 associated with the same entity, which is generated and trained for that particular query context. It is appreciated that the different identitycentric data relationship model 27 may encapsulate rules of relationships between different sets of assets, thus resulting in different identity-specific query responses depending on the specified query context.

[0066] It is also appreciated that in this alternative embodiment, the network addresses of respective identity-centric servers 25 can be calculated based on the corresponding trained model 27 and the query context. In this way, the IP address returned by an identity-centric namespace server 29 effectively identifies the network location of information related to a context-specific and identity-centric query, rather than the information itself or what the information is linked to.

Example Computer System Implementation [0067] Figure 9 illustrates an example computer system 900 in which embodiments of the present invention, or portions thereof, can be implemented as computer-readable code to program processing components of the computer system 900. For example, each of the servers of Figures 2, 3 and 4 can be implemented in system 900. The steps performed by respective servers in the methods illustrated by the flowchart of Figure 5 and 6 can be implemented by respective systems 900. Various embodiments of the invention are described in terms of this example computer system 900. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the invention using other computer systems and/or computer architectures.

[0068] Computer system 900 includes one or more processors, such as processor 904. Processor 904 can be a special purpose or a general-purpose processor. Processor 904 is connected to a communication infrastructure 906 (for example, a bus, or network). Computer system 900 may also include a user input interface 903 connected to one or more input device(s) 905 and a display interface 907 connected to one or more display(s) 909, which may be integrated input and display components. Input devices 905 may include, for example, a pointing device such as a mouse or touchpad, a keyboard, a touchscreen such as a resistive or capacitive touchscreen, etc. According to an embodiment, computer display 930, in conjunction with display interface 902, can be used to display a UI to a server operator.

[0069] Computer system 900 also includes a main memory 908, preferably random access memory (RAM), and may also include a secondary memory 910. Secondary memory 910 may include, for example, a hard disk drive 912, a removable storage drive 914, flash memory, a memory stick, and/or any similar non-volatile storage mechanism. Removable storage drive 914 may comprise a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like. The removable storage drive 914 reads from and/or writes to a removable storage unit 918 in a well-known manner. Removable storage unit 918 may comprise a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 914. As will be appreciated by persons skilled in the relevant art(s), removable storage unit 918 includes a non-transitory computer usable storage medium having stored therein computer software and/or data.

[0070] In alternative implementations, secondary memory 910 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 900. Such means may include, for example, a removable storage unit 922 and an interface 920. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 922 and interfaces 920 which allow software and data to be transferred from the removable storage unit 922 to computer system 900.

[0071] Computer system 900 may also include a communications interface 924. Communications interface 924 allows software and data to be transferred between computer system 900 and external devices. Communications interface 924 may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, or the like.

[0072] Various aspects of the present invention can be implemented by software and/or firmware (also called computer programs, instructions or computer control logic) to program programmable hardware, or hardware including special-purpose hardwired circuits such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), etc. of the computer system 900, or a combination thereof. Computer programs for use in implementing the techniques introduced here may be stored on a machine-readable storage medium and may be executed by one or more general-purpose or special-purpose programmable microprocessors. The terms “computer program medium”, “non-transitory computer readable medium” and “computer usable medium” introduced herein can generally refer to media such as removable storage unit 918, removable storage unit 922, and a hard disk installed in hard disk drive 912. Computer program medium, computer readable storage medium, and computer usable medium can also refer to memories, such as main memory 908 and secondary memory 910, which can be memory semiconductors (e.g. DRAMs, etc.). These computer program products are means for providing software to computer system 900.

[0073] Computer programs are stored in main memory 908 and/or secondary memory 910. Computer programs may also be received via communications interface 924. Such computer programs, when executed, enable computer system 900 to implement the present invention as described herein. In particular, the computer programs, when executed, enable processor 904 to implement the processes of the present invention, such as the steps in the methods illustrated by the flowcharts of Figures 5 and 6 and system architecture of Figures 2, 3 and 4 described above. Accordingly, such computer programs represent controllers of the computer system 900. Where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system 900 using removable storage drive 914, interface 920, hard drive 912, or communications interface 924.

[0074] Embodiments of the invention employ any computer useable or readable medium, known now or in the future. Examples of computer useable mediums include, but are not limited to, primary storage devices (e.g., any type of random access memory), secondary storage devices (e.g., hard drives, floppy disks, CD ROMS, ZIP disks, tapes, magnetic storage devices, optical storage devices, MEMS, nanotechnological storage device, etc.), and communication mediums (e.g., wired and wireless communications networks, local area networks, wide area networks, intranets, etc.).

Alternatives and Modifications [0075] It will be understood that embodiments of the present invention are described herein by way of example only, and that various changes and modifications may be made without departing from the scope of the invention.

[0076] For example, it will be appreciated that although the respective processes and associated processing modules are described as separate embodiments, aspects of the described embodiments can be combined to form further embodiments. For example, alternative embodiments may comprise one or more of the identity-centric server and interface server/module aspects described in the above embodiments.

[0077] In the embodiments described above, the query engine in conjunction with the prediction engine of an entity’s identity-centric server receives, processes and responds to identity-centric queries, by predicting related data assets and queries. As those skilled in the art will appreciate, the query handler of each identity-centric server can instead process a received identity-centric query as a simple request to determine other data assets that relate to the object, intent or reason for the identity-centric request. In such an alternative, the identity-centric response can contain the network addresses of the or each interface server associated with determined related data assets. An exemplary response implementing an identity-centric application layer protocol (referred to as “HTTP+”, an exemplary extended version of an existing HTTP) is set out below:

[0078] As yet another alternative, the query handler module of each identity-centric server may instead be provided as a processing module in the network management server that is in communication with the plurality of identity-centric servers. Additionally, as those skilled in the art will appreciate, the query handler functionality may be provided as one or more application programming interfaces (APIs) accessible by an application program executing on the client computing devices, or as a plug-in module, extension, embedded code, etc., configured to communicate with an application program.

[0079] In the above embodiments, the identity-centric servers, in conjunction with the corresponding data relationship models, utilise rules engines and/or neural networks to encapsulate rules of relationships between assets. As those skilled in the art will appreciate, determining a related asset can be performed with an identity-centric data relationship model including any one or more of:

probabilistic properties, heuristic properties, deterministic properties, and/or any other suitable properties.

The model updating methods can employ machine learning approaches including any one or more of:

supervised learning (e.g., using logistic regression, using back propagation neural networks, using random forests, decision trees, etc.),

- unsupervised learning (e.g., using an Apriori algorithm, using K-means clustering), semi-supervised learning, reinforcement learning (e.g. using a Q-leaming algorithm or temporal difference learning), and any other suitable learning style.

The model updater modules and the prediction server/engine can implement any one or more of:

a regression algorithm (e.g., ordinary least squares, logistic regression, stepwise regression, multivariate adaptive regression splines, locally estimated scatterplot smoothing, etc.), an instance-based method (e.g., k-nearest neighbour, learning vector quantization, self-organizing map, etc.), a regularization method (e.g., ridge regression, least absolute shrinkage and selection operator, elastic net, etc.), a decision tree learning method (e g., classification and regression tree, iterative dichotomiser 3, C4.5, chi-squared automatic interaction detection, decision stump, random forest, multivariate adaptive regression splines, gradient boosting machines, etc.), a Bayesian method (e.g., naive Bayes, averaged one-dependence estimators, Bayesian belief network, etc.), a kernel method (e.g., a support vector machine, a radial basis function, a linear discriminate analysis, etc.), a clustering method (e.g., k-means clustering, expectation maximization, etc.), an associated rule learning algorithm (e.g., an Apriori algorithm, an Eclat algorithm, etc.), an artificial neural network model (e.g., a Perceptron method, a backpropagation method, a Hopfield network method, a self-organizing map method, a learning vector quantization method, etc.), a deep learning algorithm (e.g., a restricted Boltzmann machine, a deep belief network method, a convolution network method, a stacked auto-encoder method, etc.), a dimensionality reduction method (e.g., principal component analysis, partial lest squares regression, Sammon mapping, multidimensional scaling, projection pursuit, etc.), an ensemble method (e.g., boosting, boostrapped aggregation, AdaBoost, stacked generalization, gradient boosting machine method, random forest method, etc.), and any suitable form of machine learning algorithm.

[0080] Reference in this specification to “one embodiment” are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. In particular, it will be appreciated that aspects of the above described embodiments can be combined to form further embodiments.

Similarly, various features are described which may be exhibited by some embodiments and not by others. Yet further alternative embodiments may be envisaged, which nevertheless fall within the scope of the following claims.

Claims (18)

1. A method for providing an identity-centric application layer protocol to HyperText Transfer Protocol (HTTP) gateway via a network system between a client and a plurality of servers, the method comprising:

receiving, by a device of a plurality of devices in the network system, an identity-centric application layer protocol query via a communication session with the client, wherein the identity-centric application layer protocol query identifies an entity associated with the query, and wherein the communication session is established by the client responsive to receiving a network address of the device that is associated with the entity;

identifying, by the device, a first data attribute based on the received query;

determining, by the device, a second data attribute with a relationship to the first data attribute, the second data attribute associated with a server of the plurality of servers; and generating, by the device responsive to the determining of the second data attribute and for transmission to the associated server via HTTP, an HTTP request that identifies the determined second data attribute and the entity associated with the identity-centric application layer protocol query.

2. The method of claim 1, further comprising transmitting, by the client to a name server, a request to lookup the network address of the device that is associated with the entity, the request including the entity identifier.

3. The method of claim 1, further comprising:

determining, by the device, a plurality of related query parameters, each associated with a corresponding server of the plurality of servers; and generating, by the device, a plurality of HTTP requests, each comprising a corresponding determined related query parameter and the identifier of the entity associated with the identity-centric application layer protocol query.

4. The method of claim 3, further comprising combining, by the device, information from incoming responses to the plurality of HTTP requests received from the servers, to form an identity-centric application layer protocol response.

5. The method of claim 1, further comprising inserting, by the device, an entity identifier in an HTTP header of the generated HTTP request, the entity identifier indicating that the HTTP request is created from an identity-centric application layer protocol query.

6. The method of any preceding claim, wherein the device determines a second data attribute with a relationship to the first data attribute using an identity-centric data relationship model.

7. The method of any preceding claim, wherein the identity-centric application layer protocol query further identifies a context associated with the query, and wherein the communication session is established by the client responsive to receiving a network address of the device that is associated with the entity and the query context.

8. The method of claim 7, wherein a plurality of devices are provided for each entity, each device storing an identity-centric data relationship model associated with a respective query context.

9. The method of any one of claims 6 to 8, wherein the model comprises data defining a rules engine or a trained neural network that encapsulates rules of relationships between data assets.

10. The method of claim 9, wherein the model is trained from a data set of historical queries and responses, using a machine learning algorithm, and updated based on new queries and processed responses.

11. In a computing environment, a method of implementing people as application layer objects, the method comprising:

for an entity identified in an application layer protocol query, identifying a network address of a server storing data defining an identity-centric data relationship model of the entity;

receiving, at the server identified by the network address, the application layer protocol query;

for a first data attribute identified in the query, identifying, by the server, a second data attribute with a relationship to the first data attribute as defined by the identity-centric data relationship model;

retrieving, from a data store, information related to the entity and the identified second data attribute, such that the information related to the entity is not stored in the identity-centric data relationship model of the entity;

using the retrieved information to resolve the application layer protocol query; and displaying in a user interface a result of the resolved query.

12. A computer implemented method of querying an identity-centric lookup table at a device in a computer network, the identity-centric lookup table having entries which are accessible using an entity identifier, the method comprising:

identifying a network address by querying the identity-centric lookup table for an entity identifier; and transmitting an identity-centric application layer protocol request to a server at the identified network address, wherein the request is resolved using an identity-centric data relationship model at the server.

13. A system comprising:

a plurality of servers, each server associated with a respective entity and having a unique network address; and at least one name server stores an address book of server IP addresses mapped to corresponding unique entity identifiers;

wherein each server is configured to:

receive a query identifying an entity and at least one data asset; and determine one or more related assets using a data model stored on the individual server, the data model defining relationships between related assets for the associated entity.

14. The system of claim 13, wherein each server has a unique IP address, and a private namespace server stores an address book of server IP addresses mapped to corresponding unique entity identifiers.

15. The system of claim 13 or 14, wherein each server is configured to respond with a list of respective addresses of additional servers for each related assets, where each additional server is configured to retrieve that entity’s personal data via an API.

16. The system of claim 15, wherein the determined related assets are used to generate customised or related queries.

17. A computer system comprising:

at least one processor; and at least one memory storing a computer program which, when executed by the at least one processor, cause the computer system to perform the steps of any one of claims 1 to 12.

18. A computer program product comprising instructions stored thereon for causing a computer to perform a method in accordance with any one of claims 1 to 12.