Field of the Invention The present invention relates to the field of electronic data store interrogation. Background

Electronic data stores are widely used to store data in an integrated format that allows the data to be retrieved by electronic interrogation of the data store. Examples of such data stores are the data stores containing data about people and other entities, especially those requiring a licence, such as a vehicle, firearm, etc, that are maintained by governments. For example, in Great Britain, the Driver and Vehicle Licensing Agency maintains a database of drivers and vehicles in Great Britain.

However, data stores containing details about an entity, especially a person, suffer from a number of problems, in particular in the areas of security and data privacy. For example, with regard to security, a person gaining unauthorised access to a data store, for example by hacking, may gain access to all of the data in the data store, enabling him/her to use the data for unlawful purposes. Furthermore, with regard to data privacy, an authorised, legitimate user of the data store can access the stored data and can therefore read the data, copy the data and/or make use of the data for a purpose other than the authorised, legitimate purpose. These problems have led to a situation in which a super data store, aggregating all, or many, of the details for each entity, has been considered unfeasible, even though such a super data store could have significant benefits, especially in the area of data integration. This has therefore led to the use of separate data stores. However, the use of separate data stores has led to further problems. In particular, although data is held in separate data stores to prevent the data being aggregated in a single data store, data from the different data stores becomes aggregated during the process of interrogating the different data stores to answer a query about an entity.

In addition, problems arise even when only one data store needs to be interrogated to answer a query about an entity. For example, many data owners are not prepared to allow access to their data store by another party because their data could be copied and put into a new data store or a competitor's data store. Therefore, third parties have not been able to make use of data stored in such separate data stores. This has led to a situation in which some data stores, such as certain databases maintained by government departments and certain private sector databases, have not been made available to external users, and even certain internal users, even though the data they contain could be used by the external users to provide many useful services, and access by more internal users could improve efficiency. What is needed is a solution which addresses one or more of the above problems, thereby facilitating access to a data store (or a super data store) and/or facilitating access to multiple data stores without aggregating data.

Summary

According to the present invention, there is provided a verification system operable to interrogate a data store storing data defining a plurality of attributes of a plurality of entities to verify if an entity satisfies a criterion based upon an identifier attribute provided for the entity. The system comprises a verification controller and a data store interface configured to communicate with the data store and the verification controller. The verification controller is configured to: receive data defining an identifier attribute for the entity;

transmit data to the data store interface defining the identifier attribute;

transmit data to the data store interface defining a question relating to the entity, the question requiring an answer indicating whether the question is answered positively or negatively; receive data defining an answer to the question from the data store interface, the answer indicating whether the question is answered positively or negatively; and transmit a response indicative of whether the entity satisfies the criterion in dependence upon the data defining the answer from the data store interface.

The data store interface stores an instruction for interrogating the data store. Furthermore, the data store interface is configured to: receive from the verification controller the data defining the identifier attribute and the data defining the question;

following receipt of the data defining the identifier attribute and the data defining the question from the verification controller, interrogate the data store using the instruction; and

transmit data defining an answer to the verification controller indicating whether the question is answered positively or negatively.

The present invention also provides a verification controller for use in a verification system comprising the verification controller and a data store interface arranged to interrogate a data store storing data defining a plurality of attributes of a plurality of entities to verify if an entity satisfies a criterion based upon an identifier attribute provided for the entity. The verification controller comprises apparatus configured to: communicate with the data store interface;

receive data defining an identifier attribute for an entity;

transmit to the data store interface data defining the identifier attribute;

transmit to the data store interface data defining a question relating to the entity, the question requiring an answer indicating whether the question is answered positively or negatively;

receive data defining an answer to the question from the data store interface, the answer indicating whether the question is answered positively or negatively; and transmit a response indicative of whether the entity satisfies the criterion in dependence upon the answer from the data store interface. The present invention also provides a data store interface for use in a verification system comprising a verification controller and the data store interface arranged to interrogate a data store storing data defining a plurality of attributes of a plurality of entities to verify if an entity satisfies a criterion based upon an identifier attribute provided for the entity. The data store interface comprises apparatus configured to: communicate with the verification controller and the data store;

store an instruction for interrogating the data store;

receive from the verification controller data defining an identifier attribute for an entity and data defining a question relating to the entity, the question requiring an answer indicating whether the question is answered positively or negatively;

following receipt of the data defining an identifier attribute and the data defining the question from the verification controller, interrogate the data store using the stored instruction; and

transmit data defining an answer to the verification controller indicating whether the question is answered positively or negatively.

The present invention also provides a method of interrogating a data store storing data defining a plurality of attributes of a plurality of entities to verify if an entity satisfies a criterion based upon an identifier attribute provided for the entity. The method is performed by a verification controller and a data store interface operatively connected between the data store and the verification controller. The verification controller receives data defining an identifier attribute for an entity. The verification controller transmits to the data store interface data defining the identifier attribute. The verification controller transmits to the data store interface data defining a question relating to the entity, the question requiring an answer indicating whether the question is answered positively or negatively. The data store interface receives the data defining the identifier attribute and the data defining the question from the verification controller. The data store interface interrogates the data store using a stored instruction. The data store interface transmits to the verification controller data indicating whether the question is answered positively or negatively. The verification controller receives from the data store interface the data indicating whether the question is answered positively or negatively. The verification controller transmits a response indicative of whether the entity satisfies the criterion in dependence upon the data received from the date store interface.

The present invention also provides a method performed by a verification controller in a verification system comprising the verification controller and a data store interface arranged to interrogate a data store storing data defining a plurality of attributes of a plurality of entities to verify if an entity satisfies a criterion based upon an identifier attribute provided for the entity. The verification controller receives data defining an identifier attribute for an entity, transmits data to the data store interface defining the identifier attribute, transmits data to the data store interface defining a question relating to the entity, the question requiring an answer indicating whether the question is answered positively or negatively, receives data from the data store interface indicating whether the question is answered positively or negatively, and transmits a response indicative of whether the entity satisfies the criterion in dependence upon the data received from the data store interface.

The present invention also provides a method performed by a data store interface in a verification system comprising a verification controller and the data store interface arranged to interrogate a data store storing data defining a plurality of attributes of a plurality of entities to verify if an entity satisfies a criterion based upon an identifier attribute provided for the entity. The data store interface stores an instruction for interrogating the data store, receives data from the verification controller defining an identifier attribute for an entity and data defining a question relating to the entity, the question requiring an answer indicating whether the question is answered positively or negatively, interrogates the data store using the stored instruction, and transmits data to the verification controller indicating whether the question is answered positively or negatively.

The present invention also provides a verification system comprising a verification controller and a data store interface, the verification system being operable to interrogate at least one data store storing data defining a plurality of attributes of a plurality of entities to verify if an entity satisfies at least one criterion. The verification system is configured to receive data defining an identifier attribute for an entity. The verification controller is configured to transmit data to the data store interface defining a question relating to the entity, the question requiring an answer indicating whether the question is answered positively or negatively. The data store interface is configured to store an instruction for interrogating a data store and the data store interface is configured to, in response to the receipt of data from the verification controller defining the question, interrogate the data store using the instruction and the identifier attribute provided for the entity. The verification system is configured to transmit a response indicative of whether the entity satisfies the criterion. The present invention also provides a computer program product, such as a storage medium or a signal, carrying computer program instructions to program programmable processing apparatus to become operable to perform at least one of the methods as set out above. Brief Description of the Drawings

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which like reference numbers designate like parts or processes, and in which:

Figure 1 is a block diagram showing the functional components of a verification system in a first embodiment.

Figure 2 shows an exemplary hardware implementation of a programmable computer processing apparatus in which the verification controller and each data store interface may be implemented in the first embodiment.

Figure 3 is a block diagram showing exemplary data stores of the verification controller in the first embodiment.

Figure 4 shows an exemplary configuration of the question set store of the verification controller in the first embodiment, and shows exemplary data in the question set store. Figure 5 shows an exemplary configuration of the results store of the verification controller in the first embodiment, and shows exemplary data in the results store. Figure 6 shows an exemplary configuration of the alert data store of the verification controller in the first embodiment, and shows exemplary data in the alert data store.

Figure 7 is a block diagram showing exemplary data stores of a data store interface in the first embodiment.

Figures 8a and 8b show an exemplary configuration of the instruction store in a data store interface in the first embodiment and shows exemplary instructions in the instruction store.

Figures 9a-9n are flow diagrams illustrating processing operations performed by a user equipment, the verification controller, the data store interfaces and the data stores in the first embodiment.

Figure 10 is a block diagram schematically illustrating the notional functional processing units and data stores into which the verification controller is configured in the first embodiment.

Figure 11 is a block diagram schematically illustrating the notional functional processing units and data stores into which a data store interface is configured in the first embodiment. Figure 12 shows exemplary identifier attribute types and exemplary identifier attributes for a simplified example.

Figure 13 shows exemplary data stored in the question set store of the verification controller in the simplified example.

Figure 14 shows exemplary data that is transmitted at step S9-26 by verification controller 12 in a first round of processing in the simplified example. Figures 15a, 15b, 15c and 15d show exemplary data stored in the instruction store of the data store interfaces dsi.northstate.gov.nesw, dsi.eaststate.gov.nesw, dsi.southstate.gov.nesw and dsi.weststate.gov.nesw, respectively, in the simplified example.

Figure 16 shows exemplary data stored in the North State data store in the simplified example. Figure 17 shows exemplary data stored in the results store of the verification controller after an answer has been received for the first question identifier from the data store interface dsi.northstate.gov.nesw in the simplified example.

Figure 18 shows exemplary data stored in the East State data store in the simplified example.

Figure 19 shows exemplary data stored in the results store of the verification controller after an answer has been received for the first question identifier from the data store interface dsi.eaststate.gov.nesw in the simplified example.

Figure 20 shows exemplary data stored in the South State data store in the simplified example.

Figure 21 shows exemplary data stored in the results store of the verification controller after an answer has been received for the first question identifier from the data store interface dsi.southstate.gov.nesw in the simplified example.

Figure 22 shows exemplary data stored in the West State data store in the simplified example. Figure 23 shows exemplary data stored in the results store of the verification controller after an answer has been received for the first question identifier from the data store interface dsi.weststate.gov.nesw in the simplified example. Figure 24 shows exemplary data stored in the results store of the verification controller after an answer has been received for the second question identifier from the data store interface dsi.eaststate.gov.nesw in the simplified example.

Figure 25 shows exemplary data stored in the instruction store of the data store interface dsi.postoffiee.gov.nesw in the simplified example.

Figures 26a and 26b show exemplary data stored in the Post Office data store in the simplified example. Figure 27 shows exemplary data stored in the results store of the verification controller after an answer has been received for the third question identifier from the data store interface dsi.postoffiee.gov.nesw in the simplified example.

Figures 28a and 28b show exemplary data stored in the instruction store of the data store interface dsi.birthsanddeaths.gov.nesw in the simplified example.

Figures 29a and 29b show exemplary data stored in the births and deaths data store in the simplified example. Figure 30 shows exemplary data stored in the results store of the verification controller after an answer has been received for the fourth question identifier from the data store interface dsi.birthsanddeaths.gov.nesw in the simplified example.

Figure 31 shows exemplary data stored in the results store of the verification controller after an answer has been received for the fifth question identifier from the data store interface dsi.birthsanddeaths.gov.nesw in the simplified example. Figure 32 shows exemplary data stored in the results store of the verification controller after processing has been performed at step S9-52 in the simplified example to determine a respective result for each question identifier. Figure 33 shows exemplary data stored in the alert data store of the verification controller in the simplified example.

Figures 34a, 34b, 34c and 34d show exemplary data stored in the instruction stores of data store interfaces in a second embodiment.

Figure 35 is a flow diagram showing processing operations performed by a data store interface and a data store in the second embodiment.

Figure 36 is a block diagram schematically illustrating the notional functional processing units and data stores into which a data store interface is configured in the second embodiment.

Figures 37a, 37b and 37c show exemplary data stored in an instruction store of a data store interface in a first modification.

Figures 38a, 38b and 38c are flow diagrams illustrating processing operations performed by a data store interface, a first data store and a second data store in the first modification.

Figure 39 is a block diagram schematically illustrating the notional functional processing units and data stores into which a data store interface is configured in the first modification.

Figures 40a and 40b show exemplary data stored in the Social Security data store in an example to illustrate processing in the first modification.

Figures 41a and 41b show exemplary data stored in the Births and Deaths data store in the example to illustrate processing in the first modification. Figure 42 is a block diagram showing the functional components of a verification system in a second modification.

Figures 43a, 43b and 43c show exemplary data stored in the instruction store of a first data store interface module in the second modification.

Figures 44a, 44b, 44c and 44d are flow diagrams illustrating processing operations preformed by the first data store interface module, a first data store, a second data store interface module and a second data store in the second modification.

Figure 45 is a block diagram schematically illustrating notional functional processing units and data stores into which a first data store interface module is configured in the second modification. Figure 46 is a block diagram schematically illustrating notional functional processing units and data stores into which a second data store interface module is configured in the second modification.

Figures 47a and 47b are flow diagrams illustrating processing operations performed by a verification controller and a data store interface in embodiments and modifications of the invention.

Figure 48 is a flow diagram illustrating processing operations performed by a verification controller in embodiments and modifications of the invention.

Figure 49 is a flow diagram illustrating processing operations performed by a data store interface in embodiments and modifications of the invention. Detailed Description

[Embodiment 1] Referring to Figure 1, an embodiment of a system for electronic data store interrogation comprises a verification system 2 configured to communicate with a plurality of data stores 4 for example via communication links 6. Five data stores 4 are shown in Figure 1 by way of example, although there may be more than this or fewer. Each of the data stores 4 may be of any type capable of storing electronic data, such as a relational database, an object-oriented database or a flat file database.

A plurality of user equipment 8 communicate with the verification system 2 via physical or wireless communication links 10. Five user equipments 8 are shown in Figure 1 by way of example, although there may be more than this or fewer. Each user equipment 8 comprises any device that can communicate electronically with the verification system, such as a desktop computer, a laptop computer, a tablet computer, a personal digital assistant or a smartphone. A user equipment 8 may also comprise a server. Each of the communication links 10 may be of any type that is suitable for electronic communication, such as a wire, fibre-optic cable, and/or wireless communication channel (for example a microwave, radio or infrared communication channel), and may include one or more networks, such as the Internet, a telephone network, etc.

The verification system 2 in this embodiment comprises the functional components of a verification controller 12 and a plurality of data store interfaces 14. Four data store interfaces are shown in Figure 1 by way of example, although there may be more than this or fewer. The verification controller 12 is configured to communicate with the user equipment 8 via the communication links 10 and communicate with the data store interfaces 14 via physical or wireless communication links 16. Each of the communication links 16 may be of any type that is suitable for electronic communication, such as a wire, fibre-optic cable, and/or wireless communication channel (for example a microwave, radio or infrared communication channel), and may include one or more networks, such as the Internet, a telephone network, etc. Each of the data store interfaces 14 is configured to communicate with one or more data stores 4 via the communications links 6. In this embodiment, each data store interface 14 resides on a separate server with a respective one, or a respective plurality, of the data stores 4. Accordingly, in this embodiment, each communication link 6 between a data store interface 14 and its data store(s) 4 is an internal communication link within the server. In alternative embodiments, however, each data store interface 14 need not reside on the same server as its data store(s). In those embodiments each of the communication links 6 may be of any type that is suitable for electronic communication, such as a wire, fibre-optic cable, and/or wireless communication channel (for example a microwave, radio or infrared communication channel), and may include one or more networks, such as the Internet, a telephone network, etc.

As will be explained in detail below, the data stores 4 store data defining a plurality of attributes of a plurality of entities. The verification system 2 is operable to interrogate at least one of the data stores to verify if an entity, defined by one or more identifier attributes provided by a user equipment 8, satisfies one or more criteria. By utilising the verification controller 12 and data store interfaces 14, and by performing processing operations as described hereinafter, the verification system 2 is able to use data stored in one or more data stores 4 to verify if the entity satisfies the criterion or criteria in such a way that, even when data stored in a plurality of data stores 4 is required to verify whether the entity satisfies the criterion or criteria, verification system 2 can achieve this without aggregating data (that is, without creating a combination of data that did not previously exist in one of the data stores).

In more detail, verification controller 12 is configured to receive data from a user equipment 8 defining one or more identifier attributes for an entity and the type of verification process required for the entity. For example, in the case of a person, the identifier attributes may comprise a name and an address, and the type of verification process required may be any type of verification concerning the person, such as the person's entitlements, qualifications, credit- worthiness, etc. By way of specific example, the type of verification may be verification that the person is entitled to vote in a particular election (as will be exemplified in further detail later).

The verification controller 12 stores a plurality of question sets. Each question set relates to a different verification process and contains data defining one or more questions for effecting the verification. As explained in more detail below, each question is a polar question, that is a question requiring an answer indicating whether the question is answered positively or negatively, as opposed to a content question. By way of example, the question "Does Stephen Smith live at 2 Northway, Northton, Northstate, NL19 NES ?" is a polar question, whereas the question "Who lives at 2 Northway, Northton, Northstate, NL19 NES ?" is a content question as it requires content to be returned in order to answer the question.

The verification controller 12 is configured to select a set of stored questions in dependence upon the type of verification requested by the user equipment 8, and is further configured to transmit the question(s) in the selected set to one or more of the data store interfaces 14, together with data defining the identifier attribute(s) for the entity.

Each data store interface 14 stores instructions for interrogating the data store(s) 4 to which the data store interface 14 is operatively connected (that is, in this embodiment, the data store(s) 4 which reside on the same server as the data store interface 14 or, in alternative embodiments, the data store(s) with which the data store interface 14 is configured to communicate). Following receipt of data defining the identifier attribute(s) for an entity and a question from the verification controller 12, each data store interface 14 is configured to select a stored instruction for interrogating a connected data store 4 in dependence upon the data defining the question from the verification controller 12, and is furthermore configured to interrogate the data store 4 using the selected instruction. In this embodiment, each instruction stored by a data store interface 14 comprises an instruction for interrogating a data store 4 to cause the data store 4 to return an answer to a polar question indicating whether the question is answered positively or negatively. Accordingly, each data store interface 14 is configured to interrogate a data store 4 using an instruction to obtain from the data store 4 an answer to the question indicating whether the question is answered positively or negatively, and is furthermore configured to transmit to the verification controller 12 an answer in dependence upon the answer obtained from the data store 4 indicating whether the question is answered positively or negatively. Verification controller 12 is configured to receive, from the data store interfaces 14, the data indicating whether the questions are answered positively or negatively and is configured to evaluate the answers to verify if the entity meets a set of criteria (which may contain one criterion or a plurality of criteria). The verification controller 12 is further configured to transmit a response indicative of whether the entity meets the set of criteria.

As will be explained in more detail below, the verification of whether the entity satisfies the set of criteria is performed by verification controller 12 and data store interfaces 14 without aggregating any data from the data stores. One or more of the data stores 4 may store data defining one or more biometrics, such as a facial image, fingerprint, palmprint, etc, for each of a plurality of people. In such a case, as part of the verification process for an entity that is a person, verification controller 12 may be configured to retrieve data defining a biometric for the person from the data store 4 and transmit the data defining the biometric as part of (or the whole of) the response to the verification request. This is particularly useful for verification of a person who is present at the site of the verification request. For example, in the above-mentioned example of verification of whether a person is entitled to vote in a particular election, the person wishing to vote may supply his/her name and address to an official at the polling station and the verification request may be transmitted by the official to verification system 2 using a user equipment 8 such as a desk top computer, mobile telephone, etc. In response to the verification request, verification system 2 transmits a response to the requesting user equipment 8 indicating whether the person having the supplied name and address is entitled to vote and comprising data defining an image of the face of the person with the supplied name and address. The official at the polling station can then display the image on the user equipment 8 and compare the displayed image with the face of the person in front of him/her to confirm that the person is who he/she claims to be. This ensures that a person cannot get to vote by supplying the details of another person even if the other person is entitled to vote.

In the present embodiment, the verification controller 12 and each of the data store interfaces 14 comprises software deployed on a programmable computer processing apparatus, such as a server. In this embodiment, the verification controller 12 and each respective one of the data store interfaces 14 resides on a different physical server. However, a plurality of data store interfaces may reside on the same physical server. Similarly, one or more data store interfaces 14 may reside on the same physical server as the verification controller 12. Furthermore, each server may comprise a virtual server rather than a physical server.

An example of the general kind of programmable computer processing apparatus in which the verification controller 12 and each data store interface 14 may be implemented is shown in Figure 2.

Referring to Figure 2, a programmable computer processing apparatus 200 comprises a processor 202, a communications module 204, memory 206 comprising volatile memory 208 and non- volatile memory 210, and an instruction store 212 storing computer-readable instructions which, when executed by the processor 202 cause the memory 206 to be configured into a number of different data stores and cause the processor 202 to perform the processing operations as described hereinafter.

