Patent Description:
Further embodiments of the invention relate to a computer method and system for securely granting access to analyzed data via the internet.

Providing or transferring information, for example information of analyzed data, can happen in distinct ways, for example the traditional way via print-out reports. This way, it is easy to guarantee that a) the recipient receives the message in appropriate time, with appropriate security features and with the appropriate convenience. Most often, a classical mail delivery system utilizing registered mail is used to fulfill such requirements. As an example, the registered letter of notary or analysis reports/ diagnostic results are sent to the customer/ patient.

However, the other way information is today transferred around the world is by utilizing the world wide web/ the internet. Here, a lot of convenience comes into play. By using the internet, or in general a digital communication network, one can give and/or create access to information fast, easy and independent of the requester location to almost everyone immediately. By using a worldwide network of servers the internet allows to send all kind of information to a client. Today, the internet is used in unlimited ways, like social networking, processing financial transactions or controlling industrial appliances. With rising penetration in all areas, security is getting a great concern. Most people already have access to the internet and are available via several ways. One of them is e-mail. The e-mail as an "everywhere" available feature of information exchange is, without a doubt, the most often used way to exchange all sorts of information, from documents, to videos, pictures and so on. Today, the wide availability of the smartphone makes it possible to almost always and everywhere check for new information regarding oneself or processes surrounding oneself. However, especially in the healthcare sector, this information is most often of such valuable and private nature that an e-mail, and most other information sharing products like instant messenger, picture/photo or video sharing platforms or even document exchange software is not appropriate for such kind of information.

Huge efforts have been made in the last couple of years to create secure and still highly convenient places to store information, even critical and private information, in the cloud. Securing data at rest, i.e. while not in transit, is mostly a question of what encryption algorithm is used. This also holds true for data which is persisted on some kind of computer hardware. However, most often, even today, the process of authentication of some user credentials is not very secure. Again, hashing passwords in a database (as this database is persisted on some computer hardware) is a rather secure way to hold this information. In the process of logging-in (checking credentials) and retrieving data, especially healthcare data, additional, subsequent checks of permissions are needed to assure the user that only people with appropriate permissions get access to the analyzed data.

In IT-Systems design there is a constant assessment of security vs. convenience. Many, if not all, people want their private data (especially healthcare data) to be secure and safe, wherever it is stored. However, to use such data it is granted that to access the data one needs to have the most convenient and yet most secure way of accessing it.

Accessing sensitive information, like personal data, via internet requires a secure transport channel as well as a secure authentication mechanism. The actual gold standard is authentication via username and password, which relies heavily on the strength of the used password. While weak passwords are easy to guess, strong passwords are hard to remember. In addition to that the username often consists of a part of or even the whole name of the person who wants to authenticate himself. In most scenarios the authenticator is the person the data belongs to. However, especially in the healthcare setting - which is becoming more and more digitized - the requester of personal data of an individual is a service provider. This might, in the healthcare setting, be a physician, clinician or laboratory service provider. While, as described, transit of data is most often securely done, the information regarding the individual requesting certain (health) data is not protected because login credentials (i.e. username and password) are submitted and transferred. Thus, the identity of such an individual is traceable because besides login credentials also the actual geo-location (via ip address) is traceable. This leads to a vulnerability also for the individual the data is about. Another problem in accessing information via the internet is the identification of that information. For example requesting detailed information about a certain product may result in different information about a different product.

<CIT> describes a method and system for providing authorization to a customer to access content on a network, according to which a network access provider providing network access to the customer provides verification of the identity of the customer to a content provider. The content provider then determines whether that customer is authorized to access the content and, if so, provides the customer with Such access. Therefore, content access based on the identity of the customer is provided, rather than on the identity of a device the customer uses to access the content. In that way, the customer is not restricted to accessing the content through an authorized device.

<CIT> describes systems and methods of delegating authorization to access isolated collections of data. In aspects , a request to access an isolated collection of resource identifiers and relationships may be received by an application. The resource identifiers may correspond to resources in one or more remote data repositories. Upon receiving the request , the application may interrogate a remote data repository to determine whether the requestor is currently authorized to access the one or more resources corresponding to the resource identifiers in the isolated collection. If the requestor is determined to be authorized , the application may use an authorization indication provided by the remote data repository to provide the requestor with access to the isolated collection. If the requestor is determined to be unauthorized, the application may prohibit access to the isolated collection.

