WO2021064182A1

WO2021064182A1 - Computer-implemented transaction system and method

Info

Publication number: WO2021064182A1
Application number: PCT/EP2020/077672
Authority: WO
Inventors: Mustafa KAIIALI; Sakir Sezer
Original assignee: The Queen's University Of Belfast
Priority date: 2019-10-03
Filing date: 2020-10-02
Publication date: 2021-04-08
Also published as: GB2587817A; GB201914261D0

Abstract

A computer-implemented transaction system supports transactions between a user computing device and a provider computing device. The user computing device transmits a transaction service identifier to the provider computing device, and the provider computing device transmits the transaction service identifier to a provider transaction server. The provider transaction server communicates network with a user transaction server identified by the transaction service identifier, and requests that the transaction is performed between the user transaction server and provider transaction server. In response to the transaction request, the user transaction server communicates with the user computing device and authenticates usage of the respective user computing device. The user transaction server performs the transaction if usage of the user computing device is authenticated.

Description

Computer-implemented Transaction System and Method

Field of the Invention

The present invention relates to computer-implemented transaction systems.

Background to the Invention

Electronic contactless transactions are increasingly common and normally involve interaction between a mobile computing device and a contactless terminal. Some transactions may involve identity verification whereby a user is required to provide one or more aspects of his or her identity to a service provider, and/or may involve electronic payments from the user to the provider.

It is desirable for systems that support electronic transactions to include authentication processes in order to reduce their susceptibility to fraud and/or to provide the user with some control over the transaction. It is also desirable for such systems to be decentralized, or transportable, so that they may support transactions between a user and a wide range of service providers.

Summary of the Invention

From a first aspect the invention provides a computer-implemented transaction system comprising: at least one user transaction server at least one provider transaction server; at least one user computing device; and at least one provider computing device, wherein said at least one user computing device and said at least one user transaction server are enabled for communication with each other across a telecommunications network, said at least one provider computing device and said at least one provider transaction server are enabled for communication with each other across a telecommunications network, said at least one user transaction server and said at least one provider transaction server are enabled for communication with each other across a telecommunications network, and said at least one user computing device and said at least one provider computing device are enabled for communication with each other by wireless communication, and wherein in order to perform a transaction involving a respective user computing device and a respective provider computing device, the user computing device is configured to wirelessly transmit a respective transaction service identifier to said provider computing device, and said provider computing device is configured to send said transaction service identifier to a respective provider transaction server via said telecommunications network, and wherein said respective provider transaction server is configured to communicate via said telecommunications network with a respective user transaction server identified by said transaction service identifier, and to request that at least a part of said transaction is performed between the respective user transaction server and provider transaction server, and wherein, in response to said transaction request, said respective user transaction server is configured to communicate with the respective user computing device via said telecommunications network and to authenticate usage of said respective user computing device, and wherein said respective user transaction server is configured to perform said at least a part of said transaction if said usage of said respective user computing device is authenticated.

Preferably, said respective user transaction server is configured to authenticate said usage by implicit authentication means based on monitored usage of the respective user computing device.

Preferably, said user computing device is configured to monitor at least one aspect of usage of the user computing device, and to authenticate usage of said user computing device based on the monitored usage. More preferably, said user computing device is configured to provide an authentication indication to said user transaction server based on the monitored usage.

Said user computing device may be configured to authenticate usage by comparing usage data representing said monitored usage with reference usage data that represents genuine user usage, and to determine, based on the comparison, if the actual usage data matches the genuine usage data.

Typically, said at least one aspect of usage comprises any one or more of: incoming and/or outgoing messages; incoming and/or outgoing calls; browser history; WIFI history; application usage patterns; location history; accelerometer and/or other sensor measurements.

Optionally, said respective user transaction server is configured to authenticate said usage by explicit authentication means based on user input received by the respective user computing device. Said user computing device may include at least one biometric sensor and is configured to authenticate usage of said user computing device based on user input detected by said at least one biometric sensor. Said user computing device may be configured to provide an authentication indication to said user transaction server based on the user input detected by said at least one biometric sensor.

Optionally, said respective user transaction server is configured to authenticate said usage by explicit authentication means in response to failure of said implicit authentication means.

Optionally, the user computing device is operable to request explicit user input to approve the transaction. Said user computing device may be configured to receive said explicit user input by means of any one or more user input device included in the user computing device.

The user computing device may be operable to request said explicit user input after usage of said respective user computing device is determined to be authentic. Typically, the provider computing device is configured to wirelessly transmit a respective transaction service identifier to said user computing device, and said user computing device is configured to send said transaction service identifier to the respective user transaction server via said telecommunications network. Preferably, said user transaction server and said provider transaction server are configured to perform a mutual authentication process using the respective transaction service identifiers provided by the user computing device and the provider computing device.

In some embodiments, the transaction system comprises an identity verification system. Preferably the identity verification system is configured to support the provision of a self-sovereign identity service and may be described as a self-sovereign identity system. Preferably, the identity verification system comprises cloud computing resources in order to provide a cloud-based self sovereign identity service. Advantageously, self-sovereign identity provides users with control of his/her digital identity, for example control over what portion(s) of the identity is presented to an identity verifier. For example, should a provider transaction require the user to confirm his/her minimum age, the exact age may be kept secret, or if the exact age is required, other properties such as the user’s address may be kept secret. In preferred embodiments, the user’s digital identity is transportable in that it may be used with any compatible verification system.

In other embodiments, the transaction system may be provided as a stand-alone system, or may be included in any other computer-implemented system that supports transactions between user(s) and provider(s). Embodiments of the invention by be configured for use with any kind of transactions between users including but not limited to payment transactions and/or identity verification transactions.