The instruction store 212 is a data storage device which may comprise a non-volatile memory, for example in the form of a read-only-memory (ROM), a magnetic computer storage device (for example a hard disk) or an optical disk, which is pre-loaded with the computer-readable instructions. Alternatively, the instruction store may comprise writeable memory, such as random access memory (RAM) and the computer-readable instructions can be input thereto from a computer program product, such as a computer-readable storage medium 220 (for example an optical disk such as a CD-ROM, DVD-ROM, etc) or a computer-readable signal 230 carrying the computer-readable instructions. As noted above, the memory 206 is configured to provide different data stores. These data stores differ depending upon whether the respective programmable computer processing apparatus 200 is implementing the verification controller 12 or a data store interface 14. More particularly, referring to Figure 3, the memory 206 in the verification controller 12 is configured to provide a plurality of data stores 300, which comprise an input verification data store 302, a question set store 304, a results store 306 and an alert data store 308. Memory 206 is also configured to provide working memory (not shown) for use by verification controller 12.

The input verification data store 302 comprises volatile memory and is configured to store input verification data received from a user equipment 8 comprising data defining the type of the verification to be performed for an entity, data defining one or more identifier attributes for the entity, data defining the identifier attribute type(s) and data defining the output destination(s), to which responses should be sent by the verification controller 12. By storing the input verification data in volatile, non-persistent memory, the data is overwritten when it is no longer needed by the verification controller 12 (that is, after the verification request from the user equipment 8 has been processed and a response has been transmitted) and the data is not retained if power to the verification controller 12 is turned off, for example due to a power failure. In this way, the verification data is not retained within permanent memory in verification controller 12 so that the privacy of the data is maintained and verification data for a plurality of entities is not aggregated to build up a database as verification requests for those entities are received. The question set store 304 comprises non-volatile memory and is configured to store a plurality of different sets of questions, each set relating to a different verification process. Within each set, there are one or more question identifiers, each question identifier defining a polar question that requires an answer indicating whether the question is answered positively or negatively.

Figure 4 shows, by way of example only, a question set stored in the question set store 304. Referring to Figure 4, the example question set stores data defining a total of "K" question identifiers. Referring to the second column 404, a question identifier is stored for each question rather than the question itself. Each question identifier may take any form which uniquely identifies the corresponding question. By way of example, Figure 4 shows the question identifiers Q , Q ...Q and Q for the illustrated set. By storing question identifiers, rather than the actual questions themselves, an unauthorised user who gains access to the question set stored in verification controller 12 can not determine the meaning of the questions. Verification controller 12 stores data (examples of which are shown in column 402) defining an order in which the question identifiers should be transmitted to the data store interfaces 14. Accordingly, in the example shown in Figure 4, question identifier Q is the first question identifier to be transmitted, followed by question identifier Q , etc. In the case of question identifier Q , this question identifier is transmitted simultaneously or sequentially to four different data store interfaces 14, which is why it is included four times in the question set illustrated in Figure 4.

For each question identifier, the verification controller 12 stores data defining the type(s) of identifier attribute(s) that need to be transmitted to a data store interface 14, together with the question identifier, in order for the data store interface 14 to provide an answer indicating whether the question is answered positively or negatively. Examples of identifier attribute type(s) are shown in column 406 of Figure 4. Thus, in the example of Figure 4, an attribute of the types "Address" should be transmitted for the question identifier Q ²³ , and attributes of the types "Name" and "Address" should be transmitted for the question identifiers Q ¹⁶ , Q ⁷⁸ and Q ⁴³ . Furthermore, for each question identifier, verification controller 12 stores data defining the data store interface 14 to which the question identifier and identifier attribute(s) should be transmitted. In this embodiment, the data defining each data store interface 14 comprises the communication address of the data store interface, although other types of data could be stored instead to define each data store interface 14. Examples of data defining the data store interfaces are shown in column 408 of Figure 4. In this example, each address is a hypertext transfer protocol (HTTP) internet address, although other forms of address could be used instead, such as internet protocol (IP) addresses. Not all of the data store interface addresses need to be fully defined. For example, in the case of question identifier Q ¹⁶ , the data store interface address is only partially defined, with the variable "[state]" being undefined. As will be explained later, verification controller 12 is configured to complete this address by determining "[state]" based upon one or more of the answers received in response to previous questions in the set.

In addition to the data for the question identifiers, a question set can also store an identifier for a biometric retrieval command. This is illustrated in the example of Figure 4 in the final row, in which the identifier "BRC" is stored. As described previously, one or more of the data stores 4 may store data defining one or more biometrics for a plurality of people. The purpose of the identifier "BRC" stored in a question set of verification controller 12 is to instruct a data store interface 14 to interrogate an operatively connected data store 4 and return the stored biometric for the person that is the subject of the verification by verification controller 12. Accordingly, in association with the identifier "BRC", the question set includes data defining the data store interface 14 to which the identifier BRC should be transmitted (this being illustrated in column 408 in the example of Figure 4) and data defining the types of identifier attributes that should be transmitted with the identifier "BRC" (this being illustrated in column 406 in the example of Figure 4). Referring again to Figure 3, results store 306 is configured to store, inter alia, the answers to questions received by the verification controller 12 from the data store interfaces 14.

Figure 5 shows, by way of example only, an illustrative results store 306 within verification controller 12, the illustrated example being based upon the question set shown by way of example in Figure 4. Referring to Figure 5, the results store 306 is configured to store data defining each question identifier from the question set, these question identifiers being illustrated in column 502 of Figure 5. For each question identifier, the results store 306 is configured to store data defining the address of the data store interface 14 to which the question identifier was transmitted by verification controller 12 (these addresses being illustrated in column 504) and data defining the answer received from the data store interface 14 indicating whether the question was answered positively or negatively (this data being stored in column 506 in this example and being illustrated as "T" or "true" indicating that the question was answered positively or "F" or "false" indicating that the question was answered negatively).

Furthermore, the results store 306 is configured to store data defining a result for each question identifier that will terminate subsequent questioning by verification controller 12. Thus, referring to column 508, questioning by verification controller 12 is terminated if all of the results received from the data store interfaces 14 to which question identifier Q ²³ was transmitted indicate that the question was answered negatively by each of the data store interfaces. In the case of respective question identifiers Q ¹⁶ and Q ⁷⁸ , questioning is terminated if the sole data store interface 14 to which the question identifier was sent transmits a result indicating that the question was answered negatively. On the other hand, in the case of question identifier Q ⁴³ , questioning is terminated if the data store interface 14 to which the question identifier was sent transmits a result indicating that the question was answered positively.

As illustrated in column 510, the results store 306 is further configured to store data defining the result of processing by verification controller 12 to determine whether the result received from a data store interface 14 (or set of data store interfaces 14) in response to a question identifier comprises a pass or fail for the entity in relation to that question identifier. In the present embodiment, verification controller 12 is configured to determine whether a result from a data store interface 14 (or set of data store interfaces) for a particular question identifier comprises a pass or a fail by comparing the result received from the data store interface(s) 14 with the result stored in column 508 that will terminate questioning for that question identifier. Thus, in the example of Figure 5, verification controller 12 has determined that the four results received for question identifier Q ²³ from the data store interfaces 14 represent a "Pass" because one of the results indicates that the question was answered positively and so the termination condition stored in column 508 (that all results should indicate that the question is answered negatively) is not satisfied. Similarly, for the question identifiers Q ¹⁶ and Q ⁷⁸ , verification controller 12 has determined that the respective answers received from the data store interfaces 14 each represent a "Pass" because these answers indicate that the respective questions were answered positively, whereas the termination condition for each of the question identifiers is that the question was answered negatively. On the other hand, for question identifier Q ⁴³ , verification controller 12 has determined that the positive answer from the data store interface 14 represents a "Fail" because the positive answer matches the termination condition stored for the question identifier in column 508.

As will be understood from the above description, and as will be explained in further detail below, answers to questions, which are required to verify whether an entity satisfies a criterion or plurality of criteria, can be obtained using data in multiple data stores 4 without any of the data stored in a data store 4 being returned to either a data store interface 14 or verification controller 12. Instead, data indicating whether a question is answered positively or negatively is returned to the data store interfaces 14 and the verification controller 12. The results stored in result store 306, therefore, do not comprise any data from a data store 4. In this way, the answers to the verification questions can be obtained using data stored in multiple data stores 4 without aggregating any data from the data stores 4.

Referring again to Figure 3, alert data store 308 is configured to store alerts to be transmitted by verification controller 12 if it is determined that the result(s) for a particular question identifier comprises a "fail", as well as data defining the output destination to which each alert should be transmitted.

Turning now to Figure 6 an example is shown of data stored in the alert data store 308 of the verification controller, the example being based upon the example question set shown in Figure 4.

Referring to Figure 6, the alert data store 308 is configured to store one or more alerts for each question identifier in a given question set. However, for security reasons, each alert is defined so that the question corresponding to the question identifier cannot be determined from the alert. As will be explained in more detail below, verification controller 12 is configured to output all of the alerts stored for a given question identifier when it is determined that the results(s) received from the data store interface(s) for the question identifier matches the termination condition stored in results store 306 for the question identifier so that a "Fail" is recorded in column 510 of results store 306 for the question identifier (an example of such a "Fail" being shown in the final row of column 510 in Figure 5 for question identifier Q ⁴³ ). Referring to the example data in Figure 6, no alerts are stored for question identifiers Q ²³ ,

16 78

Q and Q (although in other examples, alerts could be stored for these question identifiers).

On the other hand, an alert is stored for question identifier Q ⁴³ in the example data of Figure 6. This alert will cause the alert message "Polling station for [Address Line 2] has ineligible person attempting to vote" to be output when a "Fail" is recorded in column 510 of the results store 306 by verification controller 12 for question identifier Q ⁴³ . In this alert, the term "[Address Line 2]" is the second line of the address identifier attribute for the entity undergoing verification (the second line identifying the town). The alert is to be output to the output address fraud.police.gov.nesw.

Turning now to the data store interfaces 14 and Figure 7, the memory 206 of each data store interface 14 is configured to provide a plurality of data stores 700 which, in this embodiment, comprise an input verification data store 702 and an instruction store 704. Memory 206 is also configured to provide working memory (not shown) for use by data store interface 14.

Input verification data store 702 comprises volatile memory and is configured to store input verification data that is received by the data store interface 14 from the verification controller 12. This input verification data comprises data defining a question relating to an entity (this being a question identifier in this embodiment), the question requiring an answer indicating whether the question is answered positively or negatively, one or more identifier attributes for the entity and data defining the type of each identifier attribute for the entity. By storing the input verification data in volatile, non-persistent memory, the data is overwritten when it is no longer needed by the data store interface 14 (that is, after the data store interface 14 has interrogated one or more data stores 4 using the verification data and has transmitted a result to the verification controller 12) and the data is not retained if power to the data store interface 14 is turned off, for example due to a power failure. In this way, the verification data is not retained within permanent memory in data store interface 14 so that the privacy of the data is maintained and data for a plurality of entities is not aggregated to build up a database as verification data for those entities is received.

Instruction store 704 is configured to store one or more instructions for electronically interrogating the data store(s) 4 to which the data store interface 14 is operatively connected. Each instruction is linked to a question identifier such that each question identifier uniquely identifies an instruction.

The data stored in the instruction store 704 of each data store interface 14 may be different depending upon the data store(s) to which the data store interface 14 is connected. However, by way of example, Figures 8a and 8b show one example of data that may be stored in the instruction store 704 of a data store interface 14.

Referring to Figures 8a and 8b, an example is shown in which two respective instructions are stored in association with question identifiers, one instruction for the question identifier Q ⁷⁸ and one instruction for the question identifier Q ⁴³ . In addition, in the illustrated example, an instruction is stored in association with the identifier BRC for the biometric retrieval command. This instruction comprises computer-readable instruction code to retrieve data defining a biometric from a data store 4. In this example, each instruction in instruction store 704 comprises computer-readable instruction code for a structured query language (SQL) interrogation of a data store 4. However, it will be understood that the type and format of the code stored for each instruction will depend upon the type and format of the data store 4 which is to be interrogated by the instruction.

Having described the components shown in Figure 1 , the processing operations performed by those components will now be described, especially the processing operations performed by the functional components of the verification controller 12 and data store interfaces 14 in verification system 2. Figures 9a-9n show the processing operations performed in this embodiment by the components of Figure 1. Within these figures, the identity of the component performing each processing operation can be determined from the heading at the top of the column in which the processing operation is shown.

Processing operations will be described with reference to Figures 9a-9n, in which a user equipment 8 operated by a human user communicates with the verification system 2 to request verification of an entity. However, as noted above, the user equipment 8 need not be a user equipment operated by a human and instead could be a server programmed to automatically send verification requests to the verification system 2.

At step S9-2, a user equipment 8 receives an input from a user defining a type of verification to be performed, and at step S9-4 receives input defining the type(s) of identifier attribute(s) that will be input to identify the entity to be verified.

The verification to be performed may be of many different types. An example was given above of whether an entity comprising a person is entitled to vote in a particular election. However, many different types of verification are possible instead, such as whether a particular person is entitled to pass through a border check point to enter a country, whether a particular person is entitled to a particular benefit offered by a government, whether a particular vehicle is properly taxed and insured, whether a particular firearm is correctly licensed, etc. Many other examples are, of course, possible. With regard to the identifier attribute types, these will depend upon the nature of the entity to be verified. For example, in the case of a person, identifier attributes of types name, address, date of birth, passport number, social security number, etc may be used, while, in the case of a vehicle, the registration number may be used, and, in the case of a firearm, the serial number may be used. In this embodiment, each user equipment 8 runs an application programme which presents to the user a list of the verification types offered by the verification system 2 and, for each verification type, a list of the types of identifier attributes that the user can input for that particular type of verification. In this way, the user can select a verification type and also the type(s) of identifier attribute(s). At step S9-6, the user equipment 8 receives data defining identifier attribute(s) for the entity to be verified, each identifier attribute being of a type selected at step S9-4. Accordingly, at this step, the user equipment 8 may receive data defining, for example, a name, address, etc.

At step S9-8, user equipment 8 receives details of each output destination to which the verification system 2 is to transmit a response. Such an output destination will typically be the user equipment 8 itself but may comprise another output destination in addition to, or instead of, the user equipment 8 itself. In this way, third party user equipment 8 can be specified to which responses are to be transmitted.

Steps S9-10 and S9-12, the user equipment 8 initiates communication with the verification controller 12 via a communication link 10, and the user equipment 8 and the verification controller 12 establish a secure connection for subsequent transmission therebetween. In this embodiment, an HTTPS connection is established as the secure connection, but other forms of secure connection could be established instead. All subsequent communication between the user equipment 8 and verification controller 12 is via the established secure connection. At step S9-14, the user equipment 8 transmits data to the verification controller 12 defining the verification type, identifier attribute type(s), identifier attribute(s) and output destination(s) previously received at steps S9-2, S9-4, S9-6 and S9-8.

At step S9-16, verification controller 12 receives input verification data comprising the data defining the verification type, identifier attribute type(s), identifier attribute(s) and output destination(s) transmitted by the user equipment 8. This data is written into input verification data store 302 by verification controller 12.

At step S9-18, verification controller 12 selects a question set from the plurality of question sets stored in question set store 304 in dependence upon the type of verification to be performed and the type of the identifier attributes provided for the entity to be verified. At step S9-20, verification controller 12 identifies in the selected question set the data store interface(s) 14 to which the next question identifier in the question set is to be transmitted (this being the first question identifier in the question set the first time S9-20 is performed). Referring to the example shown in Figure 4, for the first question identifier, Q ²³ in the illustrated question set, verification controller 12 would select the data store interfaces 14 defined in column 408 for this question identifier.

At steps S9-22 and S9-24, verification controller 12 initiates communication with each of the data store interfaces 14 identified at step S9-20 via communication links 16, and establishes a respective secure connection with each of these data store interfaces 14. In this embodiment, each secure connection comprises an HTTPS connection, although other types of secure connection could be established instead. All subsequent communication between verification controller 12 and the data store interface(s) is via the established secure connection(s).

At step S9-26, verification controller 12 transmits output verification data to each of the data store interfaces identified at step S9-20 comprising data defining the question identifier, the identifier attribute type(s) and the identifier attribute(s). The data to be transmitted at step S9-26 is determined by verification controller 12 from the data stored in the question set store 304. It should be noted that not all of the identifier attribute types and identifier attributes received by verification controller 12 at step S9-16 need be transmitted to a data store interface 14 at step S9-26. More particularly, referring to the example shown in Figure 4, for the first question identifier in the question set, verification controller 12 would transmit data at step S9-26 defining the question identifier Q , the identifier attribute type "Address" and the identifier attribute for the address itself received at step S9-16, even though other identifier attribute types and identifier attributes may have been received at step S9-16. In this embodiment, data defining the question identifier, identifier attribute type(s) and identifier attribute(s) is transmitted together in a single step at step S9-26. However, instead, data defining the verification type, identifier attribute type(s) and identifier attribute(s) could be transmitted separately in sequential steps. At step S9-28, each data store interface 14 with which a secure connection was established in steps S9-22 and S9-24 receives input verification data comprising data defining the question identifier, identifier attribute type(s) and identifier attribute(s) transmitted by verification controller 12 at step S9-26. Each data store interface 14 stores the received data in input verification data store 702.

At step S9-30, each data store interface 14 which received the input verification data at step S9-28 selects a stored instruction from its instruction store 704 in dependence upon the received question identifier. More particularly, referring to the example shown in Figures 8 a and 8b, each data store interface 14 selects the instruction that is stored in association with the received question identifier.

As noted above, each instruction stored in instruction store 704 of a data store interface 14 comprises computer-readable instruction code for interrogating a data store 4 to cause the data store 4 to return an answer to the question defined by the associated question identifier indicating whether the question is answered positively or negatively. Accordingly, at step S9-32, each data store interface 14 interrogates a data store with which it is operatively connected using the instruction selected at step S9-30 and the identifier attribute type(s) and identifier attribute(s) received at step S9-28. More particularly, each data store interface 14 transmits the selected instruction, the identifier attribute type(s) and the identifier attribute(s) to the data store 4 via the communication link 6 operatively connecting the data store interface 14 with the data store 4.

In step S9-34, the data store 4 receives the data transmitted by the data store interface 14, and executes the received instruction in relation to the received identifier attribute type(s) and identifier attribute(s).

In step S9-36, the data store 4 transmits data back to the data store interface 14 which sent the instruction, the transmitted data indicating whether the question defined by the instruction is answered positively or negatively based on the data stored in the data store 4 for the entity identified by the identifier attribute(s). In this embodiment, as noted above, the data transmitted by the data store 4 at step S9-36 comprises data defining a "true" or "false" reply to the question. The "true" and "false" answers can be conveyed using any format of bits that will be understood by the receiving data store interface 14 as the appropriate "true" or "false" answer. In addition, instead of transmitting data defining a "true" or "false" answer, any other form of data indicating whether the question is answered positively or negatively could be transmitted, such as data defining a "yes" or "no" answer.

At step S9-38, the initiating data store interface 14 receives the "true" or "false" reply from the data store 4 and at step S9-40 transmits a result for the current question identifier back to the verification controller 12 defining whether the question related to the question identifier is answered positively or negatively.

At step S9-42, verification controller 12 receives the result "true" or "false" for the current question identifier and, in step S9-44 stores the result in the results store 306 in association with the question identifier. Thus, referring to the example shown in Figure 5, verification controller 12 stores the result in column 506. Verification controller 12 also stores, in association with the question identifier and result, the identity of the data store interface 14 which transmitted the result. In this embodiment, the identity of the data store interface 14 is determined from the secure connection over which the result was received. Referring again to the example shown in Figure 5, the identity of the data store interface 14 is stored in column 504.

At step S9-46, verification controller 12 disconnects each secure connection previously established at step S9-22 and S9-24 with the data store interface(s) 14.

At step S9-48, verification controller 12 determines whether the received result(s) terminates the questioning by the verification controller. More particularly, referring to the example shown in Figure 5, verification controller 12 compares the result(s) received at step S9-42 and stored in column 506 at step S9-44 with the termination condition stored in column 508 to determine if there is a match, indicating that questioning should be terminated. If it is determined at step S9-48 that questioning should not be terminated, processing proceeds to step S9-50, at which verification controller 12 determines whether there is another question identifier in the question set selected at step S9-18 that remains to be transmitted. If it is determined that there is another question identifier in the question set, then processing returns to step S9-20, and steps S9-20 to S9-50 are repeated until it is determined at step S9-48 that a result terminates questioning or it is determined at step S9- 50 that there are no further question identifiers in the question set.

