TECHNICAL FIELD

This disclosure relates to a method, a dataset handling system, a computer program, and a computer program product for de-identifying an original dataset. This disclosure further relates to a method, an application function entity, a computer program, and a computer program product for accessing the original dataset as having been de-identified.

BACKGROUND

In general terms, de-identification is the process used to prevent an identity associated with some dataset from being revealed. For example, data produced during human subject research might be de-identified to preserve the privacy of research participants. When applied to metadata or general data about identification, the process is also known as data anonymization. Common strategies include deleting or masking personal identifiers, such as personal name, and suppressing or generalizing quasi-identifiers, such as date of birth. The reverse process of using de- identified data to identify individuals is known as data re-identification. Deidentification has application in the fields of communications, multimedia, biometrics, big data, cloud computing, data mining, internet, social networks, and audio-video surveillance, just to mention a few.

De-identification algorithms can generally be divided into two classes; nondestructive (or reversible) algorithms and destructive (or irreversible) algorithms. The latter is sometimes referred to as anonymization. For non-destructive algorithms it is possible to at a later stage reveal the identity associated with the dataset. That is, non-destructive algorithms allow information elements of the dataset to be brought back to its original form from the de-identified version. For destructive algorithms, on the other hand, this is impossible.

However, there could be scenarios where some applications require non-destructive algorithms to be used whereas other applications require destructive algorithms to be used. There are currently not any such algorithms available. SUMMARY

An object of embodiments herein is to address the above identified issues.

According to a first aspect there is presented a method for de-identifying an original dataset. The method is performed by a dataset handling system. The method comprises obtaining an original dataset from a customer network. The original dataset is to be de-identified. The method comprises transforming the original dataset to a de-identified dataset by subjecting the original dataset to a destructive data anonymization algorithm. The method comprises encrypting a mapping between the original dataset and the de-identified dataset. The method comprises publishing the de-identified dataset and the encrypted mapping.

According to a second aspect there is presented a dataset handling system for deidentifying an original dataset. The dataset handling system comprises processing circuitry. The processing circuitry is configured to cause the dataset handling system to obtain an original dataset from a customer network. The original dataset is to be de-identified. The processing circuitry is configured to cause the dataset handling system to transform the original dataset to a de-identified dataset by subjecting the original dataset to a destructive data anonymization algorithm. The processing circuitry is configured to cause the dataset handling system to encrypt a mapping between the original dataset and the de-identified dataset. The processing circuitry is configured to cause the dataset handling system to publish the de-identified dataset and the encrypted mapping.

According to a third aspect there is presented a computer program for de-identifying an original dataset, the computer program comprising computer program code which, when run on processing circuitry of a dataset handling system, causes the dataset handling system to perform a method according to the first aspect.

According to a fourth aspect there is presented a method for accessing an original dataset has been de-identified. The method is performed by an application function entity. The application function entity is provided in an application network and has access to a key for decrypting an encrypted mapping between the original dataset and a de-identified dataset. The method comprises retrieving the de-identified dataset and the encrypted mapping. The method comprises decrypting the encrypted mapping using the key for decrypting. The method comprises transforming the deidentified dataset to the original dataset by using the decrypted mapping to map the de-identified dataset to the original dataset, thereby accessing the original dataset.

According to a fifth aspect there is presented an application function entity for accessing an original dataset has been de-identified. The application function entity is provided in an application network and has access to a key for decrypting an encrypted mapping between the original dataset and a de-identified dataset. The application function entity comprises processing circuitry. The processing circuitry is configured to cause the application function entity to retrieve the de-identified dataset and the encrypted mapping. The processing circuitry is configured to cause the application function entity to decrypt the encrypted mapping using the key for decrypting. The processing circuitry is configured to cause the application function entity to transform the de-identified dataset to the original dataset by using the decrypted mapping to map the de-identified dataset to the original dataset, thereby accessing the original dataset.