It is an object of embodiments of the invention to provide a concept for transferring information, the concept providing an improved tradeoff between user convenience and data security of both, the transferred information and information about the user.

Embodiments according to the present application will subsequently be described taking reference to the enclosed figures, in which:.

In the following, different inventive embodiments and aspects will be described. Also, further embodiments will be defined by the enclosed claims.

It should be noted that any embodiments as defined by the claims can be supplemented by any of the details (features and functionalities) described herein. Also, the embodiments described herein can be used individually, and can also optionally be supplemented by any of the details (features and functionalities) included in the claims. Also, it should be noted that individual aspects described herein can be used individually or in combination. Thus, details can be added to each of said individual aspects without adding details to another one of said aspects. It should also be noted that the present disclosure describes explicitly or implicitly features usable for transferring, providing, retrieving, requesting or receiving information.

The invention will be understood more fully from the detailed description given below and from the accompanying drawings of embodiments of the invention, which, however, should not be taken to limit the invention to the specific embodiments described, but are for explanation and understanding only.

In the figures, elements drawn in dashed lines are shown to support a better understanding, but these elements are not necessarily part of the shown embodiment.

<FIG> shows a schematic representation of a server <NUM> according to an embodiment. The server <NUM> is configured for providing one or more data sets via a digital communication network <NUM>. Further, the server <NUM> is configured for associating an unique identifier <NUM> with an identified data set <NUM>, which may be part of the one or more data sets. The unique identifier <NUM> represents a network address for accessing the identified data set <NUM> via the digital communication network <NUM>, wherein the unique identifier <NUM> is specific to the identified data set <NUM>. The server <NUM> is further configured for validating an authentication information <NUM> provided by an authenticator <NUM> of a client <NUM> requesting access to the server <NUM> via the unique identifier <NUM>. The server is configured for selectively providing the client <NUM> with an access right <NUM> to one or more data sets, if the authentication information <NUM> identifies the authenticator as being associated with a registered user.

According to an embodiment, the server <NUM> is configured for validating the authentication information <NUM> provided by the authenticator <NUM> of the client <NUM> requesting access to the identified data set <NUM> via the unique identifier <NUM>. Thus, the server may configured for handling an request for accessing a specific data set of the one or more data sets, for example the data set <NUM>. Additionally, the server <NUM> may be configured for selectively providing the client <NUM> with an access right <NUM> for the identified data set <NUM>, wherein the access right <NUM> for the identified data set is specific to the registered user associated with the authenticator. Thus, the server may provide the client <NUM> with different access rights depending on an identity of the authenticator <NUM>, with which the client <NUM> authenticates against the server by sending the authentication information <NUM>, wherein the identity of the authenticator <NUM> is associated with the registered user.

According to an alternative embodiment, the server <NUM> is configured for providing a data set <NUM>, also designated or referred to as identified data set <NUM>, via a digital communication network <NUM>. Further, the server <NUM> is configured for associating an unique identifier <NUM> with the data set <NUM>, the unique identifier <NUM> representing a network address for accessing the data set <NUM> via the digital communication network <NUM>, wherein the unique identifier <NUM> is specific to the data set <NUM>. The server <NUM> is further configured for validating an authentication information <NUM> provided by an authenticator <NUM> of a client <NUM> requesting access to the data set <NUM> via the unique identifier <NUM>. According to this embodiment, The server <NUM> is further configured for selectively providing the client <NUM> with an access right <NUM> for the data set <NUM>, the access right <NUM> being specific to a registered user that is associated with the authenticator <NUM>.

Further details of the server <NUM> are described in the context of further embodiments according to the following figures. In particular, for the sake of clarity, further details of the server <NUM> are described in the context of an interplay between a server and a device for obtaining a data set. It should be noted that the embodiments of the server can optionally be supplemented by any of the features, functionalities and details described herein with respect to the other embodiments, both individually and taken in combination.