When it is determined at step S9-48 that a result terminates questioning or when it is determined at step S9-50 that there are no further question identifiers in the question set, then processing proceeds to step S9-52, at which verification controller 12 evaluates the results stored in results store 306 to determine an overall result of the verification process for the entity. More particularly, in this embodiment, for each question identifier in the question set, verification controller 12 compares the received result (stored in column 506 in the example of Figure 5) with the stored termination condition (stored in column 508 in the example of Figure 5) and determines whether the result for the question identifier is a "pass" (the received result does not match the stored termination condition) or a "fail" (the received result does match the second termination condition). The pass or fail result is then recorded, for example in column 510 in the example of Figure 5. In this embodiment, verification controller 12 is configured to determine that the overall result is a "pass" if the result for each question identifier in the question set is a "pass", otherwise the overall result is determined to be a "fail". However, in other embodiments, depending upon the verification type, the overall result may be determined to be a "pass" even if the result for one or more individual question identifiers is a "fail".

At step S9-54, verification controller 12 determines whether any alerts are to be issued based upon the received results. More particularly, in this embodiment, for each question identifier for which the individual result (that is, the result stored in column 510 in the example of Figure 5) is determined to be a "fail", verification controller 12 reads the data stored in alert data store 308 to determine if one or more alerts are to be issued for that question identifier. Referring again to the example shown in Figure 5, the individual result stored in column 510 for question identifier Q ⁴³ is a "fail", and therefore verification controller 12 would read the alert data stored in alert data store 308 for question identifier Q ⁴³ (shown by way of example in Figure 6) and would determine that one alert is to be issued. If it is determined at step S9-54 that one or more alerts is to be issued, then processing proceeds to step S9-56, at which verification controller 12 reads the alert data from the alert data store 308 for each alert to be issued and determines the alert output address by reading the alert output address data stored in alert data store 308 and determining any missing information therein (such as the information "[Address Line 2]" for Alert 1 of question identifier Q ⁴³ in the example of Figure 6),

On the other hand, if it is determined at step S9-54 that no alerts are to be issued, then the processing at step S9-56 is omitted. At step S9-58, verification controller 12 determines whether the verification type (defined by the data received at step S9-16) requires data defining a biometric to be provided as part of the response. More particularly, as described previously, the provision of data defining a biometric may be useful for verification of a person who is present at the site of the verification request.

If it is determined at step S9-58 that data defining a biometric is not required, then processing proceeds to step S9-88. On the other hand, if it is determined at step S9-58 that data defining a biometric is required, then processing proceeds to step S9-60. At step S9-60, verification controller 12 identifies, from the question set selected at step S9-18, the data store interface 14 to which the identifier for the biometric retrieval command should be transmitted. Referring to the example shown in Figure 4, the data defining the identifier for the biometric retrieval command, "BRC", is stored in the final row of the question set and so, in that example, verification controller 12 would determine the data store interface by reading the data stored in column 408 of the final row. If more than one biometric is to be retrieved and transmitted, and if these different biometrics are stored in different data stores 4, then verification controller 12 is configured to identify at steps S9-60 the different data store interfaces 14 operatively connected to these different data stores.

At steps S9-62 and S9-64, verification controller 12 communicates with each data store interface 14 identified at step S9-60 via communication links 16 to establish a respective secure connection with each of the data store interfaces 14. In this embodiment, each secure connection comprises an HTTPS connection, although other types of secure connection could be established instead. All subsequent communication between verification controller 12 and the data store interface(s) 14 is via the established respective secure connection(s).

At step S9-66, verification controller 12 transmits data defining the identifier for the biometric retrieval command, relevant identifier attribute type(s) and relevant identifier attribute(s) to each data store interface 14 with which the secure connection was established at steps S9-62 and S9-64 (the relevant identifier attribute type(s) being those stored in association with the identifier for the biometric retrieval command in question set 304; for example in column 406 of the final row in the example of Figure 4). In this way, rather than transmitting an executable biometric retrieval command, verification controller 12 transmits data defining an identifier which the receiving data store interface 14 will recognise and use to identify and retrieve a stored executable command (in the same way that verification controller 12 transmits a question identifier rather than the question itself). More particularly, as previously illustrated in the example data shown in Figures 8 a and 8b, the data store interface 14 that is operatively connected with a data store 4 storing biometrics stores in instruction store 704 an instruction comprising computer-executable code for retrieving a biometric from the data store 4, this instruction being stored in association with the identifier that the verification controller 12 transmits as the identifier for the biometric retrieval command.

At step S9-68, each data store interface 14 identified at step S9-62 receives the identifier for the biometric retrieval command and relevant identifier attribute type(s) and identifier attribute(s) that were transmitted to it by the verification controller 12 at step S9-66. At step S9-70, each data store interface 14 selects a stored instruction from instruction 704 in dependence upon the received identifier by selecting the instruction that is stored in association with the identifier that matches the received identifier. At step S9-72, each data store interface 14 interrogates the operatively connected data store 4 storing the biometrics with the selected instruction in relation to the relevant identifier attribute type(s) and identifier attribute(s), so as to instruct the data store 4 to return the biometric(s) for the entity defined by the identifier attribute(s). At step S9-74, each data store 4 to which data was transmitted at step S9-72 receives and executes the instruction in relation to the identifier attribute type(s) and identifier attribute(s) and, at step S9-76, retrieves the biometric(s) for the entity defined by the identifier attribute(s) and transmits the retrieved biometric(s) to the data store interface 14 which transmitted the data at step S9-72.

At step S9-78, each data store interface 14 receives the biometric(s), and at step S9-80 transmits the biometric(s) to the verification controller 12.

At step S9-82, verification controller 12 receives the biometric(s) and, at step S9-84, disconnects each secure connection that was previously established with a data store interface 14 at steps S9-62 and S9-64.

At this stage of the processing, verification controller 12 has determined the overall result of the verification processing (step S9-52), has determined any alert data to be transmitted and the output destination for the alert data (step S9-56), and has retrieved any biometrics to be transmitted (step S9-82).

At step S9-88, verification controller 12 determines whether a response is to be transmitted to both the user equipment 8 that initiated the verification request by transmitting data at step S9-14 and at least one other output destination. In this embodiment, the determination at step S9-88 is achieved by the verification controller 12 reading details of the output destinations received at step S9-16. If it is determined at step S9-88 that a response is not to be transmitted to both the user equipment 8 and at least one other output destination, then processing proceeds to step S9- 104. On the other hand, if it is determined at step S9-88 that a response is to be transmitted to both the user equipment 8 and at least one other output destination, then processing proceeds to step S9-90, at which verification controller 12 transmits a response to the initiating user equipment 8 via the secure connection established at steps S9-10 and S9-12. In this embodiment, the response comprises the overall result determined at step S9-52, any alerts to be transmitted to the user equipment (determined at steps S9-54 and S9-56) and any biometrics retrieved at step S9-82.

The processing operations performed by the user equipment 8 in response to the transmission of data at step S9-90 will be described later. Continuing with the processing operations performed by verification controller 12, at step S9-92, verification controller 12 establishes a secure connection to each additional output destination to which it was determined at step S9-88 that the response is to be sent. In this embodiment, each secure connection comprises an HTTPS connection, although other types of secure connection can be established instead. All subsequent communication between the verification controller 12 and each of the additional output destinations is via a respective secure connection that is established.

At step S9-94, verification controller 12 transmits the response to each output destination with which a secure connection was established, the response comprising the overall result, any alerts to be transmitted to that output destination, and any biometrics that were retrieved.

The processing operations performed by the user equipment at each output destination in response to the processing operations at steps S9-92 and S9-94 will be described later. Continuing with the processing operations performed by verification controller 12, at step S9-96, verification controller 12 determines whether any alert needs to be sent to an alert output address other than the user equipment 8 and each additional output destination to which data has already been transmitted at steps S9-90 and S9-94. More particularly, in this embodiment, verification controller 12 reads the alert output addresses obtained at step S9-56 to determine where any alert is to be output to a destination other than the user equipment 8 and additional output destination to which data was transmitted in steps S9-90 and S9-94.

If it is determined at step S9-96 that no alerts are to be transmitted to further addresses, then processing proceeds to step S9-102. On the other hand, if it is determined at step S9- 96 that an alert is to be transmitted to at least one further alert output address, then processing proceeds to step S9-98, at which verification controller 12 establishes a secure connection with the user equipment at each further alert output address. In this embodiment, each secure connection comprises an HTTPS secure connection, although other types of secure connection could be established instead. All subsequent communication between verification controller 12 and the user equipment at each further alert output address is via a respective established secure connection.

At step S9-100, verification controller 12 transmits each remaining alert to the alert output address specified for that alert. The processing operations performed by the user equipment at each alert output address in response to the processing at steps S9-98 and S9-100 will be described later. Continuing with the processing operations performed by verification controller 12, following the transmission at step S9-100, or if it is determined at step S9-96 that no further alert output addresses exist, processing proceeds to step S9-102, at which verification controller 12 deletes all of the results data that it wrote into the results store 306. By way of example, with reference to Figure 5, verification controller 12 would delete the data written into columns 504, 506 and 510, but not the data in columns 502 and 508 (as this is pre-stored data that will be used for subsequent verifications). Followin the processing at step S9-102, the processing operations of verification controller 12 are complete. Referring again to step S9-88, if it is determined that a response is not to be transmitted to both the user equipment 8 and at least one other output destination, then processing proceeds to step S9-104, at which verification controller 12 determines whether a response is to be transmitted to only the user equipment 8 that initiated the verification request at step S9-14.

If it is determined at step S9-104 that the response is not to be transmitted to only the user equipment 8, then processing proceeds to step S9-116. On the other hand, if it is determined that the response is to be transmitted only to the user equipment 8, then processing proceeds to step S9-106, at which verification controller 12 transmits the response to the user equipment 8 via the secure connection established at steps S9-10 and S9-12. In this embodiment, the response comprises the overall result, any alerts to be transmitted to the user equipment 8, and any biometrics that were retrieved. The processing operations performed by the user equipment 8 in response to the transmission at step S9-106 will be described later. Continuing with the processing operations performed by verification controller 12, processing proceeds to step S9-108, at which verification controller 12 determines whether any alert needs to be transmitted to a destination other than the user equipment 8. The processing operations performed at step S9-108 and subsequent steps S9-110, S9-112 and S9-1 14 correspond to the processing operations performed at steps S9-96, S9-98, S9-100 and S9-102, respectively. As these processing operations have been described above, they will not be described again here.

As noted above, if it is determined at step S9-104 that the response is not to be transmitted only to the user equipment 8, then processing proceeds to step S9-116, at which verification controller 12 determines whether the response is to be transmitted only to one or more output destinations other than the user equipment 8.

If it is determined at step S9-116 that the response is not to be transmitted only to one or more output destinations other than the user equipment 8, then processing proceeds to step S9-130. On the other hand, if it is determined at step S9-116 that the response is to be transmitted only to one or more output destinations other than the user equipment 8, then processing proceeds to step S9-118, at which verification controller 12 establishes a secure connection to each output destination to which the response is to be sent. In this embodiment, each secure connection is an HTTPS secure connection, although other types of secure connection can be established instead. All subsequent communication between verification controller 12 and the user equipment at each output destination is via a respective established secure connection.

At step S9-120 verification controller 12 transmits a response to the user equipment at each output destination with which a secure connection was established at step S9-118. In this embodiment, the response comprises the overall result, any alerts to be transmitted to that particular output destination, and any biometrics that were retrieved.

The processing operations performed by the user equipment at each output destination in response to the processing at steps S9-118 and S9-120 will be described later. Continuing with the processing operations performed by verification controller 12, processing proceeds to step S9-122, at which verification controller 12 determines whether any alert needs to be transmitted to a destination other than the destination(s) to which the response was transmitted at step S9-120. At step S9-122, and subsequent steps S9-124, S9-126 and S9-128, verification controller 12 performs processing operations corresponding to those at steps S9-96, S9-98, S9-100 and S9-102, respectively. As these processing operations have already been described above, they will not be described again here.

As noted above, if it is determined at step S9-116 that the response is not to be transmitted only to one or more output destinations other than the initiating user equipment 8, then processing proceeds to step S9-130, at which verification controller 12 determines if there are any untransmitted alerts. At step S9-130, and subsequent steps S9-132, S9-134 and S9- 136, verification controller 12 performs processing operations corresponding to those at steps S9-96, S9-98, S9-100 and S9-102, respectively. As these processing operations have already been described above, they will not be described again here. Referring now to Figure 91, the processing operations performed by user equipment 8 in response to the transmission of the response data by verification controller 12 at step S9-90 or step S9-106 will be described. At step S9-138, user equipment 8 receives the response comprising the overall result, any alerts to be transmitted to the user equipment 8 and any retrieved biometrics. At step S9- 140, having received the response, the user equipment 8 disconnects the secure connection with verification controller 12. At step S9-142, the user equipment 8 outputs the overall result, any received alerts and any received biometrics, for example by displaying these on a display of the user equipment 8 for viewing by a user.

Turning now to Figure 9m, the processing operations are shown that are performed by a user equipment at each output destination, other than the user equipment 8 that instructed the verification request, in response to the processing by verification controller 12 at steps S9-92 and S9-94 or steps S9-1 18 and S9-120.

At step S9-144, in response to the processing by verification controller 12 at step S9-92 or step S9-118, the user equipment at the output destination communicates with verification controller 12 to establish a secure connection.

At step S9-146, the user equipment at the output destination receives the response data transmitted by verification controller 12 at step S9-94 or step S9-120, this response data comprising, in this embodiment, data defining the overall result, any alerts to be transmitted to that output destination and any retrieved biometrics.

At Step S9-148, having received the response data, the user equipment of the output destination disconnects the secure connection with verification controller 12. At step S9-150, the user equipment 8 at the output destination outputs the overall result, any received alerts and any received biometrics, for example by displaying them on a display of the user equipment 8 for viewing by a user. Turning now to Figure 9n, there are shown the processing operations performed by a user equipment at each alert output address in response to the processing operations performed by verification controller 12 at steps S9-98 and S9-100, S9-110 and S9-112, S9-124 and S9-126, or S9-132 and S9-134. At step S9-152, in response to the verification controller performing processing at step S9- 98, S9-1 10, S9-124 or S9-132, the user equipment 8 at the alert output address communicates with verification controller 12 to establish the secure connection.

At step S9-154, in response to the processing by verification controller 12 at step S9-100, S9-112, S9-126 or S9-134, the user equipment 8 at the alert output address receives the transmitted alert.

At step S9-156, having received the alert, the user equipment 8 at the alert output address disconnects the secure connection with verification controller 12.

At step S9-158, the user equipment 8 at the alert output address outputs the received alert, for example by displaying it on a display of the user equipment 8 for viewing by a user.

Having described the processing operations above, it will be understood that the computer processing apparatus 200 of the verification controller 12 is configured to provide not only the input verification data store 302, question set store 304, results store 306 and alert data store 308, but also to provide functional processing units as shown in Figure 10 comprising connection controller 1002, input verification data receiver 1004, question set selector 1006, question controller 1008, output verification data transmitter 1010, results receiver 1012, results analyser 1014, alert generator 1016, biometric data retriever 1018, output controller 1020 and response and alert transmitter 1022. Connection controller 1002 is arranged to perform the processing operations at steps S9- 12, S9-22, S9-46, S9-62, S9-84, S9-92, S9-98, S9-110, S9-118, S9-124 and S9-132.

Input verification data receiver 1004 is arranged to perform the processing operations at ste S9-16.

Question set selector 1006 is arranged to perform the processing operations at step S9-18.

Question controller 1008 is arranged to perform the processing operations at steps S9-20, S9-50, S9-102, S9-114, S9-128 and S9-136.

Output verification data transmitter 1010 is arranged to perform the processing operations at step S9-26. Results receiver 1012 is arranged to perform the processing operations at steps S9-42 and S9-44.

Results analyser 1014 is arranged to perform the processing operations at steps S9-48 and S9-52.

Alert generator 1016 is arranged to perform the processing operations at steps S9-54 and S9-56.

Biometric data retriever 1018 is arranged to perform the processing operations at steps S9- 58, S9-60, S9-66 and S9-82.

Output controller 1020 is arranged to perform the processing operations at steps S9-88, S9- 96, S9-104, S9-108, S9-116, S9-122 and S9-130. Response and alert transmitter 1022 is arranged to perform the processing operations at steps S9-90, S9-94, S9-100, S9-106, S9-112, S9-120, S9-126 and S9-134. It will be further understood that the computer processing apparatus 200 of each data store interface 14 is configured to provide not only input verification data store 702 and instruction store 704, but also to provide the functional processing units shown in Figure 11 comprising connection controller 1102, input verification data receiver 1104, instruction selector 1106, data store interrogator 1108, interrogation response receiver 1110 and result transmitter 1112.

Connection controller 1102 is arranged to perform the processing operations at steps S9-24 and S9-64.

Input verification data receiver 1104 is arranged to perform the processing operations at steps S9-28 and S9-68.

Instruction selector 1106 is arranged to perform the processing operations at steps S9-30 and S9-70.

Data store interrogator 1 108 is arranged to perform the processing operations at step S9-32 and, if a biometric retrieval command is stored in the data store interface, step S9-72. Interrogation response receiver 1110 is arranged to perform the processing operations at step S9-38 and, if a biometric retrieval command is stored in the data store interface, step S9-78.

Result transmitter 1 112 is arranged to perform the processing operations at steps S9-40 and S9-80.

To further illustrate the processing operations performed by the components in Figure 1 , and in particular the processing operations performed by verification controller 12 and data store interfaces 14, a simplified, theoretical example will now be described.

The simplified example takes place in a country called "NESW" which is made up of four states, namely North State, East State, South State and West State. It is assumed that an election is taking place in the country and that only people who are eighteen years of age or older and are recorded as being resident in one of the states of NESW are entitled to vote in the election. It is further assumed that a lady visits a polling station to vote and that she informs an official at the polling station prior to voting that her name is Jane Smith and that she lives at 2 Eastway, Eastton, East State, EK20 ESW, without providing any paper credentials to confirm these details. In order to check the person's entitlement to vote, the official uses a user equipment 8, such as a desk top computer at the polling station or a mobile telephone, to request verification system 2 to verify if the person satisfies the necessary entitlement criteria to vote.

More particularly, referring back to Figure 9a, at step S9-2, the user equipment 8 operated by the official receives an input defining the verification type "Entitlement to vote in an election in NESW". At steps S9-4 and S9-6, the user equipment 8 receives inputs from the official defining the identifier attribute types and identifier attributes shown in Figure 12, in accordance with the name and address provided by the lady claiming to be entitled to vote.

At step S9-8, in this example no details of any output destination other than the user equipment 8 operated by the official are entered, so that the response from the verification system 2 will be transmitted to only the user equipment 8 operated by the official.

At steps S9-10 and S9-12, the user equipment 8 operated and verification controller 12 establish a secure connection for subsequent communication.

At step S9-14, user equipment 8 transmits data to verification controller 12 defining the verification type "Entitlement to vote in an election in NESW", as well as the identifier attribute types and identifier attributes shown in Figure 12. The data transmitted by user equipment 8 is received by verification controller 12 at step S9-16. At step S9-18, verification controller 12 selects the questions set from question set store 304 that contains questions for verifying if a person is entitled to vote in an election in NESW based upon identifier attribute types provided for the person.

At step S9-20, verification controller 12 reads the data stored in the selected question set so as to determine the data store interface(s) 14 to which the first question identifier should be transmitted.

Figure 13 shows the data stored for the selected question set in this example, wherein the data store interfaces identified by the data stored in column 1302 comprise the following: dsi.northestate.gov.nesw: the data store interface 14 for a data store owned and operated by the local government of North State and containing state property-tax records for the residents of North State. dsi.eaststate.gov.nesw: the data store interface 14 for a data store owned and operated by the local government of East State and containing state property-tax records for the residents of East State. dsi.southstate.gov.nesw: the data store interface 14 for a data store owned and operated by the local government of South State and containing state property-tax records for the residents of South State. dsi.weststate.gov.nesw: the data store interface 14 for the data store interface 14 for a data store owned and operated by the local government of West State and containing state property-tax records for the residents of West State. dsi.[state].gov.nesw: the data store interface 14 for one of the data stores owned and operated by North State, East State, South State or West State, where "[state]" indicates that it remains to be determined which of these four data store interfaces is the one to be used for question identifier Q ¹⁶ . dsi.postoffice.gov.nesw: the data store interface for a national data store holding country-wide data comprising names, postal addresses and any instructions by a particular person at a particular address to forward his/her mail to a different address at which the person is now resident because the person has moved house. dsi.birthsanddeaths.gov.nesw: the data store interface for a national data store holding country-wide data comprising the date of birth, date of death and a biometric for each citizen of the country NESW comprising an image of the face of the citizen.