According to a sixth aspect there is presented a computer program for accessing an original dataset having been de-identified, the computer program comprising computer program code which, when run on processing circuitry of an application function entity, causes the application function entity to perform a method according to the fourth aspect.

According to a seventh aspect there is presented a computer program product comprising a computer program according to at least one of the third aspect and the sixth aspect and a computer readable storage medium on which the computer program is stored. The computer readable storage medium could be a non-transitory computer readable storage medium.

Advantageously, these aspects combine the benefits of non-destructive algorithms and destructive algorithms, where a de-identified dataset only can be restored to its original form by application functions having access to a mapping between the deidentified dataset and the original dataset. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent claims as well as from the drawings.

Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the element, apparatus, component, means, module, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, module, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

The inventive concept is now described, by way of example, with reference to the accompanying drawings, in which:

Fig. 1 is a schematic diagram illustrating a network according to embodiments;

Fig. 2 is a block diagram of a dataset handling system according to embodiments;

Figs. 3 and 4 are flowcharts of methods according to embodiments;

Fig. 5 is a schematic diagram showing functional units of a dataset handling system according to an embodiment;

Fig. 6 is a schematic diagram showing functional modules of a dataset handling system according to an embodiment;

Fig. 7 is a schematic diagram showing functional units of an application function entity according to an embodiment;

Fig. 8 is a schematic diagram showing functional modules of an application function entity according to an embodiment; and

Fig. 9 shows one example of a computer program product comprising computer readable means according to an embodiment. DETAILED DESCRIPTION

The inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the inventive concept are shown. This inventive concept may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Like numbers refer to like elements throughout the description. Any step or feature illustrated by dashed lines should be regarded as optional.

The embodiments disclosed herein relate to techniques for de-identifying an original dataset and accessing the original dataset as having been de-identified. In order to obtain such techniques there is provided a dataset handling system, a method performed by the dataset handling system, a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the dataset handling system, causes the dataset handling system to perform the method. In order to obtain such techniques there is further provided an application function (AF) entity, a method performed by the application function entity, and a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the application function entity, causes the application function entity to perform the method.

Fig. i is a schematic diagram illustrating a network too where embodiments presented herein can be applied. The network too is built on the idea that datasets (DSs) should be collected once and then shared with any authorized AF entity that needs it. The network too can be deployed in customer networks and as a service in application clusters external to customer networks. The network too handles DSs in accordance with customer contracts using automated procedures and provides security mechanisms with controlled access to original DSs and de-identified DSs (D- DSs). The network too comprises a customer network (CN) no and an application network (AN) 120. The CN 110 and the AN 120 are bridged by a DS handling system 200. Further details of the DS handling system 200 will be disclosed below with reference to Fig. 2. With continued reference to Fig. 1, the CN 110 comprises N data sources 130-1, ..., 130-n, ..., 130-N. The data sources 13O-I:13O-N could be any type of entities that exports DSs, such as a node in a telecom network, cloud infrastructure components, a social media site or a weather site. The data sources 13O-I:13O-N might export several types of DSs, such as data pertaining to performance management, fault management or configuration management, as well as logs and/or statistics from nodes in a telecommunication network. The DSs can be exported either by streaming events, files or both. Data export interfaces will in many cases follow established standards but may also be proprietary. The DSs can either be pushed from the data sources 13O-I:13O-N to a data collector or pulled from the data sources 13O-I:13O-N by data collectors. A data source 13O-I:13O-N should allow configuration of data export characteristics, so that it is possible to increase or decrease the data collection frequency, for example. From a security point of view, any exported DSs might be transport encrypted. In general terms, the DSs are to be accessed by applications in application suites 140 in the CN 110 as well as applications in application suites 140 in the AN 120. The application suites in the AN 120 are represented by AF entities 3OO-1:3OOM. In this respect, the AN 120 comprises M AF (AF) entities 300-1, ..., 300-m, ..., 300-M. The AF entities 300- I:300M are to access DSs provided by the data sources 130-1: 130-N. The AF entities 3OO-1:3OOM (as well as applications in the application suite 140) might access DSs for different purposes, such as for training machine learning (ML) or artificial intelligence (Al) models, serviceability, analytics and proactive product support. However, not all AF entities 3OO-1:3OOM might be permitted to access DSs provided by all the data sources 130-1: 130-N. Further, the AF entities 3OO-1:3OOM might only be permitted to access D-DSs. The DS handling system 200 is therefore configured to de-identify the DSs provided by the data sources 130-1: 130-N and also to ensure that the AF entities 3OO-1:3OOM only access (de-identified) DSs to which they have access. How this is enabled will be disclosed below with reference to Fig. 3. In some aspects the AF entities 3OO-1:3OOM are provided in one or more application clusters.