From another aspect the invention provides an identity verification system comprising a computer- implemented transaction system according to the first aspect of the invention, wherein said at least one user transaction server includes or is in communication with at least one storage device for storing respective user identity data for each user of the system, and wherein said at least a part of said transaction involves transmitting at least part of the respective identity data of a respective user to said provider transaction server. Said provider transaction server may be configured to identify said at least part of the respective identity data when requesting that said at least a part of said transaction is performed between the respective user transaction server and provider transaction server. Said user transaction server may be configured to render to the user a notification identifying said at least part of the respective identity data when requesting approval of the transaction. Said at least one user transaction server may be configurable to allow control of which part or parts of said user identity data are available for communication to said provider transaction server.

The identity verification system may include an authority service computing system in communication with said at least one user transaction server and/or said at least one provider transaction server across a telecommunications network, and wherein said authority service computing system is configured to verify said user identity data and/or to control which part or parts of said identity data are available for communication to said provider transaction server.

From a further aspect the invention provides a payment system comprising a transaction system according to the first aspect of the invention, wherein said at least one user transaction server includes or is in communication with at least one storage device for storing respective payment data for each user of the system, and wherein said at least a part of said transaction involves transmitting at least part of the respective payment data of a respective user to said provider transaction server.

Further advantageous aspects of the invention will be apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments and with reference to the accompanying drawings.

Brief Description of the Drawings

Embodiments of the invention are now described by way of example and with reference to the accompanying drawings in which like numerals are used to denote like parts and in which:

Figure 1 is a block diagram of a computer-implemented transaction system embodying one aspect of the invention;

Figure 2 is a block diagram of a user computing device for use with computer-implemented transaction system of Figure 1 ; and

Figure 3 is a block diagram of a provider computing device for use with computer-implemented transaction system of Figure 1 .

Detailed Description of the Drawings

Referring now to the drawings there is shown, generally indicated as 10, a computer-implemented transaction system embodying one aspect of the invention. The transaction system 10 comprises at least one user transaction computing system 12 and at least one provider transaction computing system 14.

The user transaction computing system 12 may comprise at least one computer 16 executing, in use, at least one computer program 18 configured to cause the user transaction computing system 12 to support one or more user transaction as hereinafter described or otherwise as required by the application, and may comprise, or have access to, one or more electronic storage device 20 for storing data (e.g. banking or other payment details and/or identity information) relating to the respective user. The hardware and software components of the user transaction computing system 12, and their configuration, may take any suitable conventional form as required by the application.

In preferred embodiments, the user transaction computing system 12 is a cloud computing system configured to provide one or more cloud services to other computing devices or systems via a cloud computing network (typically comprising the internet). The user transaction computing system 12 may be said to comprise at least one user transaction server 12 that provides a user transaction service for each user of the system 10.

The provider transaction computing system 10 may comprise at least one computer 22 executing at least one computer program 24 configured to cause the provider transaction computing system 14 to support one or more provider transaction as hereinafter described or otherwise as required by the application, and may comprise one or more electronic storage device 26. The hardware and software components of the provider transaction computing system 14, and their configuration, may take any suitable conventional form as required by the application. In preferred embodiments, the provider transaction computing system 14 is a cloud computing system configured to provide one or more cloud services to other computing devices or systems via a cloud computing network (typically comprising the internet). The provider transaction computing system 14 may be said to comprise at least one provider transaction server 14 that provides a provider transaction service for each provider that uses the system 10.

The transaction system 10 further includes at least one, but typically a plurality of, user computing devices 30 (only one shown). Each user computing device 30 is typically a mobile computing device and may take any conventional form, for example a smart device such as a smart phone, smart watch, or tablet, or other mobile electronic device. In addition to any conventional software that the user device 30 may include, the user device 30 executes, in use, at least one computer program 32 configured to cause the user device 30 perform one or more user tasks as hereinafter described or otherwise as required by the application, and may comprise one or more processor 34 and electronic storage device 36 as required. The hardware and software components of the user device 30, and their configuration, may take any suitable conventional form as required by the application. The user device 30 supports wireless communication, preferably contactless communication, with other compatible electronic devices. Preferably, the user device 30 supports direct wireless, or contactless, communication with compatible electronic devices, preferably only when the devices are in close proximity with one another, for example when the devices are up to approximately 10 cm or up to approximately 30 cm apart. In preferred embodiments the user device 30 is configured to support Near Field Communication (NFC) but may, alternatively or in addition, be configured to support RFID, Bluetooth (trade mark), Zigbee (trade mark) and/or any other conventional wireless or contactless communication. The user device 30 may include any conventional hardware and software for supporting the relevant wireless/contactless communication as would be apparent to a skilled person. In typical embodiments, the user device 30 is configured to act as a client device with respect to the respective user transaction server 12. The user server 12 may be configured to allow the user 31 , conveniently via device 30, to configure one or more settings that determine the availability of the data stored by the server 12 and/or to add to, modify or otherwise maintain the data stored by the server 12. The transaction system 10 also includes at least one, but typically a plurality of, provider computing devices 40 (only one shown). Each provider computing device 40 may take any conventional form, mobile or otherwise, and may for example comprises a smart device such as a smart phone, smart watch or tablet, a laptop computer, a desktop computer, a computer workstation, or other computer. In addition to any conventional software that the provider device 40 may include, the provider device 40 executes, in use, at least one computer program 42 configured to cause the provider device 40 perform one or more provider tasks as hereinafter described or otherwise as required by the application, and may comprise one or more processor 44 and electronic storage device 46 as required. The hardware and software components of the provider device 40, and their configuration, may take any suitable conventional form as required by the application. The provider device 40 supports wireless communication, preferably contactless communication, with other compatible electronic devices, in particular the user device 30 (represented by communication link 1 ).