Accordingly, based upon the data stored in the selected question set of this example, verification controller 12 at step S9-20 identifies four data store interfaces 14 as the data store interfaces to which the first question identifier Q ²³ should be transmitted, namely dsi.northstate.gov.nesw, dsi.eaststate.gov.nesw, dsi.southstate.gov.nesw and dsi.weststate.gov.nesw.

At steps S9-22 and S9-24, verification controller 12 establishes a respective secure connection with each of the four data store interfaces 14 identified at step S9-20. At step S9-26, verification controller 12 transmits output verification data to each of the four identified data store interfaces, the output verification data comprising data defining the question identifier Q ²³ as well as the identifier attribute types and identifier attributes shown in Figure 14 (these being the address identifier attribute types and address data received from the user equipment 8 at step S9-16).

At step S9-28, each of the four data store interfaces 14 receives the data transmitted from verification controller 12 at step S9-26.

In the present embodiment, the subsequent processing at steps S9-30 to S9-46 is performed in parallel for each of the four receiving data store interfaces 14 (although in other embodiments it could be performed sequentially). However, for ease of understanding, the processing performed for each separate data store interface 14 will be described separately and sequentially in the order of dsi.northstate.gov.nesw, dsi.eaststate.gov.nesw, dsi.southstate.gov.nesw and then dsi.weststate.gov.nesw.

Figure 15a shows the data stored in the instruction store 704 of the data store interface dsi.northstate.gov.nesw.

At Step S9-30, the data store interface dsi.northstate.gov.nesw selects the instruction

SELECT IF(COUNT(*)>0,T,'0') as result FROM NORTH STATE

WHERE Address Line 1 = "[Address Line 1]"

AND Address Line 2 = "[Address Line 2]"

AND Address Line 3 = "[Address Line 3]"

AND Postcode = "[POSTCODE]" as this is the instruction that is stored in instruction store 704 in association with the question identifier Q ²³ that was received at step S9-28. In English, the polar question defined by this instruction is "Is there a stored address that matches the supplied [Address] ?", where "[Address]" is the address identifier attributes received at step S9-28. The purpose of this question is to determine whether the address given by the person at the polling station claiming to be entitled to vote is a valid address in North State.

At step S9-32, dsi.northstate.gov.nesw interrogates its data store 4 with the instruction selected at step S9-30 in relation to the identifier attribute types and identifier attributes received at step S9-28. As noted previously, each instruction stored in the instruction store 704 of a data store interface 14 in association with a question identifier is a polar question requiring the data store to return data indicating whether the question is answered positively or negatively. Accordingly, at steps S9-34 and S9-36, the data store 4 that is operatively connected to dsi.northstate.gov.nesw receives and executes the instruction in relation to the provided identifier attribute types and identifier attributes, and transmits data back to the data store interface 14 indicating whether the question is answered positively or negatively for the data stored within the data store. In the present example, the data stored in the data store 4 owned and operated by the local government of North State is shown in Figure 16. As will be seen from this figure, no stored address matches the input address "2 Eastway, Eastton, East State, EK20 ESW". Accordingly, at step S9-36, the data store 4 transmits data defining "false", which is received by dsi.northstate.gov.nesw at step S9-38.

At step S9-40, dsi.northstate.gov.nesw transmits data defining the answer "false" to verification controller 12 for question identifier Q ²³ and this data is received by verification controller 12 at step S9-42.

At step S9-44, verification controller 12 stores the received result in results store 306 in association with the question identifier Q ²³ and the data store interface dsi.northstate.gov.nesw. This is schematically illustrated in Figure 17, in which the "false" result is shown stored in column 506 of the first row and "dsi.northstate.gov.nesw" is stored in column 504 of the first row.

At step S9-46, verification controller 12 disconnects the secure connection with the data store interface dsi.northstate.gov.nesw. Referring again to step S9-30, the processing by the data store interface dsi.eaststate.gov.nesw will now be described.

In this example, the data stored in the instruction store 704 of the data store interface dsi.eaststate.gov.nesw is shown in Figure 15b.

At step S9-30, dsi.eaststate.gov.nesw selects the following instruction stored in association with the question identifier Q ²³