Reference is next made to Fig. 2 which shows an example block diagram of a DS handling system 200. In general terms, the DS handling system 200 has a CN side for interacting with entities in the CN 110 and an AN side for interacting with entities in the AN 120. In this respect, the CN side might be regarded as implemented in the CN 110 and the AN side might be regarded as implemented in the AN 120. A data controller 210 acts as an interface to the data sources 130-1: 130-N and controls the general operation of the DS handling system 200. The data controller 210 might be the entity in the DS handling system 200 that de-identifies DSs obtained from the data sources 130-1: 130-N. A data distribution system 220 is configured to handle communication and distribution of DSs on the CN side. Likewise, a data distribution system 260 is configured to handle communication and distribution of DSs on the AN side. A data repository 230 acts as a database and stores customer contracts according to a defined information model that expresses the written contracts in a formal language that can be used to execute policies in the DS handling system 200. This enables only DSs to be transferred from the CN side to the AN side according to what is allowed according to the contracts, and when a transfer is performed, the transfer is performed in the manner specified by the relevant contract(s). This could imply that some information elements of the DSs must be de-identified before they can leave the CN. Examples of such information elements include customer identities such as the International Mobile Subscriber Identity (IMSI) and the Mobile Subscriber Integrated Services Digital Network (MSISDN), or other type of identity information of a user, subscriber, entity, or the like. A data catalogue 240 enables data consumers to discover available DSs, with instructions on how to access it for consumption. Data must be interpreted to be consumed, and for this purpose the data catalogue 240 also contains references to metadata specifications for available DSs. Examples of the kind of metadata stored in the data catalogue 240 include: the type of data, class of data (raw data or insight), source of origin, data quality indication, data lineage information, including all transformations that have occurred, location, DS reference, logical name (such as a Uniform Resource Locator (URL)) for data consumption, schema and serialization method, metadata specification references, such as references to schemes stored in a scheme repository. Data relay gateways 250, 270, or just gateways for short, provide the functionality to transfer DSs from the CN 110 to the AN 120 in accordance with customer contracts and legislation. In this respect, a CN gateway 250 is placed on the CN side and an AN gateway 270 is placed on the AN side. The CN gateway 250 and the AN gateway 270 are configured for communication with each other. The CN gateway 250 implements data export policies in accordance with customer contracts and regulations, and it transfers data to AN gateway 270, which is the entrance to the AN 110. For this purpose, the CN gateway 250 connects to the data repository 230. The CN gateway 250 is installed per customer and the AN gateway 270 can be installed per application cluster or be shared by several application clusters.

Reference is now made to Fig. 3 illustrating a method for de-identifying an original DS as performed by the DS handling system 200 according to an embodiment.

S102: The DS handling system 200 obtains an original DS from a CN 110. In some examples, the original DS is provided by one or more data sources 130-1: 130N in the CN 110. The original DS is to be de-identified.

S104: The DS handling system 200 transforms the original DS to a D-DS by subjecting the original DS to a destructive data anonymization algorithm.

In this respect, the destructive data anonymization algorithm needs only to be applied to those information elements of the DS that need to be anonymized. In general terms, the information elements of the DS that need to be anonymized might be the information elements that carry identity information, such as data that can be used to identify a particular user, subscriber, entity, or the like.