<FIG> shows a schematic representation of an embodiment of a device <NUM> for obtaining a data set <NUM> via a digital communication network <NUM>. The data set <NUM> may be similar to the data set <NUM> or the identified data set <NUM> and may be provided by a server <NUM>, for example the server <NUM>. The device <NUM> is configured for obtaining an unique identifier <NUM> of the data set <NUM>, the unique identifier <NUM> representing a network address for accessing the data set <NUM> via the digital communication network <NUM>, wherein the unique identifier <NUM> is specific to the data set <NUM>. For example, the unique identifier <NUM> may be provided by the server <NUM>. The device <NUM> comprises a client <NUM> which may be similar to the client <NUM>. For example, the client <NUM> may be an internet browser or a file browser or another unit configured for communicating with the digital communication network <NUM>. The client <NUM> is configured for using the unique identifier <NUM> for sending a request <NUM> for accessing the data set <NUM> to a server <NUM> providing the data set <NUM>. The client <NUM> is further configured for providing the server <NUM> with an authentication information <NUM> of an authenticator <NUM> for authenticating the client <NUM> against the server <NUM>, wherein the authenticator <NUM> is associated with a registered user. For example, the authenticator <NUM> and the authentication information <NUM> may be similar to the authenticator <NUM> and the authentication information <NUM>, respectively.

Further details of the device <NUM> are described in the context of further embodiments according to the following figures. In particular, for the sake of clarity, further details of the device <NUM> are described in the context of an interplay between a server and a device for obtaining a data set. It should be noted that the embodiments of the device <NUM> can optionally be supplemented by any of the features, functionalities and details described herein with respect to the other embodiments, both individually and taken in combination.

<FIG> schematically illustrates an interplay between a sever <NUM>, which may be similar to the server <NUM>;<NUM>, and a device <NUM> for obtaining a data set, which may be similar to the device <NUM>;<NUM>. The server <NUM> and the device <NUM> may communicate via the digital communication network <NUM>, for example the internet. The server <NUM> may provide one or more data sets including the data set <NUM>, for example the server <NUM> may host the one or more data sets or the server <NUM> may be capable of providing access to one or more data sets hosted elsewhere. The server is configured for associating the data set <NUM> with an unique identifier <NUM>, for example the unique identifier <NUM>;<NUM>. The unique identifier <NUM> represents a network address which may allow for specifically addressing the data set <NUM><NUM> when accessing the server via the digital communication network <NUM>. For example, a user intending to retrieve the data set <NUM> may use the device <NUM> for specifically requesting the data set <NUM> by calling the unique identifier <NUM> using the client <NUM> of the device <NUM>, thus sending a request <NUM> to the server <NUM> for accessing the data set <NUM>.

For example, the unique identifier <NUM> may comprise a network address of the server <NUM> and an unique data set identifier which uniquely identifies the data set <NUM> within an entity of information or data sets provided by the server <NUM>. The unique data set identifier may also be globally unique within an specific entity of identifiers. The unique identifier <NUM> may further comprise an information about a syntax or a type or a scheme for the unique data set identifier. Additionally, the unique identifier <NUM> may comprise an information about a syntax of the unique identifier <NUM>.

According to an embodiment, the unique identifier <NUM> is represented by a uniform resource identifier (URI). In other words, the requested data, e.g. the data set <NUM>, is identified by using a specially constructed URI. The URI consist of four parts, the SCHEME, the BASEURL, the IDENTIFIERTYPE, and the IDENTIFIER itself. The SCHEME is defined by IETF in RFC <NUM> [<NUM>]. The BASEURL is the domain name of the server which will receive the user request e.g. example. com [<NUM>]. The IDENTIFIERTYPE defines the type of the following identifier, ideally an international standard like GS1 GDTI (for documents), but could also be any internally defined identifier type or a similar technological approach. After the identifier type follows the IDENTIFIER itself, consisting of a unique string representing the link to the analyzed data. The IDENTIFIER must be system inherent or in combination with IDENTIFIERTYPE global unique string. Combining all parts a possible valid URI could be:
https://example. com/gdti/408980809ADHJKCGGHBKN.

For example, it may be important that the identifier is a unique string for every data object requested. A possible way to ensure the uniqueness of this identifier, for example the unique identifier <NUM>, is to relay on international standards like the ones from GS1 which are also mentioned in the EU Medical Device Regulation (MDR) and the In-vitro Diagnostic Regulation (IVDR). By using a the above described URI format, a data object, for example the data set <NUM>, may be uniquely identified and made accessible.