SELECT IF(COUNT(*)>0,T, ') as result FROM EAST STATE

WHERE Address Line 1 = "[Address Line 1]"

AND Address Line 2 = "[Address Line 2]"

AND Address Line 3 = "[Address Line 3]"

AND Postcode = "[POSTCODE]" As noted previously, in English, this instruction corresponds to the polar question "Is there a stored address that matches the supplied [Address]?". The purpose of this question is to determine whether the address given by the person at the polling station claiming to be entitled to vote is a valid address in East State.

At step S9-32, the data store interface dsi.eaststate.gov.nesw interrogates the operatively connected data store 4 owned and operated by the local government of East State using the selected instruction in relation to the identifier attributes types and identifier attributes received at step S9-28 (these being the identifier attribute types and identifier attributes shown in Figure 14).

In response, at steps S9-34 and S9-36, the data store 4 owned and operated by the local government of East State receives and executes the instruction in relation to the provided identifier attribute types and identifier attributes, and transmits data defining whether the question is answered positively or negatively.

Figure 18 shows the data stored in this example in the data store owned and operated by the local government of East State. As will be seen, this data contains an address corresponding to the input address "2 Eastway, Eastton, East State, EK20 ESW". Accordingly, at step S9-36, the data store 4 returns data defining the answer "true", which is received by the data store interface dsi.eaststate.gov.nesw at step S9-38.

At step S9-40, the result "true" is transmitted by the data store interface dsi.eaststate.gov.nesw to verification controller 12 in relation to the question identifier Q .

At steps S9-42 and S9-44, verification controller 12 receives the result "true" and stores it in results store 306 in association with the question identifier Q ²³ and the data store interface dsi.eaststate.gov.nesw. This storage is schematically illustrated in Figure 19, in which the result "true" is stored in column 506 of the second row and "dsi.eaststate.gov.nesw" is stored in column 504 of the second row. At step S9-46, verification controller 12 disconnects the secure connection with the data store interface dsi.eaststate.gov.nesw.

Referring again to step S9-30, the processing by the data store interface dsi.southstate.gov.nesw will now be described.

In this example, the data stored in the instruction store 704 of the data store interface dsi.southstate.gov.nesw is shown in Figure 15c. At step S9-30, dsi.southstate.gov.nesw selects the following instruction stored in association with the question identifier Q

SELECT IF(COU T(*)>0,T,O') as result FROM SOUTH STATE

WHERE Address Line 1 = "[Address Line 1]"

AND Address Line 2 = "[Address Line 2]"

AND Address Line 3 = "[Address Line 3]"

AND Postcode - "[POSTCODE]"

As noted previously, in English, this instruction corresponds to the polar question "Is there a stored address that matches the supplied [Address]?". The purpose of this question is to determine whether the address given by the person at the polling station claiming to be entitled to vote is a valid address in South State.

At step S9-32, the data store interface dsi.southstate.gov.nesw interrogates the operatively connected data store 4 owned and operated by the local government of South State using the selected instruction in relation to the identifier attributes types and identifier attributes received at step S9-28 (these being the identifier attribute types and identifier attributes shown in Figure 14).

In response, at steps S9-34 and S9-36, the data store 4 owned and operated by the local government of South State receives and executes the instruction in relation to the provided identifier attribute types and identifier attributes, and transmits data defining whether the question is answered positively or negatively. Figure 20 shows the data stored in this example in the data store owned and operated by the local government of South State. As will be seen, this data does not contain any address matching the input address "2 Eastway, Eastton, East State, EK20 ESW". Accordingly, at step S9-36, the data store 4 returns data defining the answer "false", which is received by the data store interface dsi.southstate.gov.nesw at step S9-38.

At step S9-40, the result "false" is transmitted by the data store interface dsi.southstate.gov.nesw to verification controller 12 in relation to the question identifier Q ²³ .

At steps S9-42 and S9-44, verification controller 12 receives the result "false" and stores it in results store 306 in association with the question identifier Q ²³ and the data store interface dsi.southstate.gov.nesw. This storage is schematically illustrated in Figure 21, in which the result "false" is stored in column 506 of the third row and "dsi.southstate.gov.nesw" is stored in column 504 of the third row.

At step S9-46, verification controller 12 disconnects the secure connection with the data store interface dsi.southstate.gov.nesw.

Referring again to step S9-30, the processing by the data store interface dsi.weststate.gov.nesw will now be described.

In this example, the data stored in the instruction store 704 of the data store interface dsi.weststate.gov.nesw is shown in Figure 15d.

At step S9-30, dsi.weststate.gov.nesw selects the following instruction stored in association with the question identifier Q ²³

SELECT IF(COUNT(*)>0,'170') as result FROM WEST STATE

WHERE Address Line 1 = "[Address Line 1]"

AND Address Line 2 = "[Address Line 2]"

AND Address Line 3 = "[Address Line 3]" AND Postcode = "[POSTCODE]"

As noted previously, in English, this instruction corresponds to the polar question "Is there a stored address that matches the supplied [Address]?". The purpose of this question is to determine whether the address given by the person at the polling station claiming to be entitled to vote is a valid address in West State.

At step S9-32, the data store interface dsi.weststate.gov.nesw interrogates the operatively connected data store 4 owned and operated by the local government of West State using the selected instruction in relation to the identifier attributes types and identifier attributes received at step S9-28 (these being the identifier attribute types and identifier attributes shown in Figure 14).

In response, at steps S9-34 and S9-36, the data store 4 owned and operated by the local government of West State receives and executes the instruction in relation to the provided identifier attribute types and identifier attributes, and transmits data defining whether the question is answered positively or negatively.

Figure 22 shows the data stored in this example in the data store owned and operated by the local government of West State. As will be seen, this data does not contain any address matching the input address "2 Eastway, Eastton, East State, EK20 ESW". Accordingly, at step S9-36, the data store 4 returns data defining the answer "false", which is received by the data store interface dsi.weststate.gov.nesw at step S9-38.

At step S9-40, the result "false" is transmitted by the data store interface dsi.weststate.gov.nesw to verification controller 12 in relation to the question identifier Q ²³ .

At steps S9-42 and S9-44, verification controller 12 receives the result "false" and stores it in results store 306 in association with the question identifier Q ²³ and the data store interface dsi.weststate.gov.nesw. This storage is schematically illustrated in Figure 23, in which the result "false" is stored in column 506 of the fourth row and "dsi.weststate.gov.nesw" is stored in column 504 of the fourth row.

At step S9-46, verification controller 12 disconnects the secure connection with store interface dsi.weststate.gov.nesw.

As noted above, the processing operations at steps S9-30 to S9-46 are performed in parallel for each of the four data store interfaces dsi.northstate.gov.nesw, dsi.eaststate.gov.nesw, dsi.southstate.gov.nesw and dsi.weststate.gov.nesw. When the processing for each of these data store interfaces is complete, processing proceeds to step S9-48, at which verification controller 12 determines whether the results from these four data store interfaces terminate further questioning by the verification controller 12. More particularly, referring to Figure 23, in this example verification controller 12 compares the results stored in column 506 in association with the question identifier Q ²³ with the termination condition stored in column 508 for this question identifier. In the present example, the result received from the data store interface dsi.eaststate.gov.nesw is "true", so that the termination condition (namely that all results should be "false") is not satisfied. Accordingly, verification controller 12 determines that the results do not terminate questioning and therefore processing proceeds to step S9-50.

At step S9-50, verification controller 12 checks the question identifiers stored in the question set selected steps S9-18 to determine whether at least one further question identifier remains. Referring again to Figure 13, at this stage in the processing, the question identifiers Q ¹⁶ , Q ^{! 9} , Q ⁷⁸ and Q ⁴³ remain, so processing returns to step S9-20.

At step S9-20, verification controller 12 identifies the data store interface 14 to which the next question identifier in the question set is to be transmitted. Referring to Figure 13, the next question identifier is Q ¹⁶ and the data store interface stored in association with this question identifier is dsi.[state].gov.nesw, where "[state]" is a variable to be determined. To determine the variable "[state]", verification controller 12 refers to the results stored in column 506 of results store 306 to identify the data store interface that returned a "true" result for question identifier Q . Thus, referring to Figure 23, verification controller 12 identifies the data store interface dsi.eaststate.gov.nesw as the data store interface 14 that transmitted a "true" result for question identifier Q ²³ . Accordingly, at step S9-20, verification controller 12 determines that the variable "[state]" is "East State" and that the data store interface 14 to which question identifier Q ¹⁶ should be transmitted is dsi.eaststate.gov.nesw.

At steps S9-22 and S9-24, verification controller 12 and the data store interface dsi.eaststate.gov.nesw establish a new secure connection. At step S9-26, verification controller 12 transmits to dsi.eaststate.gov.nesw the question identifier Q ¹⁶ , the identifier attributes types "Name" and "Address" (these being the relevant identifier attribute types stored in association with question identifier Q ¹⁶ in question set store 304 for this example, as shown in Figure 13) and the identifier attributes themselves that were received for the name and address identifier attribute types at step S9- 16, these being Jane Smith and 2 Eastway, Eastton, East State, EK20 ESW, as shown in Figure 12.

The data transmitted by verification controller 12 at step S9-26 is received by the data store interface dsi.eaststate.gov.nesw at step S9-28.

At step S9-30, dsi.eaststate.gov.nesw selects the instruction that is stored in instruction store 704 in association with the question identifier Q ^16' Thus, referring to Figure 15b, dsi.eaststate.gov.nesw selects the instruction SELECT IF(COUNT(*)>0,'1 ',Ό') as result FROM EAST STATE

WHERE Address Line 1 = "[Address Line 1]"

AND Address Line 2 = "[Address Line 2]"

AND Address Line 3 = "[Address Line 3]"

AND Postcode = "[POSTCODE]"

AND First Name = "[First Name]"

AND Middle Name = "[Middle Name]"

AND Surname = "[Surname]" In English, this instruction corresponds to the polar question "Is there a stored name at the supplied [Address] that matches the supplied [Name]?", where "[Address]" and "[Name]" are the identifier attributes for the address and name received at step S9-28. The purpose of this question is to determine whether the name given by the person at the polling station claiming to be entitled to vote is recorded at the address which has already been verified to be a valid address.

At step S9-32, dsi.eaststate.gov.nesw interrogates its operatively connected data store 4 using the instruction selected at step S9-30 in relation to the input address "2 Eastway, Eastton, East State, EK20 ESW" and the input name "Jane Smith".

At steps S9-34 and S9-36, the data store 4 receives and executes the instruction from dsi.eaststate.gov.nesw in relation to the transmitted identifier attribute types and identifier attributes, and transmits data indicating whether the question defined by the instruction is answered positively or negatively. Referring again to Figure 18, which shows the data stored in the data store 4 connected to dsi.eaststate.gov.nesw, it will be seen that the name Jane Smith is stored in association with the address 2 Eastway, Eastton, East State, EK20 ESW. Accordingly, the data store 4 transmits the result "true" which is received by the data store interface dsi.eaststate.gov.nesw at step S9-38 and then transmitted to verification controller 12 at step S9-40 in relation to the question identifier Q ¹⁶ .

At steps S9-42 and S9-44, verification controller 12 receives the "true" result and stores the result in results store 306 in association with the question identifier Q ¹⁶ and the data store interface dsi.eaststate.gov.nesw. This is schematically illustrated in the fifth row of the example results store shown in Figure 24.

At step S9-46, verification controller 12 disconnects the secure connection with dsi.eaststate.gov.nesw. At step S9-48, verification controller 12 determines whether the result received at step S9- 42 terminates questioning by comparing the result stored at step S9-44 with the termination condition in results store 306 for question identifier Q ¹⁶ . Referring to Figure 24, in this example, the result "true" does not match the termination condition "false" for question identifier Q ¹⁶ so verification controller 12 determines that the result does not terminate questioning. At step S9-50, verification controller 12 determines whether there is at least one question identifier in question set store 304 that remains to be transmitted. Referring to Figure 13, in the present example, question identifiers Q ^!9 , Q ⁷⁸ and Q ⁴³ remain to be transmitted. Accordingly, processing returns to step S9-20. At step S9-20, verification controller 12 identifies the data store interface 14 to which the next question identifier in the question set is to be transmitted. Referring to Figure 13, in this example, verification controller 12 identifies dsi.postoffice.gov.nesw as the data store interface 14 to which the question identifier Q ¹⁹ should be transmitted. At steps S9-22 and S9-24, verification controller 12 and dsi.postoffice.gov.nesw establish a secure connection for subsequent communication.

At step S9-26, verification controller 12 transmits to dsi.postoffice.gov.nesw the question identifier Q ¹⁹ ' the identifier attribute types "Name" and "Address" as well as the actual name and address identifier attributes received at step S9-16 (these being the ones shown in Figure 12, as described previously).

At steps S9-28, the data transmitted by verification controller 12 at step S9-26 is received by dsi.postoffice.gov.nesw.

At step S9-30, dsi.postoffice.gov.nesw selects the instruction that is stored in its instruction store 704 in association with the question identifier Q ¹⁹ . Figure 25 shows the data stored in the instruction store 704 of dsi.postoffice.gov.nesw in this example. Thus, at step S9-30, dsi.postoffice.gov.nesw selects the instruction

SELECT IF(COUNT(*)>0,'1*,O') as result FROM POST OFFICE

WHERE Address Line 1 = "[Address Line 1]" AND Address Line 2 = "[Address Line 2]"

AND Address Line 3 = "[Address Line 3]"

AND Postcode = "[POSTCODE]"

AND First Name = "[First Name]"

AND Middle Name = " [Middle Name] "

AND Surname = "[Surname]"

AND (Forwarding Address Line 1 IS NOT NULL OR Forwarding Address

Line 2 IS NOT NULL OR Forwarding Address Line 3 IS NOT NULL OR

Forwarding Postcode IS NOT NULL)

In English, this instruction corresponds to the polar question "Is there a forwarding address for the supplied [Name] at the supplied [Address]?", where "[Name]" and "[Address]" are the actual identifier attributes (which, in this example, are Jane Smith and 2 Eastway, Eastton, East State, EK20 ESW). The purpose of this question is to determine whether the person at the polling station claiming to be entitled to vote has instructed the Post Office to forward his/her mail to a new address, indicating that the person is no longer living at the old address and therefore indicating that the person has given an incorrect residence address to the official at the polling station. At step S9-32, dsi.postoffice.gov.nesw interrogates the data store 4 to which it is operatively connected with the instruction selected at step S9-30 in relation to the identifier attribute types and actual identifier attributes received at step S9-28.

At steps S9-34 and S9-36, the data store 4 receives the data transmitted at step S9-32, executes the instruction in relation to the received identifier attribute types and identifier attributes, and transmits data indicating whether the question defined by the instruction is answered positively or negatively.

Figures 26a and 26b show the data stored in data store 4 operatively connected to dsi.postoffice.gov.nesw in the present example. Referring to these figures, it will be seen that no forwarding address is stored for Jane Smith at 2 Eastway, Eastton, East State, EK20 ESW. Accordingly, at step S9-36, data store 4 transmits the result "false", which is received by dsi.postoffice.gov.nesw at step S9-38 and then transmitted to verification controller 12 at step S9-40 in relation to question identifier Q ¹⁹

At steps S9-42 and S9-44, verification controller 12 receives the result "false" and stores it in results store 306 in association with question identifier Q ¹⁹ and dsi.postoffice.gov.nesw, for example as schematically shown in Figure 27.

At step S9-46, verification controller 12 disconnects the secure connection with dsi.postoffice.gov.nesw.

At step S9-48, verification controller 12 determines whether the result received and stored at steps S9-42 and S9-44 terminates questioning by comparing the result with the termination condition stored in results store 306 in association with question identifier Q ¹⁹ . Referring to Figure 27, in this example, the result "false" does not match the termination condition "true" for question identifier Q ¹⁹ , so verification controller 12 determines at step S9-48 that questioning is to continue.

At step S9-50, verification controller 12 determines whether another question identifier in the current question set remains to be transmitted. Referring to Figure 13, in this example, question identifiers Q ⁷⁸ and Q ⁴³ remain to be transmitted, so processing returns to step S9- 20.

At step S9-20, verification controller 12 identifies the data store interface 14 to which the next question identifier should be transmitted. Referring again to Figure 13, the next question identifier to be transmitted is Q ⁷⁸ and the data store interface stored in association with this question identifier is dsi.birthsanddeaths.gov.nesw.

At steps S9-22 and S9-24, verification controller 12 and dsi.birthsanddeaths.gov.nesw establish a secure connection for subsequent communication.

At step S9-26, verification controller 12 transmits to dsi.birthsanddeaths.gov.nesw verification data comprising data defining question identifier Q 78 , the identifier attribute types stored in question set store 304 for question identifier 78 (that is, identifier attribute types "Name" and "Address") and the actual name and address identifier attributes received at step S9-16. At step S9-28, the verification data transmitted by verification controller 12 at step S9-26 is received by dsi.birthsanddeaths.gov.nesw.

At step S9-30, dsi.birthsanddeaths.gov.nesw selects the instruction that is stored in its instruction store 704 in association with question identifier Q ⁷⁸ . Figures 28a and 28b show the data stored in instruction store 704 of dsi.birthsanddeaths.gov.nesw in the present example. Accordingly, at step S9-30, dsi.birthsanddeaths.gov.nesw selects the instruction

SELECT IF(COUNT(*)>0,'170') as result FROM BIRTHS AND DEATHS

WHERE Address Line 1 = "[Address Line 1]"

AND Address Line 2 = "[Address Line 2]"

AND Address Line 3 = "[Address Line 3]"

AND Postcode = "[POSTCODE]"

AND First Name = "[First Name]"

AND Middle Name = "[Middle Name]"

AND Surname = "[Surname]"

AND Date Of Birth <= "(today's date minus 18 years)"

Within this instruction "today's date" is the date of operation. In this embodiment, dsi.birthsanddeaths.gov.nesw determines "today's date" by reading the date from an internal calendar (not shown) although it could be determined in other ways, for example by transmission to the data store interface by verification controller 12 or in subsequent processing by the data store 4 to which the instruction is transmitted. In English, this instruction corresponds to the polar question "Does the supplied [Name] at the supplied [Address] have a date of birth that is before or on today's date minus 18 years?". The purpose of this question is to determine if the person at the polling station claiming to be entitled to vote satisfies the requirement that they are of 18 years of age or older. At Step S9-32, verification controller 12 interrogates the data store 4 to which it is operatively connected using the instruction selected at step S9-30 in relation to the identifier attribute types and identifier attributes received at step S9-28. At steps S9-34 and S9-36, the data store 4 receives the instruction from dsi.birthsanddeaths.gov.nesw, executes the instruction in relation to the received identifier attribute types and identifier attributes, and transmits data indicating whether the question defined by the instruction is answered positively or negatively. Figures 29a and 29b show the data stored in data store 4 operatively connected to dsi.birthsanddeaths.gov.nesw in the present example. Referring to these figures, it will be seen that the date of birth for Jane Smith at 2 Eastway, Eastton, East State, EK20 ESW is 15.06.1993, which is before the present data minus 18 years. Accordingly, at step S9-36, the data store 4 transmits the result "true", which is received by the data store interface dsi.birthsanddeaths.gov.nesw at step S9-38 and then transmitted to verification controller 12 at step S9-40 in relation to question identifier Q .

At steps S9-42 and S9-44, verification controller 12 receives the "true" result and stores the result in results store 306 in association with the question identifier 78

Q and the data store interface dsi.birthsanddeaths.gov.nesw. This is schematically illustrated in the penultimate row of Figure 30.

At step S9-46, verification controller 12 disconnects the secure connection with dsi.birthsanddeaths.gov.nesw. At step S9-48, verification controller 12 determines whether the result received and stored at steps S9-42 and S9-44 terminates questioning by verification controller 12. More particularly, referring to Figure 30, in this embodiment, verification controller 12 compares the result stored in column 506 for question identifier Q ⁷⁸ with the termination condition stored in column 508 for question identifier Q . In the present example, the result "true" does not match the termination condition "false", so that verification controller 12 determines that questioning should be continued. At step S9-50, verification controller 12 determines whether there is a further question identifier in the current question set that remains to be transmitted. Referring to Figure 13, which shows the data stored in the question set for the present example, question identifier Q ⁴³ remains to be transmitted. Accordingly, processing returns to step S9-20.

At step S9-20, verification controller 12 determines the identity of the data store interface 14 to which the next question identifier in the question set is to be transmitted. Referring to Figure 13, in this example, the next question identifier is Q ⁴³ and the data store interface to which this question identifier is to be transmitted is dsi.birthsanddeaths.gov.nesw.

At steps S9-22 and S9-24, verification controller 12 and dsi.birthsanddeaths.gov.nesw establish a secure connection for subsequent communication.

At step S9-26, verification controller 12 transmits output verification data comprising data defining question identifier Q ⁴³ , the identifier attribute types "name" and "address" (these being the relevant identifier attribute types stored in question set 304 for question identifier Q ⁴³ ) and the actual name and address identifier attributes received at step S9-16.

At step S9-28, dsi.birthsanddeaths.gov.nesw receives the verification data transmitted by verification controller 12 at step S9-26.

At step S9-30, dsi.birthsanddeaths.gov.nesw selects the instruction that is stored in instruction store 704 in association with the received question identifier. Referring again to Figures 28a and 28b, in this example dsi.birthsanddeaths.gov.nesw therefore selects the instruction

SELECT IF(COUNT(*)>0,'1', ') as result FROM BIRTHS AND DEATHS

WHERE Address Line 1 = "[Address Line 1]"

AND Address Line 2 = "[Address Line 2]"

AND Address Line 3 = "[Address Line 3]"

AND Postcode = "[POSTCODE]"

AND First Name = "[First Name]" AND Middle Name = "[Middle Name]"

AND Surname = "[Surname]"

AND Date Of Death IS NOT NULL In English, this instruction defines the polar question "Is there a date of death recorded for the supplied [Name] at the supplied [Address]?". The purpose of this question is to determine whether the person at the polling station claiming to be entitled to vote has stolen the identity of a dead person in order to try to vote. At step S9-32, dsi.birthsanddeaths.gov.nesw interrogates the data store 4 to which it is operatively connected with the instruction selected at step S90-30 in relation to the identifier attribute types "Name" and "Address" and the actual identifier attributes for these identifier attribute types received at step S9-28, that is Jane Smith and 2 Eastway, Eastton, East State, EK20 ESW.

At steps S9-34 and S9-36, the data store 4 operatively connected to dsi.birthsanddeaths.gov.nesw receives the data transmitted at step S9-32, executes the received instruction in relation to the identifier attribute types and identifier attributes, and transmits a result indicating whether the question defined by the instruction is answered positively or negatively.

Figures 29a and 29b show the data stored in this example in the data store 4 that is operatively connected to dsi.birthsanddeaths.gov.nesw. As will be seen, a date of death of 28.07.2012 is stored for Jane Smith of 2 Eastway, Eastton, East State, E 20 ESW. Accordingly, at step S9-36, dsi.birthsanddeaths.gov.nesw transmits the result "true".

At steps S9-38 and S9-40, the "true" result is received by dsi.birthsanddeaths.gov.nesw and transmitted to verification controller 12 in relation to question identifier Q ⁴³ . At steps S9-42 and S9-44, verification controller 12 receives the "true" result and stores it in results store 306 in association with question identifier Q ⁴³ and data store interface dsi.birthsanddeaths.gov.nesw, as schematically illustrated in the final row of Figure 31. At step S9-46, verification controller 12 disconnects the secure connection with dsi.birthsanddeaths.gov.nesw.

At step S9-48, verification controller 12 compares the result stored at step S9-44 with the termination condition stored in results store 306 for question identifier Q ⁴³ , in order to determine whether the result terminates questioning. Referring to Figure 31, in this example, the "true" result matches the "true" termination condition stored in column 508 for question identifier Q ⁴³ . Consequently, verification controller 12 determines at step S9- 48 that questioning is terminated and processing proceeds to step S9-52.

At step S9-52, verification controller 12 evaluates the results stored in results store 306 to determine an overall result of the verification process. More particularly, referring to Figure 32, in this example, verification controller 12 firstly compares the results stored in column 506 with the termination conditions stored in column 508 and determines a respective result for each question identifier, comprising a "pass" if the result(s) stored in column 506 does not match the termination condition stored in column 508 or a "fail" if the result(s) stored in column 506 matches the termination condition stored in column 508. The respective results for the present example are shown in column 510 of Figure 32. Having determined a respective individual result for each question identifier, verification controller 12 then determines an overall result based upon the individual results. In the present example, the overall result is determined to be a "pass" if all of the individual results are a "pass". On the other hand, if one or more of the individual results is a "fail", then the overall result is determined to be a "fail". Accordingly, in the present example, verification controller 12 determines at step S9-52 that the overall result is a "fail". However, it should be noted that, in other examples, the overall result may still be a "pass" even if one or more of the individual results is a "fail".

Figure 32 shows the final form of the results store 306 in this illustrative example. It will be seen from Figure 32 that no data is stored from any data store 4. Instead, question identifiers are stored in column 502 instead of the actual questions themselves, and results are stored in column 506 indicating whether the (unstored) question corresponding to each question identifier is answered positively or negatively. In this way, verification is performed using data from multiple data stores 4 without aggregating any data, that is without creating any combination of data that did not previously exist in one of the data stores 4. At step S9-54 verification controller 12 checks the data stored in alert data store 308 for the current question set to determine if any alerts are to be issued. More particularly, in this embodiment, verification controller 12 checks the alert data stored in alert data store 308 for each question identifier having an individual result of "fail" in column 510 of results store 306 to determine if any alerts are to be output for that question identifier.

Figure 33 shows the data stored in alert data store 308 in the present example for the question set selected at step S9-18. As an individual "fail" result was recorded in column 510 of results store 306 for question identifier Q ⁴³ , verification controller 12 reads the data stored in alert data store 308 for Q ⁴³ to determine if any alerts are to be issued. Referring to Figure 33, one alert is stored for question identifier Q ⁴³ so that verification controller 12 determines at step S9-54 that an alert is to be issued and processing proceeds to step S9-56.

At step S9-56, verification controller 12 reads the data defining each respective alert message and alert output address that are stored for question identifier Q ⁴³ . Referring to Figure 33, Alert 1 in the present example has the purpose of informing the national police that an ineligible person is attempting to vote at the polling station. The reason the person is ineligible to vote is not stated in the alert message. This is because the alert is stored in association with a question identifier (Q ⁴³ ) and identifying in the alert that the person is ineligible to vote because [Name] at [Address] is deceased would enable a hacker who gained access to the data in verification controller 12 to determine the nature of the polar question corresponding to question identifier Q ⁴³ . It should be noted that no alerts are sent to the police when a "fail" is recorded in column 510 of results store 306 for any of the other question identifiers in this example, so that the police get an alert in this example only when the ineligibility is serious (in the present example, when a person attempting to vote by assuming the identity of a dead person) so that the police can take appropriate action, for example by attending the polling station and arresting the person. At step S9-58, verification controller 12 determines whether the current verification is to provide data defining one or more biometrics. In the present example, verification controller 12 determines that data defining a biometric is to be provided for the verification type "Entitlement to vote in an election in NESW" and so processing proceeds to step S9- 60.

At step S9-60, verification controller 12 identifies the data store interface 14 to which the identifier for the biometric retrieval command should be transmitted. Referring to Figure 13, in the present example, the identifier for the biometric retrieval command, "BRC", is stored in association with the data store interface dsi.birthsanddeaths.gov.nesw. Accordingly, at step S9-60, verification controller 12 identifies dsi.birthsanddeaths.gov.nesw as the data store interface 14 to which the identifier "BRC" should be transmitted. At steps S9-62 and S9-64, verification controller 12 and dsi.birthsanddeaths.gov.nesw establish a secure connection for subsequent communication.

At step S9-66, verification controller 12 transmits the identifier "BRC" as the identifier for the biometric retrieval command, as well as the identifier attribute types and identifier attributes received at step S9-16. This transmitted data is received by the data store interface dsi.birthsanddeaths.gov.nesw at step S9-68.

At step S9-70, dsi.birthsanddeaths.gov.nesw selects the instruction that is stored in instruction store 704 in association with the identifier "BRC". Thus, referring to Figures 28a and 28b, in this example, dsi.birthsanddeaths.gov.nesw selects the instruction

SELECT Biometric FROM BIRTHS AND DEATHS

WHERE Address Line 1 = "[Address Line 1]"

AND Address Line 2 = "[Address Line 2]"

AND Address Line 3 = "[Address Line 3]"

AND Postcode = "[POSTCODE]"

AND First Name = "[First Name]" AND Middle Name = "[Middle Name]"

AND Surname = "[Surname]"

This instruction instructs the data store 4 operatively connected to dsi.birthsanddeaths.gov.nesw to return the biometric that is stored for the supplied identifier attribute types and identifier attributes.

At step S9-72, dsi.birthsanddeaths.gov.nesw interrogates the connected data store 4 with the instruction selected at step S9-70 in relation to the identifier attribute types and identifier attributes received at step S9-68 (namely Jane Smith and 2 Eastway, Eastton, East State, EK20 ESW).

At steps S9-74 and S9-76, data store 4 receives the data transmitted at step S9-72, executes the instruction in relation to the received identifier attribute types and identifier attributes so as to retrieve the biometric, and transmits the biometric back to dsi.birthsanddeaths.gov.nesw. Referring to Figures 29a and 29b, in this example data store 4 stores a biometric for each person comprising image data defining an image of the person's face. Accordingly, at step S9-76, dsi.birthsanddeaths.gov.nesw transmits the stored image data for Jane Smith of 2 Eastway, Eastton, East State, EK20 ESW.

At steps S9-78 and S9-80 dsi.birthsanddeaths.gov.nesw receives the biometric from data store 4 and transmits it to verification controller 12.

At Steps S9-82 and S9-84, verification controller 12 receives the biometric and disconnects the secure connection with dsi.birthsanddeaths.gov.nesw.

At step S9-88, verification controller 12 determines whether a response is to be transmitted to both the user equipment 8 that initiated the verification request and also at least one other output destination. In the present example, no output destination other than the user equipment 8 was defined in the data received by verification controller 12 at step S9-16. Accordingly, in this example, verification controller 12 determines that the question at step S9-88 is answered negatively, so that processing proceeds to step S9-104. At step S9-104, verification controller 12 determines whether a response is to be transmitted only to the user equipment 8 that initiated the verification request. In this example, only the user equipment 8 was specified as an output destination in the data received at step S9-16. Accordingly, in this example, verification controller 12 determines that a response is to be transmitted only to the user equipment 8 that initiated the verification request, and so processing proceeds to step S9-106.

At step S9-106, verification controller 12 transmits to user equipment 8 a response comprising the overall result "fail" determined at step S9-52, and the biometric retrieved at step S9-82 (comprising image data in the present example defining an image of the face of Jane Smith of 2 Eastway, Eastton, East State, EK20 ESW).

At step S9-108, verification controller 12 determines from the alert output addresses determined at step S9-56 whether one or more alerts need to be transmitted to alert output addresses other than the user equipment 8 to which an alert was transmitted at step S9-106. Referring to Figure 33, in the present example, Alert 1 for question identifier Q ⁴³ needs to be transmitted to fraud.police.gov.nesw. Accordingly, processing proceeds to step S9-110, at which a secure connection is established between verification controller 12 and the user equipment at alert output address fraud.police.gov.nesw.

At step S9-112, verification controller 12 transmits data defining the alert message to the alert output address. In the present example, therefore, verification controller 12 transmits data defining the alert message "Polling Station for Eastton has ineligible person attempting to vote" to fraud.police.gov.nesw.

At step S9-114, verification controller 12 deletes the results stored in columns 504, 506 and 510 of results store 306.

Referring to Figure 91, at step S9-138, user equipment 8 that initiated the verification request receives the response transmitted by verification controller 12 at step S9-106. As noted above, this response comprises the overall result "fail" and image data defining an image of the face of Jane Smith of Eastway, Eastton, East State, EK20 ESW. At step S9-140, user equipment 8 disconnects the secure connection with verification controller 12 previously established at step S9-10 and S9-12.

At step S9-142, user equipment 8 presents to the user on a display an output message showing the overall result and the image defined by the image data received at step S9- 138. In the present example, the user is the official at the polling station, who can then see that the displayed image does not match the face of the lady at the polling station claiming to be entitled to vote and can read overall result "fail". The output of a biometric, such as an image showing the face of the person being verified, is useful in scenarios other than that illustrated by the present example. For example, assume that the lady attempting to vote in the example had not taken the identity of a dead person but, instead, had falsely taken the identity of a living person. In that case, the check performed using question identifier Q ⁴³ would return a "false" result because there would be no date of death stored for the living person. Consequently, all tests would be passed but the lady's deception would still be detected because the official at the polling station would see displayed an image of the face of the real person whose identity had been stolen and would see that the face did not match the face of the lady at the polling station. On the other hand, a person genuinely entitled to vote and giving his/her correct name and address would be allowed to vote because the official at the polling station would be able to see that the face displayed matched that of the person attempting to vote.

Referring now to Figure 9n, at step S9-152 the user equipment at fraud. police.gov.nesw establishes a secure connection with verification controller 12 in response to the processing at step S9- 110.

At step S9-154, the user equipment at fraud.police.gov.nesw receives the alert message "Polling station for Eastton has ineligible person attempting to vote". At step S9-156, the user equipment at fraud.police.gov.nesw disconnects its secure connection with verification controller 12. At step S9-158, the user equipment at fraud.police.gov.nesw outputs the received alert, for example by displaying it on a display.

From the above description, it will be understood that the verification controller 12 and data store interfaces 14 provide a number of advantages. Firstly, the verification controller 12 and data store interfaces 14 enable verification to be carried out using data stored in multiple data stores 4 without aggregating the data (that is, without creating a combination of data that did not previously exist in one of the data stores). This advantage can be achieved even when data defining a biometric stored in a data store 4 is returned to verification controller 12 because no data from any other data store 4 is held by verification controller 21 (instead data indicating whether a question is answered positively or negatively is held) and the combination of the data defining the biometric along with the input identifier attributes was previously stored in the data store 4 from which the data defining the biometric was obtained. As a result, no data aggregation takes place when verification is performed by the verification controller 12 and data store interfaces 14 using data from more than one data store 4. A further advantage is that the data stored for an entity in verification controller 12 during a verification process is of little use to anyone gaining unauthorised access to the stored data. This is because the data that is stored comprises question identifiers (rather than the actual questions themselves) and a result for each question identifier indicating whether the corresponding (unstored) question is answered positively or negatively, such as a "true" or "false" result. Accordingly, anyone gaining unauthorised access to this data cannot determine the meaning of the questions for which the "true" and "false" results are stored. Furthermore, as mentioned previously, a problem can arise because of data ownership in a case in which data stored in a plurality of different data stores need to be interrogated to verify an entity. In this case, if the different data stores are owned by different owners, the owners may not be prepared to allow access to their data store by a verification device because the verification device could read or copy the data from one data store and then compile its own data store or provide the data to the owner of a different data store. The verification controller 12 and the data store interfaces 14 of the present embodiment address this problem because each executable command that is used to interrogate a data store 4 is stored in a data store interface 14 for that data store 4. Thus, each data store interface 14 could be provided by the owner of the data store 4, thereby giving the owner complete control over the executable instructions that can be used to interrogate the data in its data store. Because each data store interface 14 provides verification controller 12 with a result for each question identifier indicating whether the corresponding question is answered positively or negatively, rather than returning data stored in a data store to verification controller 12, each data store owner would know that the data in its data store cannot be read or copied.

[Embodiment 2] A second embodiment of the present invention will now be described.

In the second embodiment, the user equipments 8, verification controller 12 and data stores 4 have the same structure as, and perform the same processing operations as, the user equipments 8, verification controller 12 and data stores 4, respectively, in the first embodiment. However, the data store interfaces 14 in the second embodiment are different from, and perform different processing operations from, the data store interfaces 14 in the first embodiment.

More particularly, in the first embodiment, each executable instruction that is stored in association with a question identifier in the instruction store 704 of a data store interface 14 comprises an instruction to interrogate a data store 4 to cause the data store to return data defining whether a polar question is answered positively or negatively. As will be explained in more detail below, in the second embodiment, each instruction that is stored in association with a question identifier in the instruction store of a data store interface comprises first and second respective instructions, each respective instruction being a separate executable instruction. The first instruction is for interrogating a data store 4 to cause the data store to return to the data store interface, data of one or more specified identifier attribute types that is stored in association with one or more of the identifier attributes received from verification controller 12. The second instruction is executable by the data store interface 14 itself to process the data returned from a data store 4 in response to the first instruction, so as to determine by the processing whether a polar question is answered positively or negatively. The answer determined by the data store interface 14 is then returned to verification controller 12 in relation to the corresponding question identifier. In this way, data is returned from a data store 4 to a data store interface 14, but no data from a data store 4 is provided to verification controller 12. Consequently, in the same way as the first embodiment, verification of an entity can be performed using data in multiple data stores 4 without aggregating data from different data stores. This is possible because the data that is returned from a data store 4 to the connected data store interface 14 already exists in the data store 4, and no data is returned from a data store interface 14 to verification controller 12 (instead data indicating whether a question is answered positively or negatively is returned).

The differences between the data store interfaces 14 of the second embodiment and the first embodiment will be described in further detail below.

Figures 34a and 34b show an example of data stored in the instruction store 2704 of a data store interface 14 in the second embodiment. For illustrative purposes, the example is based upon the data shown in Figure 15a that was stored in the instruction store 704 of the data store interface dsi.northstate.gov.nesw in the simplified example of the first embodiment. Referring to Figures 34a and 34b, the question identifiers Q and Q are stored in the instruction store 2704, as in the first embodiment. However, the instruction that is stored in association with each question identifier is different in the second embodiment. More particularly, as described above, each stored instruction comprises a first instruction for interrogating a data store 4 to cause the data store 4 to return data to the data store interface 14, and a second instruction to cause the data store interface 14 to process the data received from the data store 4 so as to determine a result such as "true" or "false" as the answer to the polar question defined by the associated question identifier. The use of these instructions will be explained further in the following description of the processing operations performed in the second embodiment.

In the second embodiment, the processing operations at steps S9-2 to S9-30 and steps S9- 40 to S9-158 are the same as those in the first embodiment and accordingly will not be described again here. However, the processing operations performed at steps S9-32 to S9- 38 in the first embodiment are replaced in the second embodiment by the processing operations performed at steps S35-2 to S35-10 shown in Figure 35 (in which preceding steps S9-28 and S9-30 and following step S9-40 are also shown for ease of reference).

Referring to Figure 35, after a data store interface 14 has received input verification data at step S9-28 comprising data defining a question identifier, one or more identifier attribute types and one or more identifier attributes, and has selected at step S9-30 the instruction stored in instruction store 2704 in association with the received question identifier, processing proceeds in the second embodiment to step S35-2, at which the data store interface 14 interrogates an operatively connected data store 4 using the selected instruction. More particularly, in the second embodiment, data store interface 14 interrogates the operatively connected data store 4 with the first instruction selected at step S9-30 so as to instruct the data store 4 to return attribute data of one or more specified attribute types that is stored in the data store in association with one or more of the identifier attributes received at step S9-28.

At step S35-4, the operatively connected data store 4 receives and executes the instruction and, at step S35-6, transmits the requested data back to the data store interface 14.

At step S35-8, data store interface 14 receives the data from the data store 4 and at step S35-10 processes the data by executing the second instruction selected at step S9-30 to determine a result, such as "true" or "false", indicating whether the bipolar question defined by the question identifier received at step S9-28 is answered positively or negatively.

It should be noted that a data store 4 may not contain any data specified by the first instruction used by the data store interface 14 in the interrogation at step S35-2. In such a case, the data store 4 returns a "null" result. To ensure that "null" results are correctly processed, the second instruction stored in instruction store 2704 is configured to classify a "null" result as either a "true" result or a "false" result depending upon the polar question of the corresponding question identifier. For example, referring back to the simplified example given in the first embodiment, the polar question corresponding to the question identifier Q ¹⁹ is "Is there a forwarding address for the supplied [Name] at the supplied [Address] ?" In the second embodiment, the first instruction stored in instruction store 2704 for question identifier Q ¹⁹ would be configured to instruct a data store 4 to return any forwarding address data that is stored in association with the supplied [Name] and the supplied [Address]. If no such forwarding address data was stored by data store 4, then it would return a "null" result. The second instruction stored for question identifier Q ¹⁹ would be configured to classify the "null" result as a "false" result so that the biopolar question is answered correctly. On the other hand, if the biopolar question for question identifier Q ¹⁹ was "Does the supplied [Name] still reside at the supplied [Address] ?" then the first instruction stored for Q ¹⁹ could still be configured to instruct a data store 4 to return any forwarding address data that is stored in association with the supplied [Name] and the supplied [Address] but the second instruction for Q ¹⁹ would be configured to classify a "null" result as a "true" result.

As a data store interface 14 in the second embodiment receives and processes data from a data store 4 at steps S35-8 and S35-10, the data store interface may be configured to process the data in a way which takes account of spelling differences and formatting differences between the identifier attribute(s) received from verification controller 12 and the attributes received from a data store 4. For example, a data store interface 14 may be configured to perform processing at steps S35-10 such as fuzzy matching to determine if an address "2 East Way, Eastton, East State E 20ESW" from a data store 4 matches the address identifier attribute "2 Eastway, Eastton, East State, EK20 ESW", from verification controller 12. By configuring a data store interface 14 in this way, the accuracy of the results determined by the data store interface 14 at step S35- 10 is increased.

Referring again to Figure 35, after step S35-10, processing proceeds to step S9-40, at which data store interface 14 transmits the result determined at step S35- 10 to verification controller 12.

From the above description it will be understood that the computer processing apparatus 200 of each data store interface 14 in the second embodiment is configured to provide the data stores and functional processing units shown in Figure 36, comprising connection controller 2102, input verification data receiver 2104, input verification data store 2702, instruction selector 2106, instruction store 2704, data store interrogator 2108, interrogation response receiver 2110, response processor 21 14 and result transmitter 2112.

Connection controller 2102 is the same as connection controller 1 102 in the first embodiment and is arranged to perform the processing operations at steps S9-24 and S9- 64. Input verification data receiver 2104 is the same as input verification data receiver 1 104 in the first embodiment and is arranged to perform the processing operations at steps S9-28 and S9-68.

Input verification data store 2702 is the same as input verification data store 702 in the first embodiment and is configured to store the input verification data received at step S9-28.

Instruction selector 2106 is the same as instruction selector 1106 in the first embodiment and is arranged to perform the processing operations at steps S9-30 and S9-70. Instruction store 2704 is configured to store question identifiers and instructions as described above, and may be configured in the case of one or more data store interfaces 14 to store a biometric retrieval command in association with an identifier for the biometric retrieval command, as described in the first embodiment. Data store interrogator 2108 is arranged to perform the processing operations at step S35-2 and, if a biometric retrieval command is stored in the data store interface, step S9-72.

Interrogation response receiver 2110 is arranged to perform the processing operations at step S35-8 and, if a biometric retrieval command is stored in the data store interface, step S9-78.

Response processor 2114 is arranged to perform the processing operations at step S35-10. Result transmitter 2112 is the same as result transmitter 11 12 in the first embodiment and is arranged to perform the processing operations at steps S9-40 and S9-80. To further illustrate the processing operations performed by a data store interface 14 in the second embodiment, the processing operations at steps S35-2 to S35-10 will be described for two of the data store interfaces 14 in the simplified example described in the first embodiment in which a lady visits a polling station to vote in an election in the country "NESW" and states that her name is Jane Smith and that she lives at 2 Eastway, Eastton, East State, EK20 ESW.

Firstly, the processing operations performed at steps S35-2 to S35- 10 will be described for the data store interface dsi.northstate.gov.nesw. In this example, the instruction store 2704 of the data store interface dsi.northstate.gov.nesw stores the data shown in Figures 34a and 34b.

Accordingly, upon receipt of the question identifier Q , the identifier attribute type "Address" and the identifier attribute "2 Eastway, Eastton, East State, EK20 ESW" at step S9-28, dsi.northstate.gov.nesw selects at step S9-30 the instructions

SELECT Address Line 1, Address Line 2, Address Line 3, Postcode FROM

NORTH STATE

WHERE Postcode = "[POSTCODE]" foreach ($results as $result) {

if ($result[' Address Line Γ] == $identifierAttributes['Address Line Γ] &&

$result['Address Line 2'] == $identifierAttributes['Address Line 2'] &&

$result['Address Line 3'] = $identifierAttributes['Address Line 3'] &&

$result['Postcode'] == $identifierAttributes['POSTCODE']) {

return 1 ; }

} return 0;

In English, the first instruction corresponds to the instruction "Return the address data for any address having a postcode that matches the supplied [POSTCODE] where [POSTCODE] is the postcode in the address received at step S9-28. At step S35-2, dsi.northstate.gov.nesw interrogates the operatively connected data store 4 with the first instruction selected at step S9-30, namely

SELECT Address Line 1 , Address Line 2, Address Line 3, Postcode FROM

NORTH STATE WHERE Postcode = "[POSTCODE]" so as to instruct the data store to return the requested data.

At steps S35-4 and S35-6, the data store 4 that is operatively connected to dsi.northstate.gov.nesw receives and executes the instruction and transmits data back to dsi.northstate.gov.nesw. In the present example, the data that is stored in the data store 4 is shown in Figure 16. As will be seen from this figure, no address has the postcode "EK20 ESW". Accordingly, at step S35-6, the data store 4 transmits data defining a "null" response, which is received by dsi.northstate.gov.nesw at step S35-8.

At Step S35- 10, dsi.northstate.gov.nesw processes the received data to determine a result "true" or "false" in relation to the question associated with question identifier Q ²³ , namely the question "Is there a stored address that matches the supplied [Address] ?" where "[Address]" is the address received at step S9-28.

In this embodiment, dsi.northstate.gov.nesw performs the determination at step S35-10 by executing the second instruction selected at step S9-30, namely foreach ($results as Sresult) {

if ($result['Address Line Γ] == $identifierAttributes['Address Line Γ] &&

$result[ ^* Address Line 2'] == $identifierAttributes[Address Line 2'] &&

$result['Address Line 3'] = $identifierAttributes[' Address Line 3'] &&

$result[ ostcode'] == $identifierAttributes[TOSTCODE']) {

return 1 ;

}

} return 0;

In English, the second instruction, when executed, determines whether any of the addresses returned by the data store 4 match the input "Address" received at step S9-28, with the result being set to "false" if a "null" result is returned by the data store 4. In this way, the second instruction is written in dependence upon the polar question to be answered so as to set the result to "true" or "false" as required by the question when a "null" result is received back from a data store. In the example of Figures 34a and 34b, the second instruction is written in php, although other languages can be used instead.

Accordingly, at step S9-40, dsi.northstate.gov.nesw transmits the result "false" back to verification controller 12 for the question identifier Q 23.

Turning to the data store interface dsi.eaststate.gov.nesw, the instruction store 2704 in dsi.eaststate.gov.nesw stores the data shown in Figures 34c and 34d. The data stored in the data store 4 operatively connected to dsi.eaststate.gov.nesw is shown in Figure 18.

When the question identifier Q , the identifier attribute type "Address" and the identifier attribute "2 Eastway, Eastton, East State, EK20 ESW" are received by dsi.eaststate.gov.nesw at step S9-28, processing proceeds to step S9-30, at which dsi.eaststate.gov.nesw selects the instructions stored in instruction store 2704 in association with the question identifier Q , that is SELECT Address Line 1 , Address Line 2, Address Line 3, Postcode FROM EAST STATE

WHERE Postcode = "[POSTCODE]" foreach ($results as $result) {

if ($result[ ddress Line 1 '] == $identifierAttributes[ ddress Line V] &&

$result['Address Line 2'] == $identifierAttributes[Address Line 2'] &&

$result['Address Line 3'] == $identifierAttributes[Address Line 3'] &&

$result['Postcode'] = $identifierAttributes['POSTCODE']) {

return 1 ;

}

} return 0;

In this example, there are is the same instructions as those selected by dsi.northstate.gov.nesw at step S9-30 described above (except that the first instruction is configured for the data store EAST STATE rather than NORTH STATE). However, because the data stored in data store owned and operated by the local government of East State is different, when the data store interface dsi.eaststate.gov.nesw interrogates the operatively connected East State data store using the first instruction at step S35-2, the data store returns the addresses "2 Eastway, Eastton, East State, EK20 ESW", "2 Eastway, Eastton, East State, EK20 ESW" and "3 Eastway, Eastton, East State, EK20 ESW" to dsi.eaststate.gov.nesw because each of these addresses is stored in the data store and each of the addresses has a postcode that matches the postcode "EK20 ESW" of the "Address" received at step S9-28. (The address "2 Eastway, Eastton, East State, EK20 ESW" is returned twice in this example because it is stored twice in the data store 4 that is owned and operated by the local government of East State, as shown in Figure 18).

Accordingly, when these addresses are processed at step S35-10 by dsi.eaststate.gov.nesw using the second instruction selected at step S9-30, the result "true" is obtained because two of the addresses match the identifier attributable "Address" received at step S9-28. dsi.eaststate.gov.nesw therefore transits the result "true" to verification controller 12 at step S9-40 for question identifier Q ²³ . In the subsequent round of questioning, when input verification data is received at step S9- 28 by dsi.eaststate.gov.nesw comprising question identifier Q ¹⁶ , identifier attribute types "Name" and "Address", and identifier attributes "Jane Smith" and "2 Eastway, Eastton, East State, EK20 ESW", processing proceeds to step S9-30, at which dsi.eaststate.gov.nesw selects from instruction store 2704 the instructions

SELECT First Name, Middle Name, Surname, FROM EAST STATE

WHERE Address Line 1 = "[Address Line 1]"

AND Address Line 2 = "[Address Line 2]"

AND Address Line 3 = "[Address Line 3]"

AND Postcode = "[POSTCODE]" foreach ($results as $result) {

if ($result['First Name'] == $identifierAttributes['First Name'] &&

$result['Middle Name'] == $identifierAttributes['Middle Name'] &&

$result['Surname'] == $identifierAttributes['Surname']) {

return 1;

}

} return 0;

In English, the first instruction corresponds to the command "Return any name data stored in association with the supplied [Address]", where "[Address]" is "2 Eastway, Eastton, East State, EK20 ESW" in this example.

Accordingly, referring again to Figure 18, the subsequent processing at steps S35-2 to S35- 8 results in the operatively connected data store 4 returning the name data "Jane Smith" and "James Thomas Smith" to dsi.eaststate.gov.nesw as both of these names are stored in association with the address "2 Eastway, Eastton, East State, EK20 ES W".

At step S35-10, dsi.eaststate.gov.nesw processes the received names using the second instruction selected at step S9-30, namely foreach ($results as $result) {

if ($result['First Name'] == $identifierAttributes['First Name'] &&

$result['Middle Name*] = $identifierAttributes[*Middle Name'] &&

$result['Surname']— $identifierAttributes['Surname']) {

return 1 ;

}

} return 0;

In English, this second part of the instruction determines if there is a name at the supplied address that matches the supplied name, with the result being set to "fail" in the event that a "null" result is returned by the data store 4. In the present example, therefore, dsi.eaststate.gov.nesw determines the result "true" at step S35-10 because one of the received names matches the input name "Jane Smith", dsi.eaststate.gov.nesw therefore transmits the result "true" to verification controller 12 at step S9-40 for question identifier Q ¹⁶ . From the above description, it will be understood that the verification controller 12 and data store interfaces 14 of the second embodiment provide the same advantages as in the first embodiment. In particular, verification of an entity can be performed using data from a plurality of different data stores 4 without aggregating data. This is the case even though data is returned from the data stores 4 to the data store interfaces 14. In addition, the return of data from the data stores 4 to the data store interfaces 14 does not cause a problem with data ownership in a situation in which a data store interface 14 is owned by the same owner as the operatively connected data store 4, because all data within the data store will then remain under the control of that owner. Furthermore, each data store interface 14 of the second embodiment provides the additional advantage that the data returned by a data store 4 can be processed by the data store interface 14 at step S35-10 to determine an accurate result even taking account of spelling differences and formatting differences between the identifier attribute(s) received at step S9-28 and the data stored in the data store 4.

[Modifications] Many modifications can be made to the embodiments described above. [First Modification]

In the first and second embodiments, a data store interface 14 may be operatively connected to more than one data store 4, as shown in Figure 1. However, in the first and second embodiments described above, each data store interface 14 interrogates only one data store 4 in the processing at step S9-32 or step S35-2 even if the data store interface 14 is connected to more than one data store 4. Accordingly, in those embodiments, all data needed to determine an answer to a polar question corresponding to a question identifier is stored in the single data store that is interrogated. A first modification will now be described that permits a data store interface 14 that is connected to more than one data store 4 to make use of the data stored in two of the data stores to obtain a result for a single polar question corresponding to a question identifier, without aggregating data. In the first modification, the user equipments 8, verification controller 12 and data stores 4 have the same structure as, and perform the same processing operations as, the user equipments 8, verification controller 12 and data stores 4, respectively, in the first and second embodiments. However, in the first modification, a data store interface 14 that is operatively connected to a plurality of data stores 4 is different from, and performs different processing operations from, the data store interfaces 14 in the first and second embodiments. More particularly, as will be explained in more detail below, a data store interface 14 that is operatively connected to more than one data store 4 is configured to interrogate a first of the connected data stores using one or more identifier attributes received from verification controller 12 to cause the first data store to return data stored in the first data store, and to interrogate a second of the connected data stores using the data obtained from the first data store as one or more identifier attributes to obtain from the second data store an answer to a polar question indicating whether the question is answered positively or negatively (the polar question corresponding to the question identifier received from verification controller 12).

In more detail, each instruction that is stored in association with a question identifier in the instruction store of the data store interface 14 in the first modification comprises first and second respective instructions, each respective instruction being configured for the interrogation of a different operatively connected data store 4, and each instruction being a separate executable instruction. The first instruction is configured for interrogating a first data store 4 to cause the first data store to return to the data store interface 14 data of one or more specified attribute types that are stored in the first data store 4 in association with one or more of the identifier attributes received from verification controller 12. The second instruction is configured to interrogate the second data store using the identifier attribute(s) obtained from the first data store to obtain from the second data store an answer to a polar question corresponding to the question identifier received from verification controller 12 indicating whether the question is answered positively or negatively. In this way, no data aggregation occurs in the data store interface 14. More particularly, although the first data store 4 returns the stored data for one or more attributes, and data store interface 14 holds this data together with the input identifier attributes received from verification controller 12, this combination of data already existed in the first data store 4, so there is no data aggregation because no new combination of data has been created. When the second data store is interrogated, this data store returns data indicating whether a polar question is answered positively or negatively, so no new combination of data is created in the data store interface 14. Consequently, data store interface 14 is configured to obtain an answer to a single polar question using data stored in two different data stores 4 without aggregating the data. The first modification will now be described in further detail.

Figures 37a, 37b and 37c show an example of data stored in the instruction store 3704 of a data store interface 14 in the first modification. For illustrative purposes, the example is based upon the data shown in Figures 28a and 28b that was stored in the instruction store 704 of the data store interface dsi.birthsanddeaths.gov.nesw in the simplified example of the first embodiment. Referring to Figures 37a, 37b and 37c, the question identifiers Q ⁷⁸ and Q ⁴³ are stored in the instruction store 3704, as in the first embodiment. However, the instruction that is stored in association with each question identifier is different in the first modification. More particularly, each stored instruction comprises a first instruction and a second instruction, each being an executable instruction in its own right. The first instruction is configured for interrogating a first operatively connected data store using one or more question identifiers received from verification controller 12 to cause the first data store 4 to return data to the data store interface 14. The second instruction is configured to cause the data store interface 14 to interrogate a second of the operatively connected data stores using the data obtained from the first data store as one or more identifier attributes to obtain from the second data store an answer to the polar question corresponding to the question identifier received from verification controller 12 indicating whether the question is answered positively or negatively. Furthermore, for each instruction, data is stored defining the data store 4 to be interrogated with the instruction (this data being illustrated in column 3710 in Figures 37a, 37b and 37c). The use of these instructions will be explained further in the following description of the processing operations performed in the first modification.

In the first modification, the processing operations at steps S9-2 to S9-30 and steps S9-40 to S9-158 are the same as those in the first embodiment and accordingly will not be described again here. However, the processing operations performed at steps S9-32 to S9- 38 in the first embodiment are replaced in the first modification by the processing operations performed at steps S38-2 to S38-40 shown in Figures 38a, 38b and 38c (in which steps S9-28, S9-30 and S9-40 from the first embodiment are shown for ease of reference).

Referring to Figure 38 a, after a data store interface 14 has received input verification data at step S9-28 comprising data defining a question identifier, one or more identifier attribute types and one or more identifier attributes, and has selected at step S9-30 the instruction stored in instruction store 3704 in association with the received question identifier, processing proceeds in the first modification to step S38-2, at which data store interface 14 determines whether the selected instruction requires information from more than one data store 4. This check is made because, in some cases, a question identifier from verification controller 12 may require data from only one operatively connected data store to be used to determine an answer to the corresponding polar question indicating whether the question is answered positively or negatively (as in the first embodiment). The determination at step S38-2 can be made, for example, by data store interface 14 determining whether the selected instruction comprises instructions for more than one data store (it being noted above that an instruction for the interrogation of two data stores contains respective instructions for each data store).

If it is determined at step S38-2 that the selected instruction does not require information from more than one data store, then processing proceeds to step S38-4, at which data store interface 14 determines the data store 4 that is to be interrogated with the selected instruction (this determination being performed in this example by reading the identity of the data store 4 from the data stored in column 3710 of the instruction store 3704). The processing then proceeds to step S38-6 at which data store interface 14 interrogates the identified data store with the selected instruction. The processing performed at steps 38-6 to S38- 12 and subsequently at step S9-40 is the same as that performed in the first embodiment at steps S9-32 to S9-38 and S9-40, respectively. Accordingly, this processing will not be described again here. On the other hand, if it is determined at step S38-2 that the selected instruction does require information from more than one data store, then processing proceeds to step S38- 14. At step S38- 14, data store interface 14 determines the first data store 4 that is to be interrogated with the first instruction of the selected instruction (this determination being performed in this example by reading the identity of the data store 4 from the data stored in association with the first instruction of the selected instruction in column 3710 of the instruction store 3704).

At step S38- 16, data store interface 14 interrogates the first data store 4 identified at step S38-14 using the first instruction selected at step S9-30 so as to instruct the first data store 4 to return attribute data of one or more specified attribute types that is stored in the first data store 4 in association with one or more of the identifier attributes received from verification controller 12 at step S9-28. Each attribute defined by the attribute data that data store interface 14 requests the first data store 4 to return is referred to as a bridging identifier attribute because the attribute is to be used by data store interface 14 as an identifier attribute for the interrogation of a second data store 4, so that the attribute acts as a "bridge" between the first data store 4 and the second data store 4.

At step S38- 18, the first data store 4 receives and executes the instruction and, at step S38- 20, transmits a response back to the data store interface 14. At step S38-22, data store interface 14 receives the response from the first data store 4 and, at step 38-24, checks whether the response is data defining one or more bridging identifier attributes, as requested, or whether the response is a "null" result that has been transmitted by the first data store 4 because it does not contain the requested attribute data. If it is determined at step S38-24 that the response is a "null" result, then processing proceeds to step S38-26, at which data store interface 14 sets the "null" result to be either a "true" or "false" result depending upon the polar question corresponding to the question identifier received from verification controller 12 (in a similar way that a "null" result was set to be a "true" result or a "false" result in the second embodiment described above at step S35-10). Following the setting of the "null" result to either "true" or "false", processing proceeds to step 38-28, at which data store interface 14 transmits the "true" or "false" result to verification controller 12 in relation to the corresponding question identifier. Subsequently, processing proceeds to step S9-42, which has already been described in the first embodiment.

On the other hand, if it is determined at step S38-24 that the response from the first data store 4 comprises attribute data defining the requested bridging identifier attribute(s), then processing proceeds to step 38-30, at which data store interface 14 determines the data store 4 that is to be interrogated with the second instruction (this determination being performed in this example by reading the identity of the data store 4 from the data stored in association with the second instruction in column 3710 of the instruction store 3704).

At step S38-32, data store interface 14 interrogates the identified second data store 4 using the second instruction selected at step S9-30 and the bridging identifier attribute(s) received at step S38-22 from the first data store 4 in the preceding interrogation, so as to instruct the second data store 4 to return a result "true" or "false".

At step 38-34, the final data store 4 receives and executes the instruction and, at step S38- 36, transmits a reply "true" or "false".

At step S38-38, data store interface 14 receives the "true" or "false" reply, and at step S38- 40 transmits a result "true" or "false" to verification controller 12 in relation to the corresponding question identifier.

Subsequently, processing proceeds to step S9-42, which has already been described in the first embodiment.

From the above description it will be understood that the computer processing apparatus 200 of the data store interface 14 in the first modification is configured to provide the data stores and functional processing units shown in Figure 39, comprising connection controller 3102, input verification data receiver 3104, input verification data store 3702, instruction selector 3106, instruction store 3704, instruction analyser 3114, data store interrogator 3108, interrogation response receiver 3110, interrogation response analyser 3116 and result transmitter 3112. Connection controller 3102 is the same as connection controller 1 102 in the first embodiment and is arranged to perform the processing operations at steps S9-24 and S9- 64. Input verification data receiver 3104 is the same as input verification data receiver 1104 in the first embodiment and is arranged to perform the processing operations at steps S9-28 and S9-68.

Input verification data store 3702 is the same as input verification data store 702 in the first embodiment and is configured to store the input verification data received at step S9-28.

Instruction selector 3106 is the same as instruction selector 1106 in the first embodiment and is arranged to perform the processing operations at steps S9-30 and S9-70. Instruction store 3704 is configured to store question identifiers and instructions as described above, and may be configured to store a biometric retrieval command in association with an identifier for the biometric retrieval command, as described in the first embodiment. Instruction analyser 3114 is arranged to perform the processing operations at steps S38-2, S38-4, S38-14 and S38-30.

Data store interrogator 3108 is arranged to perform the processing operations at steps S38- 6, S38- 16 and S38-32 and, if a biometric retrieval command is stored in the data store interface, step S9-72.

Interrogation response receiver 3110 is arranged to perform the processing operations at steps S38-12, S38-22 and S38-38, and also, if a biometric retrieval command is stored in the data store interface, step S9-78.

Interrogation response analyser 3116 is arranged to perform the processing operations at steps S38-24 and S38-26. Result transmitter 31 12 is the same as result transmitter 1112 in the first embodiment and is arranged to perform the processing operations at steps S9-40, S38-28, S38-40 and S9-80. To further illustrate the processing operations performed by a data store interface 14 in the first modification, the processing operations at steps S38-2 to S38-40 will be described for the question identifier Q ⁷⁸ in the simplified example described for the first embodiment, in which a lady visits a polling station to vote in an election in the country "NESW" and states that her name is Jane Smith and that she lives at 2 Eastway, Eastton, East State, EK20 ESW. To illustrate this processing, assume that the data shown in Figures 29a and 29b that is stored in a single data store 4 in the simplified example of the first embodiment is now stored in two separate data stores that are operatively connected to a single data store interface 14. More particularly, referring to Figures 40a and 40b, a first of the data stores 4 ("Social Security") stores data defining the name, address, social security number and biometric of each person. Referring to Figures 41a and 41b, the second data store ("Births and Deaths") stores data defining the social security number, date of birth, place of birth and date of death (if any) for each person.

The instruction store 3704 for the data store interface 14 that is operatively connected to the first and second data stores 4 (that is, dsi.socialsecuritybirthsanddeaths.gov.nesw) stores the data shown in Figures 37a, 37b and 37c.

Accordingly, upon receipt of the question identifier Q , the identifier attribute types "Name" and "Address" and the identifier attributes "Jane Smith" and "2 Eastway, Eastton, East State, EK20 ESW" at step S9-28, dsi.socialsecuritybirthsanddeaths.gov.nesw selects at step S9-30 the instruction

SELECT Social Security Number FROM SOCIAL SECURITY

WHERE Address Line 1 = "[Address Line 1]"

AND Address Line 2 = " [Address Line 2] "

AND Address Line 3 = "[Address Line 3]"

AND Postcode = "[POSTCODE]" AND First Name = "[First Name]"

AND Middle Name = "[Middle Name]"

AND Surname = "[Surname]" SELECT IF(COUNT(*)>0,'1 ','Ο') as result FROM BIRTHS AND DEATHS

WHERE Social Security Number = "[Social Security Number]"

AND Date Of Birth <= "(today's date minus 18 years)"

The selected instruction comprises two instructions, each being a separate executable instruction in its own right. In English, the first selected instruction comprises the instruction "Return the Social Security Number stored for Jane Smith of 2 Eastway, Eastton, East State, EK20 ESW". The second selected instruction corresponds to the polar question "Is the date of birth stored for supplied Social Security Number before or on today's date minus 18 years?", where "today's date" is determined by dsi.socialsecuritybirthsanddeaths.gov.nesw by reading the date from an internal calendar (although it could be determined in other ways, for example by transmission to the data store interface 14 by verification controller 12 or by the data store 4 to which the second instruction is transmitted reading the date from its own internal calendar). At step S38-2, dsi.socialsecuritybirthsanddeaths.gov.nesw determines whether the selected instruction requires information from more than one operatively connected data store 4. In the present example, the selected instruction comprises two instructions and therefore dsi.socialsecuritybirthsanddeaths.gov.nesw determines that information is required from two data stores, and so processing proceeds to step S38- 14.

At step S38-14, dsi.socialsecuritybirthsanddeaths.gov.nesw determines the first data store 4 that is to be interrogated using the first instruction selected at step S9-30. In the present example, the data store "Social Security" is stored in column 3710 of instruction store 3704 in association with the first instruction for question identifier Q . Accordingly, at step S38-14, dsi.socialsecuritybirthsanddeaths.gov.nesw determines that the first data store to be interrogated is the data store "Social Security". At step S38-16, dsi.socialsecuritybirthsanddeaths.gov.nesw interrogates the data store "Social Security" with the first instruction in relation to the identifier attribute types "Name" and "Address", and the identifier attributes "Jane Smith" and "2 Eastway, Eastton, East State, EK20 ESW".

At step S38-18, the data store "Social Security" receives and executes the first instruction, and at step S38-20 transmits its response. Referring to Figures 40a and 40b, the data store "Social Security" stores the social security number "SSN98765432" for Jane Smith of 2 Eastway, Eastton, East State, EK20 ESW. Accordingly, at step S38-20, the data store "Social Security" transmits the response "SSN98765432".

At step S38-22, the response "SSN98765432" is received by dsi.socialsecuritybirthsanddeaths.gov.nesw, which then processes the response at step S38- 24 to determine whether the response comprises data defining an attribute or a "null" result. In the present example, the response comprises data defining an attribute (that is, a social security number), and therefore processing proceeds to step S38-30.

Although the data store interface dsi.socialsecuritybirthsanddeaths.gov.nesw now holds the input identifier attributes "Jane Smith" and "2 Eastway, Eastton, East State, EK20 ESW" as well as the social security number "SSN98765432", this combination of data previously existed in the data store "Social Security" and so there has been no data aggregation in dsi.socialsecuritybirthsanddeaths.gov.nesw because no new combination of data has been created. At step S38-30, dsi.socialsecuritybirthsanddeaths.gov.nesw determines the data store 4 that is to be interrogated using the second instruction selected at step S9-30. In the present example, the data store "Births and Deaths" is stored in column 3710 of instruction store 3704 in association with the second instruction for question identifier Q ⁷⁸ . Accordingly, at step S38-38, dsi.socialsecuritybirthsanddeaths.gov.nesw determines that the second data store to be interrogated is the data store "Births and Death". At step S38-32, dsi.socialsecuritybirthsanddeaths.gov.nesw interrogates the data store "Births and Deaths" with the second instruction selected at step S9-30 in relation to the bridging identifier attribute type "Social Security Number" and the bridging identifier attribute "SSN98765432", so as to instruct the final data store to return an answer to the polar question "Is the date of birth stored for Social Security Number SSN98765432 before or on today's date minus 18 years?", where "today's date" is supplied in this example by dsi. socialsecuritybirthsanddeaths.gov. nesw from an internal calendar, as described above.

At step S38-34, the data store "Births and Deaths" receives and executes the second instruction and transmits its result at step S38-36. Referring to Figures 41a and 41b, the date of birth stored in the data store "Births and Deaths" for the social security number "SSN98765432" is "15.06.1993", which is more than 18 years before today's date. Accordingly, at step S38-36, the data store "Births and Deaths" transmits the result "true". At step S38-38, dsi.socialsecuritybirthsanddeaths.gov.nesw receives the result "true" and, at step S38-40, transmits the "true" result to verification controller 12 in relation to question identifier Q ⁷⁸ .

From the above description, it will be understood that a data store interface 14 of the first modification provides the advantage that data from more than one data store 4 operatively connected to the data store interface 14 can be used to determine the answer to a single bipolar question corresponding to a question identifier received from verification controller 12 without aggregating data. [Second Modification]

A second modification will now be described that permits a data store interface 14 that is operatively connected to more than one data store 4 to make use of the data stored in two of the data stores to obtain a result for a single polar question corresponding to a question identifier received from verification controller 12 without aggregating data. In the second modification, the user equipments 8, verification controller 12 and data stores 4 have the same structure as, and perform the same processing operations as, the user equipments 8, verification controller 12 and data stores 4, respectively, in the first and second embodiments. However, in the second modification, a data store interface that is operatively connected to a plurality of data stores 4 is different from, and performs different processing operations from, the data store interfaces 14 in the first and second embodiments.

More particularly, as will be explained in more detail below, the functionality of a data store interface 14 that is operatively connected to more than one data store 4 is split between a plurality of data store interface modules, comprising a respective data store interface module for each of two data stores. This is illustrated in Figure 42, for example, in which the functionality of a data store interface 14 connected to two data stores 4 is split between a first data store interface module 14-1 and a second data store interface module 14-2.

The first data store interface module is configured to communicate with verification controller 12 and to interrogate a first of the connected data stores using one or more identifier attributes received from verification controller 12 to cause the first data store to return data stored in the first data store, and is further configured to transmit the data returned by the first data store to the second data store interface module. The second data store interface module is configured to interrogate a second data store using the data obtained from the first data store as one or more identifier attributes so as to obtain from the second data store an answer to the polar question corresponding to the question identifier received from verification controller 12 indicating whether the question is answered positively or negatively.

In more detail, each instruction that is stored in association with a question identifier in the instruction store of the first data store interface module in the second modification comprises a plurality of respective instructions, each respective instruction being configured for use by a different data store interface module to interrogate a different data store 4, and each respective instruction being a separate executable instruction in its own right.

The first data store interface module is configured to interrogate a first data store 4 using a first instruction to cause the first data store to return to the first data store interface module data of one or more specified attributes that are stored in the first data store in association with one or more of the identifier attributes received from verification controller 12. The first data store interface module is further configured to transmit to the second data store interface module a second instruction and attribute data received from the first data store. The second instruction is configured for use by the second data store interface module to interrogate a second data store using the identifier attribute(s) obtained from the first data store to obtain from the second data store an answer to the polar question corresponding to the question identifier received from verification controller 12 indicating whether the question is answered positively or negatively. In this way, no attribute data is returned from the second data store to the second data store interface module.

Accordingly, the first data store interface module is configured to transmit to the second data store interface module the second instruction and one or more identifier attributes obtained by the first data store interface module from the first data store. The second data store interface module is configured to interrogate the second data store using the second instruction and the identifier attribute(s) received from the first data store interface module so as to obtain from the second data store an answer to the polar question corresponding to the question identifier received from verification controller 12 indicating whether the question is answered positively or negatively. No aggregation of data occurs during this processing because, firstly, although the first data store interface module receives attribute data from the first data store, and holds this data along with the input identifier attributes received from verification controller 12, this combination of data already existed in the first data store (otherwise the first data store would not have been able to return any attribute data to the first data store interface module when interrogated using the input identifier attributes) and, secondly, the second data store returns data indicating whether a polar question is answered positively or negatively, so no data from the second data store is combined with that held in the data store interface. The second modification will now be described in further detail with reference to the example shown in Figure 42.

Figures 43 a, 43b and 43 c show an example of data stored in the instruction store 4704 of the first data store interface module 14-1. For illustrative purposes, the example of Figures 43a, 43b and 43c is based upon the data shown in Figures 28a and 28b that was stored in the instruction store 704 of the data store interface dsi.birthsanddeaths.gov.nesw in the simplified example of the first embodiment. Referring to Figures 43 a, 43b and 43 c, the question identifiers Q and Q are stored in the instruction store 4704, as in the first embodiment. However, the instruction that is stored in association with each question identifier is different in the second modification. More particularly, each instruction comprises a respective instruction for each data store interface module, each respective instruction being an executable instruction in its own right. Accordingly, in this example, each stored instruction comprises a first instruction for use by the first data store interface module 14-1 and a second instruction for use by the second data store interface module 14-2. The first instruction is configured for use by the first data store interface module 14-1 to interrogate a first operatively connected data store using one or more question identifiers received from verification controller 12 to cause the first data store 4 to return data to the first data store interface module 14-1. The second instruction is configured for use by the second data store interface module 14-2 to interrogate a second operatively connected data store using the data obtained from the first data store as one or more identifier attributes to obtain from the second data store an answer to the polar question corresponding to the question identifier associated with the question identifier received from verification controller 12, indicating whether the question is answered positively or negatively. Furthermore, for the second instruction, data is stored defining the data store interface module to which the second instruction is to be transmitted (this being illustrated in column 4710 in Figures 43 a, 43b and 43 c). The use of these first and second instructions will be explained further in the following description of the processing operations performed in the second modification. In the second modification, the processing operations at steps S9-2 to S9-30 and steps S9- 40 to S9-158 are the same as those in the first embodiment and accordingly will not be described again here. However, the processing operations performed at steps S9-32 to S9- 38 in the first embodiment are replaced in the second modification by the processing operations performed at steps S44-2 to S44-50 shown in Figures 44a, 44b, 44c and 44d (in which steps S9-28, S9-30 and S9-40 from the first embodiment are shown for ease of reference).

Referring to Figure 44a, after the first data store interface module 14-1 has received input verification data at step S9-28 comprising data defining a question identifier, one or more identifier attribute types and one or more identifier attributes, and has selected at step S9- 30 the instruction stored in instruction store 4704 in association with the received question identifier, processing proceeds in the second modification to step S44-2, at which the first data store interface module 14-1 determines whether the selected instruction requires information from more than one data store. This check is made because, in some cases, a question identifier from verification controller 12 may require data from only one data store 4 to be used to determined an answer to the corresponding polar question indicating whether the question is answered positively or negatively (as in the first embodiment). The determination at step S44-2 can be made, for example, by the first data store interface module 14-1 determining whether the selected instruction contains a plurality of instructions (it being noted above that an instruction for the interrogation of two data stores contains a respective instruction for each of the data store interface modules).

If it is determined at step S44-2 that the selected instruction does not require information from more than one data store, then processing proceeds to step S44-4, at which the first data store interface module 14-1 interrogates its operatively connected data store 4 with the selected instruction. The processing performed at step S44-4 and subsequent steps S44-6, S44-8, S44-10 and S9-40 is the same as that performed in the first embodiment at steps S9- 32 to S9-40, respectively. Accordingly, this processing will not be described again here. On the other hand, if it is determined at step S44-2 that the selected instruction does require information from more than one data store, then processing proceeds to step S44- 12. At step S44-12, the first data store interface module 14-1 interrogates the first data store 4 using the first instruction selected at step S9-30 so as to instruct the first data store 4 to return attribute data of one or more specified attribute types that are stored in the first data store 4 in association with one or more of the identifier attributes received from verification controller 12 at step S9-28. Each attribute defined by the attribute data that the first data store interface module 14-1 requests the first data store 4 to return is referred to as a bridging identifier attribute because the attribute is to be used by the data store interface 14 as an identifier attribute for the interrogation of a second data store 4, so that the attribute acts as a "bridge" between the first data store 4 and the second data store 4. At step S44-14, the first data store 4 receives and executes the instruction and at step S44- 16 transmits a response back to the first data store interface module 14-1.

At step S44-18, the first data store interface module 14-1 receives the response from the first data store 4 and, at step S44-20, checks whether the response is data defining one or more bridging identifier attributes, as requested, or whether the response is a "null" result that has been transmitted by the first data store 4 because it does not contain the requested attribute data.

If it is determined at step 44-20 that the response is a "null" result, then processing proceeds to step S44-22, at which the first data store interface module 14-1 sets the "null" result to be either a "true" or "false" result depending upon the polar question of the corresponding question identifier (in a similar way that a "null" result was set to be a "true" result or a "false" result in the second embodiment described above at step S35- 10). Following the setting of the "null" result to either "true" or "false", processing proceeds to step S44-24, at which the first data store interface module 14-1 transmits the "true" or "false" result to verification controller 12 in relation to the corresponding question identifier. Subsequently, processing proceeds to step S9-42, which has already been described in the first embodiment.

On the other hand, if it is determined at step S44-20 that the response from the first data store 4 comprises attribute data defining the requested bridging identifier attribute(s), then processing proceeds to step S44-26, at which the first data store interface module 14-1 determines the data store interface module for the second data store to be interrogated (this determination being performed in this example by reading the identity of the data store interface module from the data stored in column 4710 of the instruction store 4704).

At steps S44-28 and S44-30, the first data store interface module 14-1 and the second data store interface module 14-2 identified at step S44-26 establish a secure connection (it being possible to omit steps S44-28 and S44-30 if a secure connection already exists between the first data store interface module 14-1 and the second data store interface module 14-2).

At step S44-32, the first data store interface module 14-1 transmits to the second data store interface module 14-2 verification data comprising the second instruction, the bridging identifier attribute type(s) and bridging identifier attribute(s) received at step S44-18 from the first data store, and also any necessary additional identifier attribute type(s) and identifier attribute(s) previously received from verification controller 12 at step S9-28.

The verification data is received by the second data store interface module 14-2 at step S44-34. At step S44-36 the second data store interface module 14-2 interrogates the second data store 4 using the second instruction, the bridging identifier attribute(s) and any identifier attribute(s) received at step S44-34 so as to instruct the second data store 4 to return a result "true" or "false". At step S44-38, the second data store 4 receives and executes the instruction and, at step S44-40, transmits a reply "true" or "false". At step S44-42, the second data store interface 14-2 receives the "true" or "false" reply and, at step S44-44, transmits a reply "true" or "false" to the first data store interface module 14-1. The first data store interface module 14-1 receives the "true" or "false" reply at step S44- 46 and, at step S44-48, disconnects the secure connection with the second data store interface 14-2 (if such a connection had previously been established at steps S44-28 and S44-30). At step S44-50, the first data store interface module 14-1 transmits the result "true" or "false" to verification controller 12 in relation to the corresponding question identifier.

Subsequently, processing proceeds to step S9-42, which has already been described in the first embodiment.

In the processing above, the "true" or "false" result obtained by the second data store interface module 14-2 at step S44-42 is transmitted to the first data store interface module 14-1 (in step S44-44) and is subsequently transmitted from the first data store interface module 14-1 to verification controller ( in step S44-50). However, instead, the second data store interface module 14-2 may be configured to transmit the "true" or "false" result directly to verification controller 12.

From the above description it will be understood that the computer processing apparatus 200 of the first data store interface module 14-1 in the second modification is configured to provide the data stores and functional processing units shown in Figure 45, comprising connection controller 4102, input verification data receiver 4104, input verification data store 4702, instruction selector 4106, instruction store 4704, instruction analyser 4114, data store interrogator 4108, interrogation response receiver 41 10, interrogation response analyser 4116, output verification transmitter 4118, result receiver 4120 and result transmitter 4112. Connection controller 4102 is the same as connection controller 1 102 in the first embodiment and is arranged to perform the processing operations at steps S9-24, S9-64, S44-28 and S44-48. Input verification data receiver 4104 is the same as input verification data receiver 1 104 in the first embodiment and is arranged to perform the processing operations at steps S9-28 and S9-68.

Input verification data store 4702 is the same as input verification data store 702 in the first embodiment and is configured to store the input verification data received at step S9-28.

Instruction selector 4106 is the same as instruction selector 1106 in the first embodiment and is arranged to perform the processing operations at steps S9-30 and S9-70.

Instruction store 4704 is configured to store question identifiers and instructions as described above, and may be further configured to store a biometric retrieval command in association with an identifier for the biometric retrieval command, as described in the first embodiment.

Instruction analyser 4114 is arranged to perform the processing operations at steps S44-2 and S44-26.

Data store interrogator 4108 is arranged to perform the processing operations at steps S44- 4 and S44-12. Interrogation response receiver 4110 is arranged to perform the processing operations at steps S44-10 and S44-18 and also, if the biometric retrieval command is stored in the first data store interface module, step S9-78.

Interrogation response analyser 4116 is arranged to perform the processing operations at steps S44-20 and S44-22. Output verification data transmitter 4118 is arranged to perform the processing operations at step S44-32.

Result receiver 4120 is arranged to perform the processing operations at step S44-46.

Result transmitter 4112 is the same as result transmitter 1 1 12 in the first embodiment and is arranged to perform the processing operations at steps S9-40, S44-24, S44-50 and S9-80.

It will furthermore be understood from the above description that the computer processing apparatus 200 of the second data store interface module 14-2 in the second modification is configured to provide the data stores and functional processing units shown in Figure 46, comprising connection controller 4202, input verification data receiver 4204, input verification data store 4206, data store interrogator 4208, interrogation response receiver 4210 and result transmitter 4212.

Connection controller 4202 is arranged to perform the processing operations at step S44- 30.

Input verification data receiver 4204 is arranged to perform the processing operations at step S44-34.

Input verification data store 4206 is configured to store the input verification data received at step S44-34. Data store interrogator 4208 is arranged to perform the processing operations at step S44- 36.

Interrogation response receiver 4210 is arranged to perform the processing operations at step S44-42.

Result transmitter 4212 is arranged to perform the processing operations at step S44-44. To further illustrate the processing operations performed by the different data store interface modules in the second modification, the processing operations at steps S44-2 to S44-50 will be described for the question identifier Q ⁷⁸ in the simplified example previously described for the first embodiment, in which a lady visits a polling station to vote in an election in the country "NESW" and states that her name is Jane Smith and that she lives at 2 Eastway, Eastton, East State, EK20 ESW. To illustrate this processing, assume that the data shown in Figures 29a and 29b that is stored in a single data store 4 in the simplified example of the first embodiment is now stored in two separate data stores comprising a first data store 4 ("Social Security") connected to a first data store interface module 14-1 and a second data store 4 ("Births and Deaths") connected to a second data store interface module 14-2. More particularly, the data stored in the first data store 4 is shown in Figures 40a and 40b and comprises data defining the name, address, social security number and biometric of each person. The data stored in the second data store 4 is shown in Figures 41a and 41b, and comprises data defining the social security number, date of birth, place of birth and date of death (if any) for each person.

A first data store interface module dsi.socialsecurity.gov.nesw is operatively connected to the first data store. A second data store interface module dsi.birthsanddeaths.gov.nesw is operatively connected to the second data store.

The instruction store 4704 for the first data store interface module 14-1 (that is, dsi.socialsecurity.gov.nesw) stores the data shown in Figures 43a, 43b and 43c.

Accordingly, upon receipt of the question identifier Q ⁷⁸ , the identifier attribute types "Name" and "Address" and the identifier attributes "Jane Smith" and "2 Eastway, Eastton, East State, EK20 ESW" at step S9-28, the first data store interface module dsi.socialsecurity.gov.nesw selects at step S9-30 the instruction

SELECT Social Security Number FROM SOCIAL SECURITY

WHERE Address Line 1 = "[Address Line 1]"

AND Address Line 2 = "[Address Line 2]"

AND Address Line 3 = "[Address Line 3]" AND Postcode = "[POSTCODE]"

AND First Name = "[First Name]"

AND Middle Name = "[Middle Name]"

AND Surname = "[Surname]"

SELECT iF(COUNT(*)>0,T, ') as result FROM BIRTHS AND DEATHS

WHERE Social Security Number = "[Social Security Number]"

AND Date Of Birth <= "(today's date minus 18 years)" The selected instruction comprises two respective instructions, each being a separate executable instruction in its own right. In English, the first selected instruction comprises the instruction "Return the Social Security Number stored for Jane Smith of 2 Eastway, Eastton, East State, EK20 ES W". The second instruction corresponds to the polar question "Is the date of birth stored for the supplied Social Security Number before or on today's date minus 18 years?", where "today's date" is determined by the first data store interface module dsi.socialsecurity.gov.nesw by reading the date from an internal calendar (although it could be determined in other ways, for example by transmission to the first data store interface module 14-1 by verification controller 12, by the second data store interface module 14-2 reading the date from its own internal calendar, or by the second data store 4 (which is interrogated using the second instruction) reading the data from its own internal calendar).

At step S44-2, dsi.socialsecurity.gov.nesw determines whether the selected instruction requires information from more than one data store 4. In the present example, the selected instruction comprises two respective instructions and therefore dsi.socialsecurity.gov.nesw determines that information is required from two data stores, and so processing proceeds to step S44-12.

At step S44-12, dsi.socialsecurity.gov.nesw interrogates the first data store "Social Security" with the first instruction in relation to the identifier attribute types "Name" and "Address" and the identifier attributes "Jane Smith" and "2 Eastway, Eastton, East State, EK20 ESW". At step S44-14, the data store "Social Security" receives and executes the first instruction, and at step S44-16 transmits its response. Referring to Figures 40a and 40b, the data store "Social Security" stores the social security number "SSN98765432" for Jane Smith of 2 Eastway, Eastton, East State, EK20 ESW. Accordingly, at step S44-16, the data store "Social Security" transmits the response "SSN98765432".

At step S44-18, the response "SSN98765432" is received by the first data store interface module dsi.socialsecurity.gov.nesw, which then processes the response at step S44-20 to determine whether the response comprises data defining an attribute or a "null" result. In the present example, the response comprises data defining an attribute (that is, a social security number), and therefore processing proceeds to step S44-26.

Although the first data store interface module dsi.socialsecurity.gov.nesw now stores the input identifier attributes "Jane Smith" and "2 Eastway, Eastton, East State, EK20 ESW" received from verification controller 12 along with the social security number "SSN98765432" received from the first data store "Social Security", this combination of data already existed in the first data store "Social Security" and so there is no aggregation of data because no new combination of data has been created. At step S44-26, the first data store interface module dsi.socialsecurity.gov.nesw determines the data store interface module to which the second instruction selected at step S9-30 should be transmitted. In the present example, the data store interface module dsi.birthsanddeaths.gov.nesw is stored in column 4710 of instruction store 4704 in

78

association with the second instruction for question identifier Q . Accordingly, at step S44-26, dsi.socialsecurity.gov.nesw determines that the data store interface module to which the second instruction should be transmitted is dsi.birthsanddeaths.gov.nesw.

At steps S44-28 and S44-30, dsi.socialsecurity.gov.nesw and dsi.birthsanddeaths.gov.nesw establish a secure connection.

At step S44-32, the first data store interface module dsi.socialsecurity.gov.nesw transmits output verification data comprising question identifier Q ⁷⁸ , the second instruction, the bridging attribute type "Social Security Number", the bridging identifier attribute "SSN98765432", and today's date.

At step S44-34 the verification data is received by the second data store interface module dsi.birthsanddeaths.gov.nesw.

At step S44-36, dsi.birthsanddeaths.gov.nesw interrogates the second data store "Births and Deaths" with the second instruction in relation to the bridging identifier attribute type "Social Security Number" and the bridging identifier attribute "SSN98765432", so as to instruct the second data store to return an answer to the polar question "Is the date of birth stored for Social Security Number SSN98765432 before or on today's date minus 18 years?", where "today's date" is supplied in this example by the first data store interface dsi.socialsecurity.gov.nesw from an internal calendar, as described above. At step S44-38, the second data store "Births and Deaths" receives and executes the second instruction and transmits its result at step S44-40. Referring to Figures 41a and 41b, the date of birth stored in the data store "Births and Deaths" for the social security number "SSN98765432" is "15.06.1993", which is more than 18 years before today's date. Accordingly, at step S44-40, the data store "Births and Deaths" transmits the result "true".

At step S44-42, the second data store interface module dsi.birthsanddeaths.gov.nesw receives the result "true" and at step S44-44 transmits the "true" result to the first data store interface module dsi.socialsecurity.gov.nesw. At step S44-46, the first data store interface module dsi.socialsecurity.gov.nesw receives the "true" result and, at step S44-48, disconnects the secure connection with the second data store interface module dsi.birthsanddeaths.gov.nesw.

At step S44-50, the first data store interface module dsi.socialsecurity.gov.nesw transmits the result "true" to verification controller 12 in relation to question identifier Q . From the above description, it will be understood that a data store interface 14 of the second modification provides the advantage that data from more than one data store 4 operatively connected to the data store interface 14 can be used to determine the answer to a single bipolar question corresponding to a question identifier received from verification controller 12 without aggregating data.

[Further Modifications]

As explained in the first and second embodiments and the first and second modifications above, the operation of the verification controller is the same in each embodiment and each modification, while the operation of the data store interfaces changes in the different embodiments and different modifications. This means that verification controller 12 can be supplied without knowledge of what type of a data store interface 14 it is to be used with, as it is compatible with all of the different types of data store interfaces (that is, a data store interface 14 in accordance with the first embodiment, the second embodiment, the first modification or the second modification). Similarly, the supplier of a data store interface 14 can provide any of the different types of data store interfaces as they are all compatible with the verification controller 12. Therefore, different data store interfaces 14 may be provided by different suppliers without a supplier consulting with the supplier(s) providing the other data store interfaces 14.

Many further modifications can be made to the embodiments and the first and second modifications described above. For example, in the embodiments and modifications described above, verification controller 12 is operatively connected to a plurality of different data store interfaces 14 so that data from a plurality of different data stores 4 can be used to verify if an entity satisfies a number of different criteria. However, for some applications, verification controller 12 may be operatively connected to a single data store interface 14 and data from a single data store 4 may be used to verify if an entity satisfies a single criterion or a plurality of criteria. In the embodiments and modifications described above, verification controller 12 and each respective data store interface 14 is implemented on a single apparatus. A different respective single apparatus may be used to implement each one of the verification controller 12 and the data store interfaces 14. Alternatively, a single apparatus may implement a plurality of the data store interfaces 14, or may implement verification controller 12 and one or more data store interfaces 14. However, in each case, the full functionality of the functional component implemented is provided by the single apparatus. As a modification, more than one apparatus could be used to implement the functionality of verification controller 12 or a single data store interface 14.

In the embodiments and modifications described above, verification controller 12 stores multiple question sets and processing is performed at step S9-18 to select a question set to be used for verification of an entity based upon the verification type requested by a user equipment 8 in the data received at step S9-16. However, instead, multiple verification controllers 12 may be provided, with each of the verification controllers 12 storing a different question set and therefore providing a different type of verification. A user equipment 8 wishing to perform a particular type of verification would then connect to the appropriate verification controller 12 that provides the type of verification required. This could be achieved, for example, by providing each verification controller 12 with its own, unique URL. Furthermore, some of the multiple verification controllers 12 could store the same question set. In this way, if one of the verification controllers storing the question set failed, an alternative verification controller storing the same question set would be available, thereby providing resilience in the case of failure. The provision of multiple verification controllers 12 storing the same question set could also assist in load balancing during periods of heavy demand in which many user equipments 8 wish to perform the same type of verification. In cases with multiple verification controllers 12, a plurality of verification controllers 12 may be connected to a single data store interface 14 if the data stored in the data store 4 operatively connected to that data store interface 14 is needed to perform different types of verification. A data store interface 14 connected to multiple verification controllers 12 would store in its instruction store instructions for each question identifier that would be transmitted from the different verification controllers 12. In the embodiments and modifications described above, each communication link 6 between a data store interface 14 and its data store(s) 4 is an internal communication link because each data store interface 14 resides on the same server as its data store(s). However, as noted previously, each data store interface 14 need not reside on the same server as its data store(s). In an implementation in which a data store interface 14 does not reside on the same server as its data store 4, the data store interface 14 and the data store 4 would establish a secure connection before communicating with each other (in the same way that a secure connection is established between verification controller 12 and each data store interface 14 in the embodiments and modifications described above).

In the embodiments and modifications described above, data defining a biometric comprising an image of the face of a person may be output as part of the response by verification controller 12 to a user equipment 8. However, instead, data defining a biometric identifier (for example a unique ID stored in association with a biometric such as a facial image, fingerprint, palm print, etc in a separate database) may be obtained by verification controller 12 from a data store 4 via a data store interface 14 (in the same way that the biometric comprising the facial image was obtained in the embodiments and modifications described above) and transmitted by verification controller 12 to user equipment 8. This would enable the receiving user equipment 8 to obtain the relevant biometric itself from the separate database using the biometric identifier.

In the embodiments and modifications described above, verification controller 12 is arranged to transmit some of the question identifiers stored in question set store 304 to different data store interfaces 14 sequentially. By way of example, referring to the question set store 304 shown in Figure 13 for the simplified example that was described previously, verification controller 12 transmits question identifiers Q , Q and Q sequentially. However, instead, verification controller 12 could be arranged to send question identifiers in parallel to the data store interfaces 14. In the embodiments and modifications described above, verification controller 12 is configured to perform processing at step S9-52 to evaluate the answers stored in results store 306 to determine an overall result, which it subsequently transmits to a user equipment 8. The processing at step S9-52 is performed after all answers have been received from the data store interfaces 14 and stored in results store 306. However, instead, verification controller 12 may be configured to transmit partial results to user equipment 8 as answers are received from the different data store interfaces 14, rather than waiting for all answers to be received from all data store interfaces 14 before transmitting an overall result. These partial results may be provided instead of, or as well as, the overall result. By way of example, referring to the answers shown in results store 306 in Figure 32 of the simplified example described previously, verification controller 12 may be configured to transmit a first partial result when answers have been received from data store interfaces 14 for the question identifiers Q ²³ and Q ¹⁶ . In the simplified example described, this first partial result could take a format such as "a Result 1 of 4: pass". Similarly, verification controller 12 could transmit a second partial result when the answer has been received to question identifier Q ¹⁹ . This second partial result could take a format such as "Result 2 of 4: pass". Similarly, when an answer for question identifier Q ⁷⁸ is received, verification controller 12 may transmit a third partial result, such as "Result 3 of 4: pass". Subsequently, upon receipt of an answer for question identifier Q ⁴³ , verification controller 12 may transmit a fourth partial result, such as "Result 4 of 4: Fail". As noted, verification controller 12 may also transmit an overall result as described in the embodiments and modifications above, or the overall result may be omitted.

In the embodiments and modifications described above, each answer to a polar question that is transmitted from a data store 4 to a data store interface 14 and/or from a data store interface 14 to verification controller 12 has a binary format (such as, for example, true/false, yes/no, etc). However, instead, an answer may take a different form. For example, an answer may take the form of a binary response (as before) plus a level of confidence. Alternatively, an answer may take the form of a level of confidence alone. The level of confidence could be, for example, a percentage or a relevance score. The skilled person will be aware of many different techniques for generating levels of confidence such as percentages or relevance stores. For example, one method of generating a relevance score would be by querying based on FULLTEXT indexed fields in MySQL. In the second embodiment, a level of confidence could be produced by a datastore interface 14 by configuring the datastore interface 14 to process the data returned from a datastore 4 using fuzzy logic or the like. If an answer includes a confidence level, then the receiving datastore interface 14 or verification controller 12 may be configured to determine whether the corresponding polar question is answered positively or negatively for example by comparing the level of confidence against a stored threshold level.

In the Second Modification described above, the second instruction for interrogating the second data store is stored in the first data store interface module 14-1 and is transmitted to the second data store interface module 14-2 at step S44-32. However, as a modification, the second instruction could be stored in the second data store interface module 14-2.

In the embodiments and modifications described above, each alert is transmitted by verification 12 to a user equipment over a secure connection. However, one or more alerts to one or more user equipment may be transmitted over a non-secure connection, for example if it is not important to keep the alert secure.

Many other modifications can be made without departing from the spirit and scope of the appended claims.

It will be understood from the above description that a verification controller and a data store interface in embodiments and modifications of the invention perform the processing operations shown in Figures 47a and 47b.

Referring to these figures, at step S47-2, the verification controller receives data defining an identifier attribute for an entity.

At step S47-4, the verification controller transmits to the data store interface data defining the identifier attribute.

At step S47-6, the verification controller transmits to the data store interface data defining a question relating to the entity, the question requiring an answer indicating whether the question is answered positively or negatively. At step S47-8, the data store interface receives the data defining the identifier attribute and the data defining the question from the verification controller.

At step S47-10, the data store interface interrogates a data store using a stored instruction.

At step S47-12, the data store interface transmits to the verification controller data indicating whether the question is answered positively or negatively.

At step S47-14, the verification controller receives from the data store interface the data indicating whether the question is answered positively or negatively.

At step S47-16, the verification controller transmits a response indicative of whether the entity satisfies the criterion in dependence upon the data received from the data store interface.

It will be appreciated that the processing operations performed by the verification controller and the data store interface need not necessarily be in the order shown in Figures 47a and 47b. For example, the processing at step S47-6 could be performed before the processing at step S47-4. Furthermore, the data defining the identifier attribute and the data defining the question may be received at different times or in a different order by the data store interface so that the processing at step S47-8 shall not be understood to be restricted to simultaneous receipt of the data or receipt of the data in any particular order.

It will also be understood from the description above that a verification controller in embodiments and modifications of the invention performs the processing operations shown in Figure 48.

Referring to this figure, at step S48-2, the verification controller receives data defining an identifier attribute for an entity.

At step S48-4, the verification controller transmits data to a data store interface defining the identifier attribute. At step S48-6, the verification controller transmits data to the data store interface defining a question relating to the entity, the question requiring an answer indicating whether the question is answered positively or negatively.

At step S48-8, the verification controller receives data from the data store interface indicating whether the question is answered positively or negatively.

At step S48-10, the verification controller transmits a response indicative of whether the entity satisfies the criterion in dependence upon the data received from the data store interface.

It will be appreciated that the processing operations performed by the verification controller need not necessarily be in the order shown in Figure 48. By way of example, the processing operations at step S48-6 may be performed before the processing operations at step S48-4.

Furthermore, it will be understood from the above description that a data store interface in embodiments and modifications of the invention performs the processing operations shown in Figure 49.

Referring to this figure, at step S49-2, the data store interface stores an instruction for interrogating a data store. At step S49-4, the data store interface receives data from a verification controller defining an identifier attribute for an entity and data defining a question relating to the entity, the question requiring an answer indicating whether the question is answered positively or negatively. At step S49-6, the data store interface interrogates a data store using the stored instruction. At step S49-8, the data store interface transmits data to the verification controller indicating whether the question is answered positively or negatively.

It will be appreciated that the data from the verification controller defining an identifier attribute and the data from the verification controller defining a question may be received at different times and in different orders, so that the processing at step S49-4 should not be understood as being restricted to receiving the data at the same time or in a particular order.