S106: The DS handling system 200 encrypts a mapping between the original DS and the D-DS.

S106: The DS handling system 200 publishes the D-DS and the encrypted mapping.

This method enables inexpensive destructive de-identification of the original DS whilst, by means of the encrypted mapping, also providing the ability for the original DS to be re-created. Hence, this method provides the same capabilities as nondestructive de-identification algorithms but only for authorized AF entities 300-m that have access to a key for decrypting the encrypted mapping between the original DS and a D-DS.

Embodiments relating to further details of de-identifying an original DS as performed by the DS handling system 200 will now be disclosed.

There could be different ways to provide the mapping between the original DS and the D-DS. In some aspects, the mapping is implemented as a set of name-value pairs. In particular, in some embodiments, the original DS is composed of pieces of data and the D-DS is composed of de-identified values, and the mapping is composed of name-value pairs correlating each piece of data in the original DS to a corresponding de-identified value in the D-DS. There could be different examples of mappings implemented as a set of name-value pairs. In some examples, the mapping is an information element chain (IEC).

There could be different examples of destructive data anonymization algorithms. In some embodiments, the destructive data anonymization algorithm is a one-way function. One example of a one-way function is a (cryptographic) hash function. Them, the D-DS is a hash of the original DS.

In some embodiments, the mapping is integrity protected before being published. This can be done to ensure that no other entity has tampered with the mapping after it was created.

The D-DS and the encrypted mapping might be published on a data distribution system 220, 260 of the DS handling system 200.

In some aspects, the D-DS and the encrypted mapping are transferred from the CN side to the AN side. In particular, in some embodiments, the DS handling system 200 is configured to perform (optional) step S110.

S110: The DS handling system 200 transfers, upon having applied transport encryption to the D-DS and the encrypted mapping, the D-DS and the encrypted mapping from the CN 110 to the AN 120.

In this respect, the D-DS and the encrypted mapping might be transferred from the CN gateway 250 on the CN side to the AN gateway 270 on the AN side of the DS handling system 200.

Reference is now made to Fig. 4 illustrating a method for accessing an original DS having been de-identified as performed by the AF entity 300-m according to an embodiment. The AF entity 300-m is provided in an AN 120. The AF entity 300-m has access to a key for decrypting an encrypted mapping between the original DS and a D-DS.

S202: The AF entity 300-m retrieves the D-DS and the encrypted mapping. In some examples, the D-DS and the encrypted mapping are retrieved from the DS handling system 200, such as from a data distribution system 260 on the AN side of the of the DS handling system 200.

S204: The AF entity 300-m decrypts the encrypted mapping using the key for decrypting.

S206: The AF entity 300-m transforms the D-DS to the original DS by using the decrypted mapping to map the D-DS to the original DS. The AF entity 300-m thereby accesses the original DS.

That is, with the key, the AF entity 300-m is capable of unlock the D-DS and back it back to its original form.

Embodiments relating to further details of accessing an original DS having been deidentified as performed by the AF entity 300-m will now be disclosed.

In general terms, the embodiments, aspects, and examples, disclosed above in relation to the method performed by the DS handling system 200 also apply to the method performed by the AF entity 300-m.

As disclosed above, in some embodiments, the original DS is composed of pieces of data and the D-DS is composed of de-identified values. The mapping is then composed of name-value pairs correlating each piece of data in the original DS to a corresponding de-identified value in the D-DS.

As further disclosed above, in some embodiments, the mapping is an IEC.

One particular embodiment for de-identifying an original DS and for accessing the original DS as having been de-identified based on at least some of the above disclosed embodiments will now be disclosed in detail. This particular embodiment is for illustrative purposes disclosed in the context of a Data Ingestion (DI) architecture, although the herein disclosed embodiments are not restricted to any particular architecture but are applicable to any architectures where de-identification of DSs is required.