The client <NUM> may be similar to the client <NUM>;<NUM>. For example, the client <NUM> may comprise or be part of an internet browser or a file browser or another unit for navigating in a digital communication network which may, for example be utilized by a user for accessing the server <NUM> or one of the data sets hosted by the server.

The server <NUM> may be configured for selectively granting access to the data set <NUM> and optional additional data sets in dependence on an identity of a user using the client <NUM> for accessing the server <NUM>. For this purpose, the server <NUM> may verify, if the request <NUM> for accessing the data set originates from a registered user, and optionally, the server <NUM> may check the identity of the registered user requesting access to the server.

For authenticating as a registered user, a user may be represented by an authenticator <NUM>. For example, a registered user may simply be represented by a previously registered authenticator <NUM>. The authenticator <NUM> may comprise a cryptographic entity that allows for an unique identification of the authenticator <NUM> within a cryptographic system. For example, the authenticator may comprise a pair of cryptographic keys, for example a private key that is secret to the authenticator and a public key.

According to an embodiment, the server <NUM> is configured for registering the authenticator <NUM> by associating the authenticator <NUM> with an identity information identifying the registered user.

For example, a registered user may register the authenticator <NUM>, so that after the registration, the authenticator <NUM> is associated with the registered user. For example, the server <NUM> may store the public key of the authenticator <NUM> for registering the authenticator <NUM>.

For example, the server <NUM> is configured for using a cryptographic system for validating the authentication information <NUM>, wherein the server <NUM> is configured for associating the authenticator <NUM> with a cryptographic key that is specific to the authenticator <NUM>.

According to an embodiment, a registered user may register one or more authenticators. A possible scheme for registering an authenticator is described in the context of <FIG>.

The client <NUM> may use the authenticator <NUM> associated with the registered user for verifying that a request for accessing the server occurs on behalf of a registered user and/or for verifying the identity of the registered user requesting access to the server. For example, the authentication of the identity of the authenticator <NUM> is based on an exchange of an encrypted message between the server <NUM> and the client <NUM>.

According to an embodiment, the authenticator <NUM> may comprise a cryptographic key, and the authenticator <NUM> may be configured for using the cryptographic key for providing the authentication information <NUM> to the server.

For example, the server <NUM> may send an validation information to the device <NUM>. The device <NUM> may encrypt or sign the validation information by using a secret key of the authenticator <NUM>, for example the private key of the pair of keys, for obtaining the authentication information <NUM>. The client <NUM> may send the authentication information <NUM> to the server <NUM>. The server <NUM> may validate the identity of the authenticator <NUM> by testing if decrypting the authentication information <NUM> using the public key of the authenticator <NUM> results into the validation information as originally sent to the client <NUM> or by using the public key for testing, if the signature of the authentication information was generated by using the private key. As the server may associate the authenticator <NUM> with the registered user, this authentication procedure allows for an authentication of the registered user against the server without transmitting information about the user identity. Thus, the authentication information <NUM> may allow for an anonymized authenticating of the registered user against the server.

Alternatively, the cryptographic system may be symmetric. That is, the server <NUM> comprises a cryptographic key associated to the authenticator <NUM>, wherein the common cryptographic key is secret to the authenticator <NUM> and the server <NUM>, wherein the server <NUM> uses the common cryptographic key for decrypting the authentication information <NUM>, and wherein the authentication information <NUM> is obtained by the device <NUM> by decrypting the validation information by using the common cryptographic key.

In other words, in order to access the requested information, e.g. the data set, the requester may have to authenticate against the system or the server holding this information. For example, the authentication itself may be based on the WebAuthn standard and may require a so called authentication device. Every user of the system may be able to register one or more of these devices, as an alternate method for the classical username-password authentication. By using this kind of authentication, there may be no need to exchange personal data between the client and the server. For example, the only data exchanged is a public key, based on the users authentication device.

The arrangement of the authenticator <NUM> in <FIG> is schematic and exemplary. The device <NUM> or the client <NUM> may comprise the authenticator <NUM>. Thus, the device may, for example, have access to the authenticator at any time of operation.