Preferably, the provider device 40 supports direct wireless, or contactless, communication with the user device 30, preferably only when the devices 30, 40 are in close proximity with one another, for example when the devices are up to approximately 10 cm or up to approximately 30 cm apart. In preferred embodiments the provider device 40 is configured to support Near Field Communication (NFC) but may, alternatively or in addition, be configured to support RFID, Bluetooth (trade mark), Zigbee (trade mark) and/or any other conventional wireless or contactless communication. The provider device 40 may include any conventional hardware and software for supporting the relevant wireless/contactless communication as would be apparent to a skilled person. Optionally, the provider computing device 40 may comprise a contactless terminal. In typical embodiments, the provider device 40 is configured to act a client device with respect to the respective provider transaction server 14. The provider server 14 may be configured to allow the user 41 , conveniently via device 40, to configure one or more settings that determine the availability of the data stored by the server 14 and/or to add to, modify or otherwise maintain the data stored by the server 14.

The transaction system 10 may comprise a respective user transaction server 12 for each user device 30, or multiple user devices 30 may share a common user transaction server 12 (e.g. each device 30 being associated with a respective account supported by the common user transaction server 12). In any event, each user device 30 is associated with a respective user transaction service that is supported by the, or a respective, transaction server 12 as is described in more detail hereinafter. The system 10 may comprise a respective provider transaction server 14 for each provider device 40, or multiple provider devices 40 may share a common user transaction server 12 (e.g. each device 40 being associated with a respective account supported by the common user transaction server 12). In any event, each provider device 40 is associated with a respective provider transaction service that is supported by the, or a respective, provider server 14 as is described in more detail hereinafter.

The components of the transaction system 10 support communication with one another, as required, via a telecommunications network (represented by communication links 2, 3, 4), which may take any conventional form, typically comprising at least one computer network (e.g. the internet) and/or at least one telephone network. In particular, each user device 30 is capable of communication with the user transaction server 12 (via communication line 4 in the drawing), each provider device 40 is capable of communication with the provider transaction server 14 (via communication line 2 in the drawing), the user transaction server 12 and provider transaction server 14 are capable of communication with each other (via communication line 3 in the drawing). The user device 30, provider device 40, user transaction server 12 and provider transaction server 14 may include any conventional hardware and software for supporting the relevant communication as would be apparent to a skilled person.

The operation of the preferred transaction system 10 is now described. It is assumed that the user 31 , using the user device 30, engages in a transaction that is facilitated by the user 41 , using the provider device 40. As described above, the user device 30 is associated with a respective cloud- based transaction-enabling user transaction server 12, and the provider device 40 is associated with a respective cloud-based transaction-enabling provider transaction server 14. In preferred embodiments, the transaction is initiated by direct communication between the user device 30 and the provider device 40. The direct communication is preferably wireless communication. In the illustrated embodiment, the direct communication is effected by wireless communication link 1 between the devices 30, 40, which for example may be supported by Bluetooth, NFC or other wireless technology. The transaction may be initiated when the user device 30 and provider device 40 are brought sufficiently close to one another to allow the communication link 1 to be established. The transaction may be initiated in response to one or other or both of the devices 30, 40 detecting that they are sufficiently close to the other device 40, 30, and/or in response to user interaction with the respective device 30, 40 (e.g. the provision of user input by either one or both of the users 31 , 41 to the respective device 30, 40).

In an initial stage of the transaction, either one or both of the user device 30 and provider device 40 transmits, via communication link 1 , a respective transaction service identifier to the other device 40, 30. In preferred embodiments, each device 30, 40 sends its respective transaction service identifier to the other device 40, 30. The transaction service identifier may comprise an address for the respective server 12, 14 and any other information required to identify the respective transaction service, e.g. an account number and/or other identifier for the respective user 31 or provider 41. In alternative embodiments, either one of the devices 30, 40 may send its transaction service identifier to the other device 40, 30, and the transaction server whose address is provided may send its address to the other transaction server as required.

After the initial stage in which transaction server identifiers are exchanged, performance of the transaction is delegated to the respective transaction servers 12, 14.

The, or each, of the client devices 30, 40 that has received a transaction service identifier sends the transaction service identifier to its respective transaction server 12, 14 (via communication links 4 and 2 respectively in the illustrated example). Either one of the transaction servers 12, 14 establishes a connection with the other of the transaction servers 14, 12 using the address provided by its client device 30, 40, i.e. by means of the respective transaction service identifier. This connection is represented by communication link 3, which in preferred embodiments comprises a connection between cloud servers. In typical embodiments, the provider transaction server 14 establishes the connection 3 with the user transaction server 12 and requests that the transaction is performed. Alternatively, the user transaction server 12 establishes the connection 3 with the provider transaction server 14 and requests that the transaction is performed. In either case, the request may include any information that is required to perform the transaction, e.g. information indicating any one or more of an account number or other payment information and/or other identifier for the respective user 31 or provider 41 , as applicable, and/or the information that the requesting server is requesting from the other server in order to perform the transaction. Data relating to the user 31 that is required to perform the transaction, including any data that may need to be sent to the provider transaction server 14 to perform the transaction, may be stored in storage device 20. Data relating to the provider 41 that is required to perform the transaction, including any data that may need to be sent to the user transaction server 12 to perform the transaction, may be stored in storage device 26. Any data received by either server 12, 14 relating to the transaction may be stored in the respective storage device 20, 26.

Preferably, a mutual authentication process is performed by the servers 12, 14, which may involve mutual verification using the respective address (and/or other identifier) provided to each server 12,

14 for the other server 14, 12 by the respective device 30, 40. The mutual authentication process is performed before the transaction is performed.