S301: A DS is collected by the DS handling system 200 from a data source 130- I:130N in the CN 110. The DS is not de-identified. S302: The collected DS is published on a data distribution system 220 in the CN side of the of the DS handling system 200.

S303: The data controller 210 is notified of the DS being published, retrieves the DS and transforms the original DS to a D-DS by subjecting the original DS to a destructive data anonymization algorithm. The data controller 210 further generates an IEC, where the IEC defines a mapping between the original DS and the D-DS. The data controller 210 encrypts and digitally signs the IEC for authenticity and integrity purposes.

S304: The data controller 210 publishes the D-DS and the encrypted and signed IEC on the data distribution system 220.

S305: The CN gateway 250 notifies the AN gateway 270 that the D-DS is available.

S306: The D-DS and the encrypted and signed IEC are transferred with transport encryption via the CN gateway 250 and the AN gateway 270 to the AN 120.

S307: The AN gateway 270 publishes the D-DS and the encrypted and signed IEC on a data distribution system 260 on the AN side of the of the DS handling system 200.

S308: Any application entities 300-m in the AN 120 with the right security class can access, i.e., decrypt, the encrypted and signed IEC and then transform the D-DS into its original form.

Fig. 5 schematically illustrates, in terms of a number of functional units, the components of a dataset handling system 200 according to an embodiment. Processing circuitry 510 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 910a (as in Fig. 9), e.g. in the form of a storage medium 530. The processing circuitry 510 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

Particularly, the processing circuitry 510 is configured to cause the dataset handling system 200 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 530 may store the set of operations, and the processing circuitry 510 may be configured to retrieve the set of operations from the storage medium 530 to cause the dataset handling system 200 to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus the processing circuitry 510 is thereby arranged to execute methods as herein disclosed.

The storage medium 530 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

The dataset handling system 200 may further comprise a communications interface 520 for communications with other entities, functions, nodes, and devices of the network 100. As such the communications interface 520 may comprise one or more transmitters and receivers, comprising analogue and digital components.

The processing circuitry 510 controls the general operation of the dataset handling system 200 e.g. by sending data and control signals to the communications interface 520 and the storage medium 530, by receiving data and reports from the communications interface 520, and by retrieving data and instructions from the storage medium 530. Other components, as well as the related functionality, of the dataset handling system 200 are omitted in order not to obscure the concepts presented herein.

Fig. 6 schematically illustrates, in terms of a number of functional modules, the components of a dataset handling system 200 according to an embodiment. The dataset handling system 200 of Fig. 6 comprises a number of functional modules; an obtain module 610 configured to perform step S102, a transform module 620 configured to perform step S104, an encrypt module 630 configured to perform step S106, and a publish module 640 configured to perform step S108. The dataset handling system 200 of Fig. 6 may further comprise a number of optional functional modules, such as a transfer module 650 configured to perform step S110. In general terms, each functional module 610:650 maybe implemented in hardware or in software. Preferably, one or more or all functional modules 610:650 may be implemented by the processing circuitry 510, possibly in cooperation with the communications interface 520 and/or the storage medium 530. The processing circuitry 510 may thus be arranged to from the storage medium 530 fetch instructions as provided by a functional module 610:650 and to execute these instructions, thereby performing any steps of the dataset handling system 200 as disclosed herein.

The dataset handling system 200 may be provided as a standalone device or as a part of at least one further device. Thus, a first portion of the instructions performed by the dataset handling system 200 may be executed in a first device, and a second portion of the instructions performed by the dataset handling system 200 may be executed in a second device; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the dataset handling system 200 may be executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by a dataset handling system 200 residing in a cloud computational environment. Therefore, although a single processing circuitry 510 is illustrated in Fig. 5 the processing circuitry 510 may be distributed among a plurality of devices, or nodes. The same applies to the functional modules 610:650 of Fig. 6 and the computer program 920a of Fig. 9.