According to an embodiment, the device <NUM> is configured for having access to the authenticator <NUM> via a digital interface. For example, the authenticator <NUM> may be part of an external device connected to the device <NUM> via the digital interface. Thus, the device <NUM> may only authenticate using the authenticator <NUM>, if the external device is connected to the device <NUM>.

According to an embodiment, the server comprises an access information, the access information associating the registered user with the access right for the data set <NUM>, and optionally with an access right for further data sets.

For example, the access right for the data set <NUM> may comprise specific permissions for the data set <NUM>, for example, a right to receive the data set <NUM> in a specific form, or to download, delete or modify the data set <NUM>. For example, the access right may be defined for a specific user or for specific groups of users or roles. For example, the access information associates the registered user with one or more roles or groups of users.

According to an embodiment, the server <NUM> is configured to provide a client that authenticates with an authenticator associated to any registered user with access to the data set <NUM> and optionally to further data sets, for example all data sets provided by the server <NUM>.

According to an embodiment, the server <NUM> is configured for directing the client <NUM> requesting access to the server <NUM> to the identified data set.

For example, the client <NUM> may access the server <NUM> by using the unique identifier <NUM>. After authentication, the server <NUM> may direct the client <NUM> to the data set <NUM> identified by the unique identifier <NUM>. Optionally, the server <NUM> may provide the client <NUM> with access to further data sets without again demanding for authentication.

According to an embodiment, the device <NUM> comprises an input interface <NUM> for receiving an user input <NUM>, wherein the device <NUM> is configured for selectively providing the authentication information <NUM> to the server in dependence on the user input <NUM>.

For example, the device <NUM> may require a user to actively initiate the request for accessing the data set <NUM>, or to confirm an initiation of the request for accessing the data set <NUM> by the user input <NUM>. For example, the device may allow the client <NUM> to use the authenticator <NUM> only after a user initiated or confirmed the usage via the user input <NUM>. For example, the user input <NUM> may comprise an input via a keyboard, a touch screen, a scanner unit, or a camera.

According to an embodiment, the device <NUM> is configured for obtaining a biometric information about a user, wherein the device <NUM> is configured for selectively providing the authentication information <NUM> to the server <NUM>, if the biometric information identifies the user as being associated with the authenticator <NUM>.

For example, the user input comprises a user's fingerprint or an image of a user's face. The device <NUM> may associate the authenticator <NUM> with the identity of one or more users allowed to use the authenticator <NUM>. For example, the device may allow the client <NUM> to use the authenticator <NUM> only after an associated user initiated or confirmed the usage via the user input <NUM>.

According to an embodiment, the device <NUM> is configured for retrieving the unique identifier <NUM> from a graphical pattern representing the unique identifier <NUM>. For example, the device may receive the unique identifier <NUM> from a scanner unit or a camera capable, which may optionally be part of the device <NUM> or may be an external device.

For example the user input <NUM> may comprise scanning the graphical pattern. For example, a user scanning the graphical pattern may initiate the request for accessing the data set identified by the unique identifier represented by the graphical pattern.

<FIG> shows a flow chart of a method <NUM> for registering an authenticator, for example the authenticator <NUM>;<NUM>;<NUM> according to an embodiment. The authenticator to be registered may be part of a device for obtaining a data set, e. g, the device <NUM>;<NUM>;<NUM>, or may be connected to such a device. For registration, the authenticator may also be connected to another device.

The method <NUM> may be applied for an initial registration of the authenticator. A step <NUM> comprises a login of a user, e.g. a registered user, to a personal administration page using a user name and a password. For example, the administration page may be hosted by the server <NUM>;<NUM>;<NUM>. The administration page may also be hosted on another server that is configured for sharing information about a registered authenticator with the server <NUM>;<NUM>;<NUM>. In another step <NUM>, the user may select the option to register a new authenticator. Subsequently, in step <NUM>, the server asks the user to follow the browser, or an specific App (i.e. a piece of software from something alike the Apple App-Store) instructions. Subsequently, in step <NUM>, the user follows an authenticator specific registration process. In step <NUM>, the server receives and stores a public key information from the authenticator to complete the registration of the authenticator.