In preferred embodiments, before the transaction is performed, and in particular before the user transaction server 12 sends any user data to the provider transaction server 14 as part of the transaction, the user transaction server 12 communicates with the user device 30 in order to verify that the transaction may proceed. The verification may take any desired form and use any conventional authentication means. Preferably, the verification involves authenticating the user 30, which may be performed using any authentication means. In preferred embodiments, the authentication involves implicit authentication based on monitored usage of the user device 30. To this end, the user device 30 may support one or more computer programs 50 configured to monitor usage of the user device 30 and to provide an authentication indication based on the monitored usage. By way of example usage of the device 30 may be monitored by monitoring any one or more of the following aspects of the device 30: incoming and/or outgoing messages; incoming and/or outgoing calls; browser history; WIFI history; application usage patterns; location history; accelerometer and/or other sensor measurements. The implicit authentication program 50 may be configured to compare actual (i.e. current or recent) usage data to reference usage data that represents genuine user usage, and to determine, based on the comparison, if the actual usage data matches the genuine usage data. The comparison may be performed using any convenient conventional technique, for example using one or more conventional mathematical algorithms, for example Kullback-Leibler divergence or k-means clustering, or any other comparison or classification algorithms. The reference usage data may be obtained by any convenient conventional means, for example by applying machine learning algorithms to usage data obtained for training purposes, e.g. usage data gathered from the device 30 during one or more training periods. The reference data may comprise a usage model against which actual usage data may be compared to determine authenticity of use of the device 30. Generation of the reference data may be performed by the user device 30, e.g. by the implicit authentication program(s) 50, or may be performed by any other convenient computing system which may provide the reference data to the user device 30 as required.

If the actual usage data matches the genuine usage data then the implicit authentication program 50 may provide an indication that the user 30 is authentic, otherwise it may indicate that the user is inauthentic. In preferred embodiments, the user device 30, conveniently by means of the program(s) 50, provides the user transaction server 12 with an indication of whether or not the user 30 is authentic. Alternatively, the user device 30 may provide usage data to the server 12 and the server 12 may determine if the user is authentic. Optionally, multi-factor implicit authentication (MFIA) may be employed by which the implicit authentication program 50 and/or the user transaction server 12 cross-correlate usage or status feature(s), e.g. accelerometer and GPS information, of first and second user devices, e.g. a mobile device (such as a smartphone or tablet) and a smartwatch or any two paired user devices, so that the user 31 is only authenticated if it is determined that there is authentic usage of each of the user’s devices.

If implicit authentication fails, then the user device 30 and/or the user transaction server 12, as applicable, may seek explicit authentication of the user 31 . This may be achieved by any conventional means, for example by causing the user device 30 to prompt the user 31 (e.g. by rendering to the user a visual and/or audio message message) to provide authenticating user input to the device 30. The requested user input may take any form supported by the device 30, for example by means of a keyboard, touchscreen, biometric sensor or other available input device.

The user input may comprise a code, e.g. a PIN, or other unique identifier, but preferably comprises physiological biometric input such as a fingerprint input, iris input or facial recognition input. In alternative embodiments, explicit authentication may be used to authenticate the user 31 as well as or instead of implicit authentication, as desired, and the authentication program(s) 50 may be configured to support the relevant authentication process(es) as applicable.

When the user transaction server 12 communicates with the user device 30 to verify/authenticate the requested transaction, the user device 30 responds by providing information indicative of whether or not recent usage is deemed to be authentic and/or whether any other relevant authentication process has been successful, as applicable, conveniently by means of the authentication program(s) 50. The user device 30 may provide an indication of authentication or provide information that allows the transaction server 12 to make a determination on authentication, as desired. If authentication is established, then the transaction server 12 may allow, or cause, the transaction to proceed (subject to user approval, if applicable, as described below), otherwise the transaction may be denied. Optionally, the user transaction server 12 may request that the user device 30 requests input from the user 31 to approve the transaction. This approval process may be separate from any authentication process that is supported. The requested user input may take any form supported by the device 30, for example by means of a keyboard, touchscreen, biometric sensor, microphone or other available input device. The user input may comprise a code, e.g. a PIN, or other unique identifier, or may comprise a simple confirmation. This may be achieved by any conventional means, for example by causing the user device 30 to prompt the user 31 (e.g. by rendering to the user a visual and/or audio message message) to provide the approving user input to the device 30. This is illustrated in Figure 1 as a message 52 displayed on a touchscreen of the device 30 with “approve” and “deny” input buttons. In preferred embodiments, the transaction server 12 is configured to cause the user device 30 to request such user input after the implicit authentication program 50 has indicated to the transaction server 12 that the current detected actual usage of the device 30 is authentic.

If user input approving the transaction is received by the user device 30, this is indicated to the user transaction server 12 which may then allow or cause the transaction to take place between the user transaction server 12 and the provider transaction server 14 (subject to usage authentication, if applicable, as described above).

In some embodiments, the transaction system 10 is configured to serve as an identity verification system. Optionally, the system 10 supports the provision of a self-sovereign identity service and may be said to comprise a self-sovereign identity system. In preferred embodiments, the user transaction server(s) 12 and provider transaction server(s) 14 are implemented using any convenient conventional cloud computing technologies in order to provide a cloud-based self-sovereign identity service to the user device(s) 30 and provider device(s) 40. Advantageously, self-sovereign identity provides a user 31 of the device 30 with control of his/her digital identity, for example control over what portion(s) of the identity is presented to an identity verifier, which in the illustrated example is represented by the user 41 of the provider device 40. For example, should a provider transaction require the user to confirm his/her minimum age, the exact age may be kept secret, or if the exact age is required, other properties such as the user’s address may be kept secret. In preferred embodiments, the user’s digital identity is transportable in that it may be used with any compatible verification system. The user server 12 may therefore be configured to allow the user 31 , conveniently via device 30, to configure one or more settings that determine the availability of his/her identity data. The user server 12 may be configured to allow the user 31 , conveniently via device 30, to modify or add to his/her identity data.

In preferred embodiments, the user transaction server 12 is configured to provide a personal cloud service for the respective user (the user 31 of user device 30 in this example) that is responsible for providing data indicating one or more aspects of his/her identity to the provider transaction server 14 associated with a requesting identity verifier, or authenticator. The identity data may be stored in the storage device 20. In the illustrated example, the identity verifier/authenticator is represented by the user 41 of the provider device 40. The provision of identity data may be in accordance a self sovereign identity model supported by the system 10.