Fig. 7 schematically illustrates, in terms of a number of functional units, the components of an application function entity 300-m according to an embodiment. Processing circuitry 710 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 910b (as in Fig. 9), e.g. in the form of a storage medium 730. The processing circuitry 710 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

Particularly, the processing circuitry 710 is configured to cause the application function entity 300-m to perform a set of operations, or steps, as disclosed above. For example, the storage medium 730 may store the set of operations, and the processing circuitry 710 may be configured to retrieve the set of operations from the storage medium 730 to cause the application function entity 300-m to perform the set of operations. The set of operations maybe provided as a set of executable instructions. Thus the processing circuitry 710 is thereby arranged to execute methods as herein disclosed. The storage medium 730 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

The application function entity 300-m may further comprise a communications interface 720 for communications with other entities, functions, nodes, and devices of the network 100. As such the communications interface 720 may comprise one or more transmitters and receivers, comprising analogue and digital components.

The processing circuitry 710 controls the general operation of the application function entity 300-m e.g. by sending data and control signals to the communications interface 720 and the storage medium 730, by receiving data and reports from the communications interface 720, and by retrieving data and instructions from the storage medium 730. Other components, as well as the related functionality, of the application function entity 300-m are omitted in order not to obscure the concepts presented herein.

Fig. 8 schematically illustrates, in terms of a number of functional modules, the components of an application function entity 300-m according to an embodiment. The application function entity 300-m of Fig. 8 comprises a number of functional modules; a retrieve module 810 configured to perform step S202, a decrypt module 820 configured to perform step S204, and a transform module 830 configured to perform step S206. The application function entity 300-m of Fig. 8 may further comprise a number of optional functional modules, as represented by functional module 840. In general terms, each functional module 810:840 may be implemented in hardware or in software. Preferably, one or more or all functional modules 810:840 may be implemented by the processing circuitry 710, possibly in cooperation with the communications interface 720 and/or the storage medium 730. The processing circuitry 710 may thus be arranged to from the storage medium 730 fetch instructions as provided by a functional module 810:840 and to execute these instructions, thereby performing any steps of the application function entity 300-m as disclosed herein.

The application function entity 300-m may be provided as a standalone device or as a part of at least one further device. Thus, a first portion of the instructions performed by the application function entity 300-m may be executed in a first device, and a second portion of the instructions performed by the application function entity 300- m may be executed in a second device; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the application function entity 300-m may be executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by a application function entity 300-m residing in a cloud computational environment. Therefore, although a single processing circuitry 710 is illustrated in Fig. 7 the processing circuitry 710 maybe distributed among a plurality of devices, or nodes. The same applies to the functional modules 810:840 of Fig. 8 and the computer program 920b of Fig. 9.

Fig. 9 shows one example of a computer program product 910a, 910b comprising computer readable means 930. On this computer readable means 930, a computer program 920a can be stored, which computer program 920a can cause the processing circuitry 510 and thereto operatively coupled entities and devices, such as the communications interface 520 and the storage medium 530, to execute methods according to embodiments described herein. The computer program 920a and/or computer program product 910a may thus provide means for performing any steps of the dataset handling system 200 as herein disclosed. On this computer readable means 930, a computer program 920b can be stored, which computer program 920b can cause the processing circuitry 710 and thereto operatively coupled entities and devices, such as the communications interface 720 and the storage medium 730, to execute methods according to embodiments described herein. The computer program 920b and/or computer program product 910b may thus provide means for performing any steps of the application function entity 300-m as herein disclosed.

In the example of Fig. 9, the computer program product 910a, 910b is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu- Ray disc. The computer program product 910a, 910b could also be embodied as a memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory or a Flash memory, such as a compact Flash memory. Thus, while the computer program 920a, 920b is here schematically shown as a track on the depicted optical disk, the computer program 920a, 920b can be stored in any way which is suitable for the computer program product 910a, 910b.

The inventive concept has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the inventive concept, as defined by the appended patent claims.