For example, the registration of an authentication device, may follow the principles defined by the WebAuthn standard [<NUM>]. After a successful initial login, the user is able to register a new security key/device. A security device can be, according to the WebAuthn specification, either a platform authenticator or a roaming authenticator. The main difference is that a platform authenticator is physically bound to the client device (e.g. smartphone or laptop), while a roaming authenticator (e.g. an USB security key) is removable and can be attached to different client devices. During the registration process the server side component associates the public key, which is provided by the authenticator, with the user information.

<FIG> shows a flow chart of an embodiment of a method <NUM> for providing one or more data sets, for example the data set <NUM>;<NUM>;<NUM> via a digital communication network.

The method <NUM> comprises a step <NUM> of associating an unique identifier <NUM>;<NUM>;<NUM> with an identified data set <NUM>;<NUM>;<NUM>, the unique identifier <NUM>;<NUM>;<NUM> representing a network address for accessing the identified data set <NUM>;<NUM>;<NUM> via the digital communication network <NUM>, wherein the unique identifier <NUM>;<NUM>;<NUM> is specific to the identified data set. A further step <NUM> comprises validating <NUM> an authentication information <NUM>;<NUM>;<NUM> provided by an authenticator <NUM>;<NUM>;<NUM> of a client <NUM>;<NUM>;<NUM> requesting access to one or more data sets via the unique identifier <NUM>;<NUM>;<NUM>. The method <NUM> comprises a further step <NUM> of selectively providing the client <NUM>;<NUM>;<NUM> with an access right to one or more data sets, if the authentication information <NUM>;<NUM>;<NUM> identifies the authenticator <NUM>;<NUM>;<NUM> as being associated with a registered user.

The order of the steps of the method <NUM> as shown in <FIG> is chosen exemplarily. For example, the steps <NUM> and <NUM> may be executed independently from step <NUM>.

<FIG> shows a flow chart of an embodiment of a method <NUM> for obtaining a data set <NUM>;<NUM>;<NUM> via a digital communication network <NUM>.

The method <NUM> comprises a step <NUM> of obtaining an unique identifier <NUM>;<NUM>;<NUM> of the data set <NUM>;<NUM>;<NUM>, the unique identifier <NUM>;<NUM>;<NUM> representing a network address for accessing the data set <NUM>;<NUM>;<NUM> via the digital communication network <NUM>, wherein the unique identifier <NUM>;<NUM>;<NUM> is specific to the data set <NUM>;<NUM>;<NUM>. The method comprises a further step <NUM> of using the unique identifier <NUM>;<NUM>;<NUM> for sending a request for accessing a server <NUM>;<NUM>;<NUM> hosting the data set <NUM>;<NUM>;<NUM>. The further step <NUM> comprises providing the server <NUM>;<NUM>;<NUM> with an authentication information <NUM>;<NUM>;<NUM> of an authenticator <NUM>;<NUM>;<NUM> for authenticating the client <NUM>;<NUM>;<NUM> against the server <NUM>;<NUM>;<NUM>, wherein the authenticator <NUM>;<NUM>;<NUM> is associated with a registered user.

The order of the steps of the method <NUM> as shown in <FIG> is chosen exemplarily. For example, after obtaining <NUM> the unique identifier the steps <NUM> and <NUM> may be executed repeatedly and/or independently from step <NUM>.

<FIG> shows a flow chart of an embodiment of a method <NUM> for transferring a data set between a server and a device for obtaining a data set. For example, the method <NUM> may combine features of the methods <NUM> and <NUM>, which may be executed by the server <NUM>;<NUM>;<NUM> or the device <NUM>;<NUM>;<NUM>.

The method <NUM> comprises an opening <NUM> of an unique URI for an analyzed data item, e.g. the data set <NUM>;<NUM>;<NUM>. For example, the step <NUM> may comprise the step <NUM>. For example, the URI directs to a server, e.g. the server <NUM>;<NUM>;<NUM>. Subsequently, in step <NUM>, the server asks for authentication. In the following step <NUM>, the user authenticates himself via the authenticator, e.g. the authenticator <NUM>;<NUM>;<NUM>. For example, the step <NUM> may comprise the step <NUM>. In step <NUM>, the server decides, if the authentication is successful, for example, if the user authenticates as a registered user or as a registered user authorized to access the requested data set. For example, the step <NUM> may comprise the step <NUM>. If the authentication is successful, step <NUM> is executed, otherwise, step <NUM> is executed. In step <NUM>, the server responds with the analyzed data item. For example, the step <NUM> may comprise the step <NUM>. In step <NUM>, the server denies the access, e.g. to the server or to the data item or data set.