In preferred embodiments, the provider transaction server 14 provides an identity verification cloud service for the user 41 via the provider device 40. The provider transaction server 14 is configured to communicate with the user transaction server 12 and to request information relating to the respective user 31 . In this embodiment the requested information relates to the user’s 31 identity. In preferred embodiments, the provider transaction server 14 requests one or more identity details of the user 31 as required by the application, e.g. any one or more of the user’s name, age or address. Advantageously the identity information may be used by the provider transaction server 14 to authenticate the user 31.

Optionally, the system 10 includes an authority service computing system 48 which may comprise at least one computer executing, in use, at least one computer program configured to cause the authority service computing system 48 to provide one or more authority service. The hardware and software components of the authority service computing system 48, and their configuration, may take any suitable conventional form as required by the application. In preferred embodiments, the authority service computing system 48 is a cloud computing system configured to provide one or more cloud services to other computing devices or systems via a cloud computing network (typically comprising the internet). The authority service computing system 48 may conveniently be referred to as authority server 48. In preferred embodiments, the authority server 48 is operated by a trusted entity, e.g. a regulatory or governmental body, and provides an authority service that involves approving and/or regulating the services provided by the user transaction server 12 and provider transaction server 14 in accordance with any applicable security, privacy and/or other regulations.

An exemplary operation of the identity verification system 10 is now described in the context of an identity verification transaction. In this example, it is assumed that the user 31 , using the user device 30, engages in an identity verification transaction facilitated by the user 41 using the provider device 40. The transaction involves proving at least an aspect of his digital identity to the user 41 via the system 10. In this context, the user transaction server 12 may be described as a digital identity server, the provider transaction server 14 may be described as an identity authenticator server 14, the user 41 may be described as an identity verifier, and the provider device 40 may be described as a verifier’s device.

When the user 31 , carrying user device 30, is close enough to the verifier’s station, which is equipped with the verifier’s device 40, so that the devices 30, 40 can interact wirelessly via communication link 1 , the transaction program 32 on the user device 30 interacts with the corresponding program 42 supported by the verifier’s device 40 to exchange the respective addresses of the respective servers 12, 14. The exchange of transaction identifiers (which typically includes the respective server address) is preferably performed automatically, i.e. without requiring user input. The preferred arrangement is such that only one user device at a time can be close enough to the verifier’s device 40 so that only one user 31 is serviced at a time.

The verifier’s device 40, conveniently under control of the program 42, sends the transaction identifier (including server address) for the user’s identity server 12 to its authentication server 14, thereby delegating the identity authentication process to its authenticator server 14, which is in the cloud in preferred embodiments.

The authenticator server 14 connects to the user’s identity server 12 using the address provided by the verifier’s device 40 and requests identity information relating to the user 31. Preferably, a mutual authentication process is performed by the servers 12, 14, which may involve mutual verification using the respective address provided to each server 12, 14 for the other server 14, 12 by the respective device 30, 40. The mutual authentication process is preferably performed before the authenticator server 14 requests the identity information or at least before any identity information is provided by the identity server 12 to the authenticator server 14.

In response to a request for information from the authenticator server 14, the identity server 12 communicates with the user device 30, conveniently via the program 32, in order to obtain verification that the transaction can proceed. In preferred embodiments, the identity server 12 communicates with the user device 30 to authenticate the user 31 using an implicit authentication method based on his/her usage behaviour, and/or an explicit authentication method. If authentication is successful, then the program 32 may prompt the user 31 , via message 52 in this example, to provide user input approving or denying the transaction, which in this case involves the identity server 12 presenting the requested identity-related information to the authenticator server 14.

Once the authentication and/or approval, as applicable, has been obtained, the identity server 12 communicates the relevant identity information to the authenticator server 14. The identity server 12 may also be configured to learn to approve such future authentications without the user’s consent. Advantageously, the user 31 has full configurational control over his/her digital identity service as supported by server 12 in that the user 31 can control which part(s) of his/her digital identity can be communicated to an authenticator service supported by the authenticator server 14. To this end, the user 31 may be able to configure, conveniently via the user device 30, one or more settings supported by the digital identity service that determine what identity related information may be made available to authenticator servers 14. In preferred embodiments, however, the user 31 cannot cause the identity server 12 to present false identity-related information to the requesting authenticator server 14. To this end, in preferred embodiments, the authority server 48 is configured to control setting up the digital identity service for the user 31. The authority server 48 has control over the system 10 to ensure that all of the user’s identity-related information is verified and is correct. Any update in this information, e.g. the user’s address, has to be first approved by the authority operating the authority server 48. Inter-authority trust can be established to trust a digital identity provided by an identity service supported by the server 12 approved by a different authority, allowing the user 31 to take his/her self-sovereign digital identity along with him/her while interacting with different authorities.

Advantageously, the authority server 48 may be configured to govern the authenticator servers 14 to conform with either or both of the following rules:

1 - No authenticator server 14 can request to know any part of the identity-related information when it is not permitted to know. For example, an authenticator server 14 cannot ask the user’s identity server 12 about the user’s address if it is not in advance permitted to know (i.e. one or more parameters relating to the identity transaction are pre-defined). Although the user transaction server 12 may obtain authentication and/or approval from the user 31 before releasing any part of the identity-related information to the authenticator server 14, the user 31 may be unaware of any rules and regulations that the organisation associated with the authenticator server 14 is bound by. Having this information predetermined and governed by the authority server 48 helps to prevent the user server 12 providing and/or the user 31 authorising the provision of identity information that is not required.

2- Authenticator servers 14 have to comply with any relevant regulations while dealing with the user’s identity-related information to ensure that no breaches of confidentiality occur.

In this example the system 10 supports a “hands-free” way for the user 31 to present his/her identity using well-established communication technologies, e.g. Bluetooth or NFC. The user 31 does not need to present any sort of handheld ID to the verifier 41. Advantageously, the verifier’s station may be designed in such a way that only one user at a time can be close enough to its Bluetooth (or other wireless) to initiate a transaction. Alternatively, or in addition, an array of Bluetooth/wireless beacons may be provided in the vicinity of the provider device 40 to avoid any confusion with multiple possible users.

Preferably, each authenticator server 14 obtains an electronic certificate from the trusted authority server 48 that identifies which identity-related information it may ask for in order in respect of any give transaction that it supports, and/or may certify the identity of the authenticator 14. The certificate may be provided to the user’s identity server 12, e.g. as part of the initial communication between the servers 12, 14 in relation to the transaction to allow the identity server 12 determine which aspect(s) of the user’s identity information that the authenticator server is allowed to request. This allows the identity server 12 to inform the user device 30, and therefore the user 31 , what identity information has been legitimately requested when seeking approval of the transaction.

Preferred systems embodying the invention employ a decentralized server architecture, which is preferably implemented using cloud computing. Preferred systems exhibit good scalability as they are not dependent on a common centralised server, instead providing respective, autonomous, personalised cloud-based services for the users. Advantageously, at least some aspects of the system’s operation, in particular user authentication, may be performed “hands-free”, i.e. without direct user input, allowing the authentication process to be more seamless. The preferred digital identity transaction system 10 for supporting a cloud-based self-sovereign identity service comprises:

(a) A personal identity transaction service for each user (provided by server 12 in this example), storing securely the respective user’s identity related data. The personal identity transaction service 12 is responsible for authenticating the user explicitly, e.g. requesting him/her to provide biometric input to the user device 30, or implicitly by monitoring and tracking the user’s behaviour for enabling continuous (implicit) authentication.

(b) An independent authenticator service (provided by server 14 in this example) that can communicate with the user’s personal service 12 and have the user authenticated as described.

(c) Optionally, an independent trusted authority service (provided by server 48 in this example) that is responsible for verifying and certifying genuine authenticators and personal services.

In preferred embodiments, the authenticator server 14 does not hold any personal identity information about the user 31 in its database. Authenticator servers 14 are only allowed to store the user’s personal service address and it is only the user who can grant them access to his/her data just at authentication times. The preferred system offers several advantages including: single point to update; seamless user controllability; smooth approach of granting the right to be forgotten; no single point of disclosure; user-advisability; and support anti-collusion.

In other embodiments, the transaction system 10 is configured to serve as a payment system. In such embodiments, the system 10 supports the provision of a payment service in which the supported transactions comprise payment transactions. In preferred embodiments, the user transaction server(s) 12 and provider transaction server(s) 14 are implemented using any convenient conventional cloud computing technologies in order to provide a cloud-based payment service to the user device(s) 30 and provider device(s) 40.

In preferred embodiments, the user transaction server 12 is configured to provide a personal cloud service for the respective user (the user 31 of user device 30 in this example) that is responsible for providing payment data (e.g. bank account details) to the provider transaction server 14 associated with a merchant. In the illustrated example, the merchant is represented by the user 41 of the provider device 40. Payment data for the user 31 may be stored by the server 12, conveniently in storage device 20, and the server 12 may support maintenance of the data by the user 31 , e.g. via device 30, as required.

In preferred embodiments, the provider transaction server 14 provides a payment cloud service for the user 41 via the provider device 40. The provider transaction server 14 is configured to communicate with the user transaction server 12 and to request information relating to the respective user 31 . In this embodiment the requested information relates to the user’s 31 payment means, e.g. bank account details. In preferred embodiments, the provider transaction server 14 requests payment related data for the user 31 as required by the application. The payment information may be used by the provider transaction server 14 to perform a payment transaction between the user 31 and the merchant.

An exemplary operation of the payment transaction system 10 is now described in the context of a payment transaction. In this example, it is assumed that the user 31 (or customer), using the user device 30, engages in a payment transaction facilitated by the user 41 (or merchant) using the provider device 40. The transaction involves providing payment data of the user 31 to the user 41 via the system 10. In this context, the user transaction server 12 may be described as a customer payment server, the provider transaction server 14 may be described as a merchant payment server 14. The user 41 may be described as a merchant and the provider device 40 may be described as a merchant’s payment device.

When the user 31 , carrying user device 30, is close enough to the merchant’s station, which is equipped with the merchant’s device 40, so that the devices 30, 40 can interact wirelessly via communication link 1 , the transaction program 32 on the user device 30 interacts with the corresponding program 42 supported by the merchant’s device 40 to exchange the respective addresses of the respective servers 12, 14. The exchange of transaction identifiers (which typically includes the respective server address) is preferably performed automatically, i.e. without requiring user input. The preferred arrangement is such that only one user device at a time can be close enough to the merchant’s device 40 so that only one user 31 is serviced at a time.

The merchant’s device 40, conveniently under control of the program 42, sends the transaction identifier (including server address) for the user’s payment server 12 to its payment server 14, thereby delegating the payment process to its authenticator server 14, which is in the cloud in preferred embodiments.

The authenticator server 14 connects to the user’s payment server 12 using the address provided by the merchant’s device 40 and requests payment information relating to the user 31 . Preferably, a mutual authentication process is performed by the servers 12, 14, which may involve mutual verification using the respective address provided to each server 12, 14 for the other server 14, 12 by the respective device 30, 40. The mutual authentication process is preferably performed before the authenticator server 14 requests the payment information or at least before any payment information is provided by the customer payment server 12 to the merchant server 14.