In other words, after the successful registration of an authenticator, e. g the authenticator <NUM>;<NUM>;<NUM> the user is able to access the analyzed data, e.g. the data set <NUM>;<NUM>;<NUM> via the provided URI, e.g. the unique identifier <NUM>;<NUM>;<NUM>, without providing a username or password. When opening the URI, for example by typing in the URI or by scanning a two-dimensional code, the user may have to authenticate himself by using the registered authenticator. The authentication process itself may also follow the principles of a WebAuthn compatible public key authentication mechanism, where the server validates the authentication information by letting the users authenticator cryptographically sign a given message with his private key and send it to the server. After that the server ensures that the transmitted message can be verified with the public key, stored on the server and associated with the user [<NUM>].

According to an embodiment, using this authentication method, there may be no need to transport any personal data to identify the user in order to access the information.

Embodiments of the disclosure relate to a method and system for securely retrieving information about analyzed (healthcare) data via the internet. For example, the information is requested by a client calling a well-formed URI [<NUM>] based on international standards which guarantees a unique one to one relation between the analyzed data and the gathered information about the data. The URI itself may be encoded and presented as a two dimensional code like a QR-code, a GS1 datamatrix or a similar technological approach, which is accessible through handheld as well as stationary devices.

According to an embodiment, in order to retrieve the information the client has to authenticate himself against the server using Public Key Cryptography mechanisms based on the Web Authentication API specification [<NUM>] or a similar technological approach. For example, after receiving the authentication information by the client, the server presents the information in HTML or a structured data format like for example json.

Embodiments of the disclosure relate to a method and system for securely retrieving analyzed (healthcare) data through a convenient and yet safe way.

Embodiments of the disclosure relate to a system for securely granting access to analyzed data via the internet, while keeping the identification of the data item unique and the identity of the requesting party secure.

Embodiments of the presented invention relate to a method, device or system which is able to create pseudonomized access to a remote service system, authenticate the specific user against the remote system using pseudonomyzed data and grant certain access right, i.e. permissions to this user based on roles. The requested data may thereby be uniquely identified in order to prevent false information.

While there has been a lot of progress in securing the transport of information via secure channels, using encrypted transport protocols, the invention of new authentication mechanisms, which are not relying on personal information like a username or an email address, has not been in the focus.

For example, combining a unique URI for object identification, using the WebauthN standard to authenticate a user without relying on personal data and finally presenting the requested information in a structured way, solves the described problems of current solutions in a modular and unique way.

For example, the specific identification of requested detailed information, for example an requested object or a data set, is inevitable, especially in the context of clinical data, containing information about a specific individual.

Depending on certain implementation requirements, embodiments of the invention can be implemented in hardware or in software or at least partially in hardware or at least partially in software.

The data carrier, the digital storage medium or the recorded medium are typically tangible and/or non-transitory.

Claim 1:
Server (<NUM>;<NUM>;<NUM>) for providing one or more data sets via a digital communication network (<NUM>), wherein the server (<NUM>;<NUM>;<NUM>) is configured for :
associating an unique identifier (<NUM>;<NUM>;<NUM>) with an identified data set (<NUM>;<NUM>;<NUM>), the unique identifier (<NUM>;<NUM>;<NUM>) representing a network address for accessing the identified data set (<NUM>;<NUM>;<NUM>) via the digital communication network (<NUM>), wherein the unique identifier (<NUM>;<NUM>;<NUM>) is specific to the identified data set (<NUM>;<NUM>;<NUM>),
validating an authentication information (<NUM>;<NUM>;<NUM>) provided by an authenticator (<NUM>;<NUM>;<NUM>) of a client (<NUM>;<NUM>;<NUM>) requesting access to the server (<NUM>;<NUM>;<NUM>) via the unique identifier (<NUM>;<NUM>;<NUM>), and
selectively providing the client (<NUM>;<NUM>;<NUM>) with an access right for one or more data sets, if the authentication information (<NUM>;<NUM>;<NUM>) identifies the authenticator (<NUM>;<NUM>;<NUM>) as being associated with a registered user.