In response to a request for information from the merchant server 14, the customer payment server 12 communicates with the user device 30, conveniently via the program 32, in order to obtain verification that the transaction can proceed. In preferred embodiments, the customer payment server 12 communicates with the user device 30 to authenticate the user 31 using an implicit authentication method based on his/her usage behaviour, and/or an explicit authentication method. If authentication is successful, then the program 32 may prompt the user 31 , via message 52 in this example, to provide user input approving or denying the transaction, which in this case involves the payment server 12 presenting the requested payment-related information to the merchant server 14. It is noted that in Figure 1 the text of the message 52 is exemplary only and, in the present embodiment the message 52 may for example alternatively be “Merchant X wishes to receive your payment details. Is that OK?”.

Once the authentication and/or approval, as applicable, has been obtained, the customer payment server 12 communicates the relevant payment information to the merchant server 14. The payment server 12 may also be configured to learn to approve such future authentications without the user’s consent.

Advantageously, the user 31 has full configurational control over his/her payment service as supported by server 12 in that the user 31 can control which payment details can be communicated to an merchant service supported by the merchant server 14. To this end, the user 31 may be able to configure, conveniently via the user device 30, one or more settings supported by the payment service that determine what payment related information may be made available to merchant servers 14.

In this example the system 10 supports a “hands-free” way for the user 31 to provide payment electronically using well-established communication technologies, e.g. Bluetooth or NFC. Advantageously, the merchant’s station may be designed in such a way that only one user at a time can be close enough to its Bluetooth (or other wireless) to initiate a transaction. Alternatively, or in addition, an array of Bluetooth/wireless beacons may be provided in the vicinity of the provider device 40 to avoid any confusion with multiple possible users.

In preferred embodiments, the system 10 advantageously allows user 31 to transact, e.g. shop, online without disclosing his/her address to merchant 41 who may be located anywhere in the world. Instead, the personal service provided by the respective user transaction server 12 of the user 31 is configured to provide to the merchant service supported by the respective merchant server 14 of merchant 41 a service address ID for the user 31 . An authorised third party server (not shown), for example a server of a postal or courier service, may request real world (physical) address information from the user’s 31 transaction server 12 using the service address ID, which the authorised third party may then use to send, e.g. via a postal or courier service, the item(s) that have been purchased to the user 31 . Preferably, in response to a request for real world postal address information the transaction server 12 is configured to provide only a partial address, e.g. identification of the country, or other general location, to which the item(s) is to be delivered if the requesting third party is identified as being outside of said country or other general location, and to provide a full address, i.e. identifying a specific physical location for receiving post, if the requesting third party is identified as being within the country or other general location. Preferably, the user transaction server 12 contacts the user 31 to seek approval to provide address information and only does so in response to receiving such approval from the user 31 . For example, it is assumed that user 31 with a postal address in one country purchases an item online from merchant 41 located in another country. The merchant 41 only receives the user's personal service address ID, which he/she submits it to a postal service that is local to the merchant 41. The merchant's local postal service contacts the user’s personal service (transaction server 12) to obtain an address to which the item is to be delivered. The user's personal service (transaction server 12) notifies the user 12 about the postal service’s request and seeks approval. If approval is obtained, the merchant's local postal service is able to access the user's country of residence/delivery. The item may then be delivered to the user's home postal service in his/her home country. The user's local postal service contacts the user's personal service (transaction server 12) to get his/her full address. The user's personal service (transaction server 12) notifies the user about the local postal service request and seeks approval. If approval is obtained, the local postal service is able to access the user's full address in order to deliver the item. Advantageously, the user 31 is able to set his/her personal service to remember his/her access decisions for every postal service to avoid further notifications.

Preferred systems embodying the invention employ a decentralized server architecture, which is preferably implemented using cloud computing. Preferred systems exhibit good scalability as they are not dependent on a common centralised server, instead providing respective, autonomous, personalised cloud-based services for the users. Advantageously, at least some aspects of the system’s operation, in particular user authentication, may be performed “hands-free”, i.e. without direct user input, allowing the authentication process to be more seamless.

It will be understood that methods embodying the invention may be implemented in software, firmware, hardware, or a combination thereof. In one mode, the method is implemented in software, as one or more executable program, and is executed by one or more special or general purpose digital computer(s), such as a personal computer (PC; IBM-compatible, Apple-compatible, or otherwise), mobile computing device, smart phone, personal digital assistant, workstation, minicomputer, or mainframe computer. The steps of the method may be implemented by a server or computer in which the software modules reside or partially reside. In particular, each of the devices 30, 40 and servers 12, 14 may comprise one or more suitably configured computer programs for performing the tasks and methods described herein, and may include or have access to one or more data storage device for storing any necessary data.

Generally, in terms of hardware architecture, such a computer will include, as will be well understood by the person skilled in the art, a processor, memory, and one or more input and/or output (I/O) devices (or peripherals) that are communicatively coupled via a local interface. The local interface can be, for example, but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface may have additional elements, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications. Further, the local interface may include address, control, and/or data connections to enable appropriate communications among the other computer components.

The processor(s) may be programmed to perform the functions of the method as described above. The processor(s) is a hardware device for executing software, particularly software stored in memory. Processor(s) can be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with a computer, a semiconductor based microprocessor (in the form of a microchip or chip set), a macroprocessor, or generally any device for executing software instructions.

Memory is associated with processor(s) and can include any one or a combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and non-volatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.). Moreover, memory may incorporate electronic, magnetic, optical, and/or other types of storage media. Memory can have a distributed architecture where various components are situated remote from one another, but are still accessed by processor(s). The software in memory may include one or more separate programs.

The separate programs comprise ordered listings of executable instructions for implementing logical functions in order to implement the functions of the modules. In the example of heretofore described, the software in memory includes the one or more components of the method and is executable on a suitable operating system (O/S).

The present teaching may include components provided as a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When a source program, the program needs to be translated via a compiler, assembler, interpreter, or the like, which may or may not be included within the memory, so as to operate properly in connection with the O/S. Furthermore, a methodology implemented according to the teaching may be expressed as (a) an object oriented programming language, which has classes of data and methods, or (b) a procedural programming language, which has routines, subroutines, and/or functions, for example but not limited to, C, C++, Pascal, Basic, Fortran, Cobol, Perl, Java, and Ada.

When the method is implemented in software, it should be noted that such software can be stored on any computer readable medium for use by or in connection with any computer related system or method. In the context of this teaching, a computer readable medium is an electronic, magnetic, optical, or other physical device or means that can contain or store a computer program for use by or in connection with a computer related system or method. Such an arrangement can be embodied in any computer readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a "computer-readable medium" can be any means that can store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. Any process descriptions or blocks in the Figures, should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process, as would be understood by those having ordinary skill in the art.

The invention is not limited to the embodiment(s) described herein but can be amended or modified without departing from the scope of the present invention.

Claims

1. A computer-implemented transaction system comprising: at least one user transaction server at least one provider transaction server; at least one user computing device; and at least one provider computing device, wherein said at least one user computing device and said at least one user transaction server are enabled for communication with each other across a telecommunications network, said at least one provider computing device and said at least one provider transaction server are enabled for communication with each other across a telecommunications network, said at least one user transaction server and said at least one provider transaction server are enabled for communication with each other across a telecommunications network, and said at least one user computing device and said at least one provider computing device are enabled for communication with each other by wireless communication, and wherein in order to perform a transaction involving a respective user computing device and a respective provider computing device, the user computing device is configured to wirelessly transmit a respective transaction service identifier to said provider computing device, and said provider computing device is configured to send said transaction service identifier to a respective provider transaction server via said telecommunications network, and wherein said respective provider transaction server is configured to communicate via said telecommunications network with a respective user transaction server identified by said transaction service identifier, and to request that at least a part of said transaction is performed between the respective user transaction server and provider transaction server, and wherein, in response to said transaction request, said respective user transaction server is configured to communicate with the respective user computing device via said telecommunications network and to authenticate usage of said respective user computing device, and wherein said respective user transaction server is configured to perform said at least a part of said transaction if said usage of said respective user computing device is authenticated.

2. The transaction system of claim 1 , wherein said respective user transaction server is configured to authenticate said usage by implicit authentication means based on monitored usage of the respective user computing device.

3. The transaction system of claim 1 or 2, wherein said user computing device is configured to monitor at least one aspect of usage of the user computing device, and to authenticate usage of said user computing device based on the monitored usage.

4. The transaction system of claim 3, wherein said user computing device is configured to provide an authentication indication to said user transaction server based on the monitored usage.

5. The system of claim 3 or 4, wherein said user computing device is configured to authenticate usage by comparing usage data representing said monitored usage with reference usage data that represents genuine user usage, and to determine, based on the comparison, if the actual usage data matches the genuine usage data.

6. The system of any one of claims 3 to 5, wherein said at least one aspect of usage comprises any one or more of: incoming and/or outgoing messages; incoming and/or outgoing calls; browser history; WIFI history; application usage patterns; location history; accelerometer and/or other sensor measurements.

7. The system of any preceding claim, wherein said respective user transaction server is configured to authenticate said usage by explicit authentication means based on user input received by the respective user computing device.

8. The system of claim 7, wherein said user computing device includes at least one biometric sensor and is configured to authenticate usage of said user computing device based on user input detected by said at least one biometric sensor.

9. The system of claim 8, wherein said user computing device is configured to provide an authentication indication to said user transaction server based on the user input detected by said at least one biometric sensor.

10. The system of any one of claims 7 to 9 when dependent on any one of claims 2 to 6, wherein said respective user transaction server is configured to authenticate said usage by explicit authentication means in response to failure of said implicit authentication means.

11. The system of any preceding claim, wherein the user computing device is operable to request explicit user input to approve the transaction.

12. The system of claim 11 , wherein said user computing device is configured to receive said explicit user input by means of any one or more user input device included in the user computing device.

13. The system of claim 11 or 12, wherein the user computing device is operable to request said explicit user input after usage of said respective user computing device is determined to be authentic.

14. The system of any preceding claim, wherein the provider computing device is configured to wirelessly transmit a respective transaction service identifier to said user computing device, and said user computing device is configured to send said transaction service identifier to the respective user transaction server via said telecommunications network.

15. The system of claim 14, wherein said user transaction server and said provider transaction server are configured to perform a mutual authentication process using the respective transaction service identifiers provided by the user computing device and the provider computing device.

16. An identity verification system comprising a computer-implemented transaction system as claimed in any preceding claim, wherein said at least one user transaction server includes or is in communication with at least one storage device for storing respective user identity data for each user of the system, and wherein said at least a part of said transaction involves transmitting at least part of the respective identity data of a respective user to said provider transaction server.

17. The system of claim 16, wherein said provider transaction server is configured to identify said at least part of the respective identity data when requesting that said at least a part of said transaction is performed between the respective user transaction server and provider transaction server.

18. The system of claim 16 or 17 when dependent on claim 11 , wherein said user transaction server is configured to render to the user a notification identifying said at least part of the respective identity data when requesting approval of the transaction.

19. The system of any one of claims 16 to 18, wherein said at least one user transaction server is configurable to allow control of which part or parts of said user identity data are available for communication to said provider transaction server.

20. The system of any one of claims 16 to 19, further including an authority service computing system in communication with said at least one user transaction server and/or said at least one provider transaction server across a telecommunications network, and wherein said authority service computing system is configured to verify said user identity data and/or to control which part or parts of said identity data are available for communication to said provider transaction server.

21. A payment system comprising a transaction system as claimed in any one of claims 1 to 15, wherein said at least one user transaction server includes or is in communication with at least one storage device for storing respective payment data for each user of the system, and wherein said at least a part of said transaction involves transmitting at least part of the respective payment data of a respective user to said provider transaction server.