FI3912021T3 - Dynamic creation of compatibility between file systems in real time - Google Patents

Description

1 EP 3912 021

DYNAMIC CREATION OF COMPATIBILITY BETWEEN FILE SYSTEMS IN

REAL TIME

Description

The present invention is directed at a method for dynamically establishing file system compatibility and accessing data in real time independently of the file system. According to the invention, it is possible for an end user to access a passive data store using any terminal without requiring consideration of the underlying file system of the passive store. Thus, complex method steps are avoided which, for example, provide a conversion of the file system directly on the storage medium. Thus, the proposed method is more efficient and robust against error. The present invention is also directed at a correspondingly configured device and at a system arrangement. In addition, a computer program product with control instructions that implement the method steps is proposed.

US 5,463,772 A1 discloses devices for reading and writing to a data store having a predetermined file system by a host computer via a transparent peripheral file system adapter.

WO 2005/086 039 A2 proposes a method for producing storage media recorded with structured information and proposes to perform a conversion of data for this purpose and uses a universal data model.

WO 2018/031 794 A1 shows a method for writing to storage media. US 5,742,818

A shows a method for converting a file system.

The prior art addresses the problem that, if a terminal wants to access a data store, compatibility problems can occur. For example, the terminal does not support a file system present on the memory. For this purpose, the prior art proposes that, in the event of an incompatibility, i.e., different file systems, the file system of the data store typically be converted. Thus, the file system of the data store is converted to the file system that is supported by the terminal. This is a complex process and, moreover, the data on the storage medium are lost.

The transfer or conversion from one file system to another file system is often performed by formatting the entire data store. Formatting is based upon erasing

2 EP 3 912 021 the entire data store during restructuring, so that the data store is then empty at the start of a write operation. This entails further problems - for example, the need for data backup or the problem of a possible data loss.

Furthermore, an emulation is known from the prior art, wherein a functionality of a target system is imitated. Emulation is in turn a complex process and requires a considerable outlay in the provision of an abstraction layer of the underlying hardware and software of the target system. The emulation itself is often complex.

In addition, unnecessary functionality is provided if a communication party is a passive data store. This typically does not offer extensive functionality; rather, the essential task of the data store is simply to act passively and store only static data.

Thus, emulation is also complicated and may be susceptible to errors.

The prior art thus has the disadvantage that no method is provided which allows an end user to connect a passive data carrier to a terminal in such a way that a compatibility of the underlying file systems is guaranteed in every case.

Corresponding methods are costly, and, typically, an elaborate conversion of the entire file system is carried out in a preparatory method step. However, this is perceived as disadvantageous by the user, since the user typically wants to write to the data carrier in real time and thus does not want to accept formatting. If the user is then still threatened with data loss, then acceptance of such methods is lacking.

Itis therefore an object of the proposed invention to provide a method which enables the user to connect a passive data store to a terminal without the occurrence of problems relating to the compatibility of file systems. This means that data access should be possible independently of the file system, without any loss of data, and in real time. It is further an object of the present invention to propose a correspondingly configured device and a correspondingly configured system arrangement. In addition, a computer program is to be proposed with control instructions that implement the method or operate the device or system arrangement.

The object is achieved by a method having the features of claim 1. Further advantageous embodiments are specified in the dependent claims.

3 EP 3 912 021

Accordingly, a method is proposed for dynamically establishing file system compatibility and for accessing data in real time independently of the file system, comprising granting access to the file system of a passive data store for an active terminal, and a modeling device communicatively interposed between the passive data store and the active terminal; receiving an access request from the active terminal by the modeling device, wherein the access request specifies access data and access operations to the passive data store; a recognition of the file system of the passive data carrier by the modeling device; selecting stored access rules suitable for carrying out the access request according to the recognized file system of the passive data store; application by the modeling device of the selected access rules to access data specified by the access request, wherein the access rules map the access request as generated by the file system of the active terminal to the file system of the passive data store; and performing the access operations according to the access request.

According to the invention, a compatibility of file systems is dynamically established in such a way that the hardware of the data carrier is not emulated, but, rather, an adjustment is made on the data level or file level in such a way that data can be written from the terminal to the passive data store. Thus, there is no simulation of hardware, but, rather, work is done on the file level, for which purpose an emulation is not necessary. A passive data store also does not hold any software, so here as well no functionality needs to be mapped. Only passive read operations or write operations are typically offered by the data store. This makes it possible for the proposed method to operate in real time.

According to the present invention, real time means that there is no significant latency, i.e., that the user does not notice any delay from their point of view. The individual method steps can be carried out in a fraction of a second, so that the end user perceives the execution of the method as being in real time. From a technical point of view, there is of course a processing time, but this is not subjectively perceptible by a human user.

According to the invention, the method avoids the need to emulate or transfer file systems in a preparatory method step. Thus, the end user can couple the storage medium or passive data store to the terminal using the modeling device and

4 EP 3 912 021 immediately begin read operations and write operations to the data store. Thus, access to data of the data store is carried out independently of the file system.

Access to data in this case means that both read operations and write operations on the data carrier are supported.

This requires granting access to the file system. A grant of access is also referred to as a MOUNT process. It is possible here to read out the file system of the passive data store and to already recognize which data are present on the data store. This does not require a significant time outlay; so, from the user's point of view, this method step can also be executed in real time, i.e., without wait times.

By granting access to the file system, the data store is communicatively coupled to the active terminal, with the modeling device interposed. The granting of access comprises, for example, the establishment of a plug-in connection between the data store, the modeling device, and the active terminal.

The plug-in connection can be made in such a way that the passive data store is plugged directly into the modeling device, which in turn is plugged into the active terminal. However, it is also possible to provide one wired connection each between the data store, the modeling device, and the terminal. According to one aspect of the present invention, granting access is performed by means of a physical connection between the data store, modeling device, and terminal. For this purpose, the person skilled in the art knows standard formats or how such a plug-in connection is to be designed. USB can be taken as an example, so that standard interfaces can be used for this. A passive data store can thus be an external hard disk or a USB stick or SD card slot.

The modeling device can be designed as a separate hardware device and can, for example, have a data store which contains access rules. The modeling device can also be implemented as an embedded system that provides or executes the control logic. In general, the modeling device comprises at least two interfaces, wherein the passive data store communicates with the modeling device via one interface, and the active terminal communicates with another interface. In general, however, it is also possible to provide further interfaces, so that several data stores can also be connected. It is also possible to connect several active terminals so that they write or read to the data store.

EP 3 912 021

The passive data store does not provide any functionality, but merely serves to store data, and can consequently be referred to as passive. The corresponding write operations and read operations are initiated and transmitted by the active terminal. The active terminal therefore initiates the method according to the 5 invention and wants to access the passive data store. The active terminal holds data ready that are stored according to the underlying file system, or requests data that are stored on the passive data store. According to the invention, the corresponding data are adapted as a function of the supported file system of the active device.

In general, the active terminal supports a first file system, wherein the passive data store has a second file system. If data are now written to the passive data store, the data in the first file system format are adapted in such a way that they are to be stored in the second file system format. If data are requested from the data store, the corresponding data are adapted by the second file system format in such a way that they correspond to the first file system format. Typically, no adaptation of the user data is required for this, but only the additional data must be adapted. For example, metadata can be modeled such that they are writable to the data store or can be stored on the active terminal. The additional data can be data which describe the user data or provide information relating to the file system.

Thus, it may happen that the additional data describe an offset indicating where the corresponding data blocks are physically stored on the storage medium.

Thus, receiving an access request from the active terminal is performed by the modeling device, wherein the access request specifies access data and access operations to the passive data store. The access operations can be either read operations or write operations, while the access data describe what exactly is to be queried or transmitted. The access data can specify, for example, a file name that is to be written to the data store according to the access operation, “write.”

The access request is initiated by the active terminal and specifies the desired data without referring to the file system.

The file system of the passive data carrier is then recognized by the modeling device. The modeling device mediates between the active terminal and the passive data store. Thus, all messages or instructions are passed through the

6 EP 3 912 021 modeling device. Thus, the connected communication parties, i.e., the active terminal and the passive data store, communicate only via the modeling device.

Furthermore, a selection is made from stored access rules as to which are suitable for carrying out the access request according to the detected file system of the passive data memory. The stored access rules can, for example, be determined empirically or can be created in a preparatory method step. The access rules describe how data are to be modeled so that, starting from a first file system, they can be interpreted within a second file system. Typically, additional data are adapted here, e.g., metadata, such that files or data which are encoded according to the first operating system are encoded according to the second operating system. If, for example, a write operation takes place, the active terminal transmits the files according to the first file system or file system format which is present on the active terminal. These are then modeled according to the access rules in such a way that they can be stored on the second file system or file system format. If, on the other hand, a read operation is performed, the data of the second file system are modeled in such a way that they are interpretable by the active one.

Thus, the data are converted such that they can be stored on the file system of the active terminal.

The access rules can be selected such that a table is kept available which describes the file system of the active terminal in the first column, describes, in the second column, the file system of the passive data store, and, in a third column, indicates which access rules are provided. Thus, the third column can hold a pointer that points to the corresponding access rules. FAT, FAT32, ExFAT, NTFS, or others can be used as a file system.

The data store with the access rules is typically installed inside the modeling device, or it is also possible that the data store exist as an external data store that is read out. The data store can thus also be kept available by the active terminal.

The access rules thus describe rules as to how to adapt the data to be written or read so that they are compatible in each case. That is, it can be provided that the access data be analyzed in such a way that user data are separated from other data, and the other data are adapted according to the file system. Optionally, it is

7 EP 3 912 021 provided that the user data also be adapted, wherein, in a typical case, only the additional data or the metadata are adapted. It is thus possible to carry out the modulation process very efficiently, and it is in turn possible to carry out the method in real time. The conversion of the additional data can therefore take place quickly, since it is not the file system that is adapted, but, rather, the data, and, in the data, typically only the metadata. These are only very small amounts of data, which can be adapted without great technical effort.

Once the access rules have been selected, they are applied to the access data, i.e., the data to be read or written are adapted in such a way that they can be written to the file system of the passive data store, or, if data are read, they are adapted in such a way that they correspond to the file system of the active terminal. As has already been described, here, it is often sufficient to encode or model only additional data, and not user data.

Since the data have now been transformed in a compatible manner, it is possible to initiate the actual step of performing the access operations. The access operations may be either read operations or write operations. Since the data are now present in a suitable form, they are therefore written to the passive data store or read from the passive data store.

The method steps can be carried out iteratively such that the application of the selected access rules and the performance of the access operations take place for a defined data stream. Thus, for example, a set of files can be requested by the active terminal, and it can be determined according to the access operations whether a one-time adaptation of the access data is sufficient or whether - for example, after each write operation of a file - a renewed application of the access rules is necessary. In this way, the metadata can thus be adapted for each file, or the metadata are adapted only once, and all user data are overwritten. How to proceed here can be stored in the data store of the modeling device.

According to one aspect of the present invention, the granting of access comprises a mount operation, an integration of the passive data carrier into the modeling device, an integration of the passive data carrier into the active terminal, a communicative coupling, establishing at least one plug-in connection, an activation

8 EP 3 912 021 of an access, setting up access rights, and/or a data communication. This has the advantage that already during the granting of access, the data store can be read out, and it is thus possible already to estimate the available data during a read operation. Thus, for example, file sizes are known, and it can be determined how the data stream to be read is constructed. As a function of this information, the application of the selected access rules and the execution of the access operations can be optimized. For example, if many smaller files are present, individual groups of files can be read as one data stream, and thus the application of the selected access rules relates to several files. If large files are present, the application of the access rules can take place for each file. The communicative coupling ensures that the active terminal communicates with the passive data store via the modeling device. Furthermore, it is possible to implement additional security mechanisms; for example, access rights can be assigned.

According to a further aspect of the present invention, the active terminal has an operating system which generates the access request. This has the advantage that the data streams can be specified in advance, and thus it is known which files are requested. Thus, the operating system can specify that a number of files are to be read or written, and thus the application of the selected access rules can be applied to one or more files. The access data can consequently be segmented and can be adapted as a batch, or individual segments, i.e., individual data streams, can be adapted. Thus, small amounts of data can be combined, and a one-time application of the access rules takes place. Thus, these files can be written, and additional data need not be adapted every time.

According to a further aspect of the present invention, the application and execution is iteratively performed for each data stream, wherein the operating system defines the data stream. This has the advantage that the application of the access rules and the execution of the write operations can be performed as often as desired, so that, after the last iteration, all access data are read or written. Thus, the data streams can be selected as a function of the requested or specified files.

According to a further aspect of the present invention, the access request includes at least one read and/or write request. This has the advantage that the passive

9 EP 3 912 021 data store can be accessed with both read and write operations. In this case, itis not necessary to emulate a functionality of the passive data store, but, rather, in accordance with the invention, an adaptation of the (meta) data to be written or read is carried out, and there is no direct adaptation of the file system on the passive data store.

According to a further aspect of the present invention, the access request specifies user data and/or additional data. This has the advantage that the access request already specifies which data are user data and which are additional data.

Additional data can be present, for example, as metadata which describe the user data. Such additional data are, for example, the size of the file or a file name. If a file system does not support certain additional data, e.g., a different character set is used, the access rules are applied in such a way that the file name is modified so that it matches the character set of the file system. For example, the active terminal wants to write files to the passive data store and, in this case, specifies user data with file names that have an umlaut. If umlauts are not supported on the file system of the data store, the access rule provides for example that umlauts be replaced by another vowel, or be replaced by a vowel and an “e.”

According to a further aspect of the present invention, access data describe file names, absolute memory addresses, relative memory addresses, file types, and/or file properties. This has the advantage that the access data describe which information potentially has to be adapted. If the memory system of the passive data store supports only certain memory addresses or has only a certain size, then the transmitted memory addresses are adapted so that the access data can be written to the data store. If files are read, these access data can be adapted such thatthey can be stored on the file system of the active terminal.

According to a further aspect of the present invention, access operations describe read and/or write operations. This has the advantage that the access operations describe how the individual operations are to be performed. Here, it is possible to describe for each file system how read or write operations are to be done.

According to another aspect of the present invention, the access rules describe modulation operations that specify how to model additional data from access data

10 EP 3 912 021 so that the access data can be read and/or written according to the file system.

This has the advantage that the access rules show transformation rules or modulation rules which transform certain access data in such a way that, if these are encoded with respect to a first file system, they are re-encoded in such a way that they are compatible with a second file system.

According to another aspect of the present invention, access rules describe how data according to a first file system are to be written to a second file system and/or to be read from a second file system. This has the advantage that a transformation can take place from a file system which can be present on the active terminal and from a file system which is present on the passive data store. Thus, the access rules describe encoding data or describe the process of how additional data are to be adapted. Typically, only the additional data must be adapted, and not necessarily the user data.

According to another aspect of the present invention, the passive data store comprises a storage medium, a USB stick, a hard drive, a memory card, a server, a network component, a DAS, an NAS, and/ or a local data store. This has the advantage that conventional specifications can be reused, and, moreover, a large number of storage media can be used. Here, it is also possible for several passive data stores to be addressed. NAS stands for Network Attached Storage. DAS stands for Direct Attached Storage.

According to another aspect of the present invention, the active terminal is present as a television, a printer, a router, a DAS, an NAS, a portable terminal, a stationary terminal, a computer, a telephone, or a network component. This has the advantage that the active terminal can be implemented in a large number of ways, and a generic method is created which establishes the compatibility of very different file systems.

Another aspect of the present invention is its ability to differentiate access requests and decide whether access to user contents or to metadata is requested.

Depending upon the type of access request, the request is then either forwarded without data modifications into the passive store or the metadata are brought into the corresponding format using the translation rules.

11 EP 3 912 021

Another aspect of the present invention is its ability to retrieve only a portion of metadata from the passive store in order to send feedback to the terminal. Thus, only the most necessary information about the requested files is provided, in real time and with a short response time.

Another aspect of the present invention is its ability to make only a certain part of the passive store (typically, a particular subdirectory, with its contents) available as separate memory, which can then be provided by the terminal.

Another aspect of the present invention is its ability to preselect and thus decide which file system is made available to the terminal. This is done either by a switch or by using preset files on external media, such as makeas.exFAT, which instructs the modeling unit to create an external store with an exFAT file system. Thus, the modeling unit can make the exFAT file system available to the terminal, because this file system has been widely used, since its specifications were made publicly available (the open-source implementation of exFAT is supported by the developers of the Microsoft Corporation), and is used in a wide range of embedded devices, cell phones, and other multimedia devices.

Another aspect of the present invention is its ability to compensate for serious disadvantages of FAT32 when this file system is used on the terminal. A major disadvantage is the limitation of the file size, which is 4 GB for FAT32. Another limitation of FAT32 is the number of addressable files in the same subdirectory, which is 65,534. An external medium provided with FAT32 is, with high probability, supported by older models of terminals, and their limitations can also be taken into account so that the user can continue to work with it. The present invention deals with the problem posed by large files in such a way as to make multiple files available to the terminal with the maximum allowed size of 4 GB.

The second limitation of FAT32, viz., the maximum number of 65,534 addressable files in the same subdirectory, then has an effect on usage if all the files are located in the same directory or subdirectory. While it is highly unlikely that information will be retrieved from a subdirectory containing more than 65,534 files, in suchacase, the present invention will alert the user that the limit has been reached, and that these 65,534 files cannot be accessed simultaneously. Thus,

12 EP 3 912 021 the user knows that not all files can be displayed on the terminal, but are still available.

It is assumed according to one aspect of the present invention that the terminal supports only FAT32. Support for FAT32 in the terminal is considered to exist if its modules or components (e.g., installed file system drivers) are capable of addressing local, external, or virtual stores with FAT32 format to create, restore, update, or delete files and directories.

According to one aspect of the present invention, the store is defined as a block device, i.e., basic operations are provided by means of blocks - read and write blocks addressed in offset fashion or via the position in the memory. It is assumed that the terminal has a USB interface for connection to external storage media.

The assumption of FAT32 support in the terminal is generally only for demonstration purposes and is not intended to limit the possible uses of the proposed invention to the FAT32 system. The assumption that the terminal has a

USB interface for connection to external storage media is also for the purpose of illustration and is not intended to limit the possible uses of the proposed invention to a USB interface connection. If corresponding standards are named here, such as FAT or FAT32, this stands generally for a file system.

The object is also achieved by a modeling device communicatively interposable between a passive data store and an active terminal and set up to grant access to the file system of a passive data store for an active terminal, wherein the modeling device is further set up for receiving an access reguest from the active terminal, wherein the access reguest specifies access data and access operations to the passive data store, and is further set up to recognize the file system of the passive data carrier, and is further set up to select stored access rules suitable for performing the access reguest according to the recognized file system of the passive data store, and the modeling device is further set up to apply the selected access rules to access data specified by the access reguest; and is further set up to cause the access operations to be performed in accordance with the access request. The modeling device is suitable for use in

13 EP 3 912 021 the proposed method. Furthermore, the modeling device can be used in the proposed system arrangement.

The object is also achieved by a system arrangement for dynamically establishing file system compatibility and for accessing data in real time independently of the file system, comprising at least one interface unit set up for granting access to the file system of a passive data store for an active terminal, and a modeling device communicatively interposed between the passive data store and the active terminal; the modeling device set up for receiving an access request from the active terminal, wherein the access request specifies access data and access operations to the passive data store; the modeling device set up to recognize the file system of the passive data carrier; a database unit set up to select stored access rules suitable for performing the access request according to the recognized file system of the passive data store; the modeling device set up for application by the modeling device of the selected access rules to access data specified by the access request, wherein the access rules map the access request as generated by the file system of the active terminal to the file system of the passive data store; and the passive data store set up to perform the access operations according to the access request.

The object is also achieved by a computer program product with control instructions that execute the method and operate the proposed arrangement when executed on a computer.

According to the invention, it is particularly advantageous that the method can be used to operate the proposed devices and units or the system arrangement.

Furthermore, the proposed devices and equipment are suitable for carrying out the method according to the invention. Thus, the device, or the system arrangement, each implement structural features which are suitable for carrying out the corresponding method. However, the structural features can also be designed as method steps. The proposed method also contains steps for implementing the function of the structural features. Further advantages, features, and details of the invention will become apparent from the following description, in which aspects of the invention are described in detail with reference to the drawings. The terms, "left," "right," "top," and "bottom," used in the description of the embodiments refer

14 EP 3 912 021 to the drawings in an orientation with normally readable figure designation or normally readable reference signs. The embodiments shown and described are not to be understood as conclusive, but have an exemplary character for explaining the invention. The detailed description is provided for the information of the person skilled in the art; therefore, known circuits, structures, and methods are not shown or explained in detail in the description in order not to make the understanding of the present description more difficult. In the drawings:

Figure 1: shows a schematic block diagram of a known system arrangement;

Figure 2: shows a schematic block diagram of a system arrangement for dynamically establishing file system compatibility and for accessing data in real time independently of the file system, in accordance with an aspect of the present invention;

Figure 3: shows a schematic block diagram of a system arrangement for dynamically establishing file system compatibility and for accessing data in real time independently of the file system, in accordance with another aspect of the present invention; and

Figure 4: shows a schematic flowchart of a method for dynamically establishing file system compatibility and for accessing data in real time independently of the file system, in accordance with another aspect of the present invention;

Figure 5: shows a schematic flowchart of method steps which can be carried out by the modeling device;

Figure 6: shows a schematic flowchart of method steps according to the invention in order to serve an access request;

Figure 7: shows a schematic flowchart of method steps according to the invention of the modeling device for reading the file system parameters from the passive store;

Figures 8A, 8B: show tables illustrating the method steps for applying the stored access rules according to one aspect of the present invention;

15 EP 3 912 021

Figures 9A, 9B: show further tables illustrating the method steps for applying the stored access rules according to a further aspect of the present invention; and

Figure 10: shows tables illustrating the method steps for applying the stored access rules according to one aspect of the present invention.

Figure 1 shows a system arrangement according to the prior art. A storage medium is located on the left-hand side and a terminal is located on the right-hand side, wherein in the present case only the plug-in connection is shown on the right.

The modeling device is designed such that the hardware is emulated on both the right side and the left side. This is the case in the prior art because the device in the middle is suitable for passing on control commands to peripheral devices.

Thus, the prior art typically does not provide for a passive storage medium here; rather, a peripheral device such as an input device can be connected here. Thus, the prior art also requires an emulation of functionality, which is not necessary according to the present invention.

As can be seen from the present Figure 1, it is particularly disadvantageous in the prior art that emulation by means of both emulator 1 on the left side and emulator 2 on the right side is necessary. The prior art therefore provides that all connected terminals have to be emulated, which represents a considerable technical effort and is possibly even prone to error.

According to the invention, this disadvantage in the prior art is overcome, and it was surprisingly found that adaptations are necessary only at the file level or data level. Furthermore, the state of the art does not allow compatibility to be established in real time. If, for example, a storage medium is actually present on the left side, the state of the art provides for the file system to be adapted here.

According to the invention, the file system is not adapted, but only the data to be read or written.

Figure 2 shows a system arrangement according to the present invention. The passive storage medium is located on the left side, and the active terminal, which is not shown here, is located on the right side. In the center is the modeling device

M, which is communicatively interposed between the storage medium and the

16 EP 3 912 021 terminal. For this purpose, plug-in connections can be provided both on the left side and on the right side, or cables are provided in each case.

Figure 2 also shows a data store that stores the access rules and holds them for the modeling device M. The data store can be arranged externally, wherein, in a preferred embodiment, the data store is installed in the modeling device. It is particularly advantageous compared to the prior art that, according to the proposed invention, no emulation components 1, 2 need to be provided, but, rather, it is sufficient to provide a modulation unit. This unit is arranged centrally in the modeling device M.

Figure 3 shows another view of the proposed system arrangement, with a plug-in connection on the left side to the passive data store and a cable connection on the right side. This can also be solved differently, and there can also be a cable connection on the left side. The interfaces used can be designed according to conventional specifications. In a preferred embodiment, the interfaces are implemented as USB interfaces.

Figure 4 shows, in a schematic flowchart, a method for dynamically establishing file system compatibility and for accessing data in real time independently of the file system, comprising granting access 100 to the file system of a passive data store for an active terminal, and a modeling device M communicatively interposed between the passive data store and the active terminal; receiving 101 an access reguest from the active terminal by the modeling device, the access reguest specifying access data and access operations to the passive data store; a recognition 102 of the file system of the passive data carrier by the modeling device; selecting 103 stored access rules suitable for performing the access reguest according to the recognized 102 file system of the passive data store; applying 104 the selected access rules to access data specified by the access request; and performing 105 the access operations according to the access reguest.

The person skilled in the art recognizes here that the steps can have further substeps and in particular that the method steps can be carried out iteratively and/or in another sequence.

17 EP 3 912 021

All the following operations are described from the point of view of the terminal, which is controlled by the user as the main actor.

Figure 5 shows which actions the modeling device 202 can perform according to the invention when the terminal 201 generates read access requests. In the present case, the terminal supports FAT32 as a file system, which is referred to hereafter as filesystem.

According to one aspect of the present invention, the access requests are made by means of a communications interface between the terminal and the modeling device; this is the USB interface 204.

According to one aspect of the present invention, two methods are realized In the modeling device. The method for holding the additional data 206 and the method for the modeling of data 207. When the data are read from the passive store 203, this process takes place by means of a communications interface 205. However, it is not mandatory that the passive store also be connected to the modeling device via USB interface; the 205 can also be replaced by a data bus, so that the passive store is directly realized as a component of the modeling device.

According to one aspect of the present invention, the order of events is based

Upon which access reguests the terminal has initiated, after which the modeling device to which the passive store is already connected is shot at the terminal.

Depending upon the design of the terminal, this order may differ from the following illustrations.

According to one aspect of the present invention, the terminal communicates with the modeling device in two ways: on the one hand, the component of the operating system of the terminal that is responsible for USB devices is to recognize the modeling device connected via USB as an external USB device of the type, "memory." On the other hand, the other component of the operating system is to determine how the connected storage device is to be addressed on the logical level, and specifically which file system to recognize on the store.

According to one aspect of the present invention, for the first communication using the USB protocol, it is at least necessary that the modeling device report essential

18 EP 3 912 021 parameters, e.g., the number of addressable blocks or the block size, as necessary actions in the context of the USB protocol support. For this purpose, a so-called identifier reguest 301 could be initiated, which, however, does not necessarily take place, depending upon the operating system implementation.

Specific actions according to the USB protocol are not discussed here, since this protocol can be carried out largely without any problem by a person skilled in the art. It is only to be noted that this first identifier request already has the result that the modeling device can orient itself according to it, and, for the processing of such identifier reguest, necessary data (the number of addressable blocks) are to be held.

The first action by the modeling device required for this, according to one aspect of the present invention, is the reading of the file system parameters from the passive store 314, which is indicated in detail on Figure 7. The file system on the passive store, henceforth referred to as filesystem2, is recognized by the modeling device during the execution of 314, wherein read-out data are not limited to satisfying the first identifier request, but are first converted according to the invention such that they continue to be held 206 in the modeling device as boot sector data of the filesystem. Consequently, essential parameters for the identification request are also sufficiently determined (the number of addressable blocks, the block size); the modeling device fulfills 310 the identifier request according to the USB protocol.

In a further step, the operating system of the terminal is to determine how the connected storage device is to be addressed on the logical level - specifically, which file system is to be recognized on the store.

For this purpose, the terminal can generate at least one access request that is directed towards at least the block O being read from the memory, because this block contains the information for determining the file system.

In order to fulfill this access request, the following actions can be carried out according to the invention, which are shown by way of example in Figure 5.

The first access reguest 311 of the terminal is: read a sector, starting from position O.

19 EP 3 912 021

In the first step 312, according to one aspect of the present invention, it is checked whether the requested data are already held in the modeling device. It cannot be ruled out that the identifier request of the terminal 301 has not yet occurred, but has been replaced by the access request 311. Although the parameters of the passive store would not yet be known to the terminal when executing the 311, this does not prevent the terminal from generating the access request 311, because it is always possible to read from the position O if the memory device is addressable.

For illustration purposes, it is assumed that the identifier request according to 301 has not been made previously. Consequently, the data for the first sector in position O are not yet held in accordance with 206.

In the second step 313, according to an aspect of the present invention, it is checked which data in the sense of the filesystem are involved when a sector is read from position O. Thus, the action 313 is generally to be described as checking during the reading process whether additional data or user data are involved, and, if they are user data, from which file in the sense of the filesystem1 they originate.

Access rules are applied for this purpose. As shown above, access rules define how metadata of one file system are to be converted into metadata of another file system. These rules also define which areas of the file system intended for the file system structures correspond to the respective areas on the other file system, thus making it possible to determine whether an access request relates to additional data in the sense of metadata.

According to the present access rule 400, specifically, additional data are involved, i.e., a so-called boot sector, if a sector is read from position O.

According to the access rules, a boot sector for file system 1 is summed 314 in such a way that all file system parameters (file system size, the size for logical blocks on the file system (so-called clusters), the initial position for the first directory, etc.) are already sufficiently determined. This requires that these data must be held for the terminal in order to process the very first access 311.

Fundamentally, all parameters for the filesystem1 are derived or calculated from the respective parameters of the filesystem2 of the passive store. The access rule 401 comprises this method; specifically, it determines how the parameters of the

20 EP 3912 021 filesystem are to be calculated, depending upon filesystem2, for the respective filesystem1-filesystem2 combination, and which specific access rule is used. The figure shows how this access rule is applied for the boot sector 401. Such an application is unproblematic, because the file system size is known, and the size of the logical blocks can be taken from the filesystem? (if this is not possible, additional access rules for block size adaptation take effect).

Thus, the modeling device has simulated and held the data for sector O in such a way that the terminal can initiate further access operations on the basis of these.

According to an aspect of the present invention, the specific present reguest 311 is satisfied when modeled boot sector data are provided.

The reguested data 315 are provided via the communications interface (here:

USB). The access reguest 311 is thus completed.

The fact that the first access reguest leads to the result that the read-out block 1 is a FAT32 boot sector determines further actions by the terminal.

In principle, according to one aspect of the present invention, it can be assumed that, if the first block is recognized as a valid boot sector with valid contents (file system parameters), the operating system of the terminal will continue access reguests in order to determine the file system on the store provided via the USB interface. Such an operation can also be called a "test," the purpose of which is to recognize the store as a specific, logically organized file system and to expose its own logical interface (the so-called "mount point") within the operating system.

Alternatively, after the initial access reguest is satisfied and the contents of the first block prove to be a plausible boot sector, the operating system of the terminal can also make a communication (a so-called "broadcast") to its components or applications to inform them of the availability of the new storage device. As a result, the responsible component and the file system driver can initiate a further operation, often referred to as "mounting."

Both alternatives lead to the same result, viz., that the newly-provided storage is recognized as FAT32, and the operating system of the terminal or at least one of the components or apps can address it as a logical file system.

21 EP 3 912 021

According to one aspect of the present invention, whether this file system is mounted only for read operations or also for write operations depends upon the following factors: the operating system of the terminal, the extent of support for the respective file system, and the task that the terminal provides for externally- connectable storage media. The following statements relate to the read-write mode. The case in which the file system on the memory is mounted only in read mode need not be dealt with separately, because the method proposed according to the invention can be applied a fortiori to read mode if it results in the promised success in read-write mode.

Thus, further access requests from the terminal depend upon what tasks are provided in case of the event that "a new store is available." It may be that the terminal executes a particular application that attempts to read the contents of the newly-provided store, with the result that first the contents of the root directory are accessed. If no application is started automatically, the user who connects the modeling device to the device then takes further actions to retrieve the contents of the memory, starting with the action, "retrieve the contents of the root directory," and then determining further steps of his own. To retrieve contents of the root directory, the user could also enter terminal commands like "dir" or "Is." At most, it is to be expected that the terminal will attempt to read the contents of the root directory by means of the next access request. In order to fulfill this access reguest, the following actions can be carried out according to the invention, which are also shown by way of example in Figure 5.

It is assumed, according to an aspect of the present invention, that the root directory range starts at sector X, occupies the range of 100 sectors, and that this has been determined by the rule applied to step 314. Accordingly, the second access request 321 will be: read 100 sectors, starting at sector X.

In the first step 312, according to one aspect of the present invention, it is checked whether the requested data are already held. In the present case, the data are not yet available, since the terminal has only read the sector O up to now.

22 EP 3 912 021

In the second step 313, it is checked which data in the sense of the filesystem are involved when 100 sectors are read starting from position X. Access rules are applied for this purpose.

According to access rule 400, the so-called root directory is involved if sector X is accessed for the modeled file system, and in fact over the entire requested length (100 sectors).

In order for the modeling device 202 to be able to hold available the data for the root directory of the terminal 206, further access rules are applied in the following step 324 (see Figure 9), in such a way that metadata that correspond to the root directory data format of the filesystem are generated in real time for the files present on the filesystem2 in the root directory of this system.

These metadata are thus suitable for rewriting the files on the filesystem2 in such a way that any component of the terminal that supports filesystem1 (here: FAT32) interprets them as if these rewritten files were held in the modeling device.

According to the invention, these metadata are held available 206 for present and future access reguests from the terminal.

For the application of the access rule 324, it may be necessary here to read out further metadata from the filesystem2 in order to gain complete knowledge of which files of the root directory structure are addressable by the reguested 100 sectors and what size they are, and furthermore to determine by means of the method 404 (see Figure 10) in which areas of the filesystem2 the above- mentioned files are placed.

In the intermediate result: by modeling the root directory in the format corresponding to the filesystem1, it is possible that more data than were requested areread out, which is harmless, because such initially superfluous read-out data are held for further applications of the access rule.

The read access reguest from the terminal from step 321 that is specifically present here is satisfied by providing 100 sectors modeled by application of the access rule.

23 EP 3912 021

The provision 325 of the requested data takes place via a communications interface (here: USB). The access request 321 is thus completed.

After the root directory contents have been provided to the terminal, its application can prompt the user to take further steps, such as opening files or selecting file contents for specific operations (printing, playing video/audio files, etc.). At this point, the access to the file content should take place from the external storage medium, and the operating system component of the terminal (or its file system driver) should generate requests to the mounted logical volume in order to retrieve the required content from the file.

In accordance with an aspect of the present invention, it is assumed that the content of file ABC.ZYZ is accessed, and it is assumed that the file size is 10 blocks.

In order to fulfill this access request, the following actions can be carried out according to the invention, which are also shown by way of example in Figure 5.

An access request 351 is initiated, which consists in reading 10 blocks from the position Pos1 that correspond to the first cluster of the file ABC.ZYZ SC1 on the file system 1.

These data were not yet requested, and therefore they are not yet held available 206.

First, it is to be determined whether this request is for user data or additional data 313.

That this request is for user data is already evident from the fact that, when modeling the FAT structures 402 to satisfy the request 321, the size of file

ABC .XYZ has been taken into account, and an unbroken, modeled chain is maintained in the file allocation table for its contents.

That is, the modeling method 402 is suitable for placing existing files of the filesystem2 on the modeled filesystem such that they are not fragmented, regardless of whether these files on the filesystem2 arise from multiple shared content fragments.

These are therefore user data that have been read out by means of the access request 351.

24 EP 3 912 021

In the further step 354, according to one aspect of the present invention, it is to be checked which user data are specifically accessed. It cannot be ruled out that the terminal makes the access request with regard to several files, and not only for

ABC XYZ. This is determined by the method 404 (see Figure 10), which determines which files on the filesystem2 are specifically involved when certain blocks are accessed in the sense of the filesystem. Thus, this method 404 is suitable for determining further actions to be taken in specific contexts for accessed contents from various files. Such a context establishes that, when reading certain blocks from the filesystem that correspond to user data, corresponding blocks to be read are always determined on the filesystem2. As a result, user data is read through a corresponding access request 355 directed to the passive store. The process 355 is repeated until all data requested by way of request 351 have been read, if requested contents are not placed on the filesystem2 as an unbroken chain.

The provision 356 of the requested data takes place via a communications interface (here: USB). The access request 351 is thus completed.

After the root directory contents are provided for the terminal, the application thereof can prompt the user to take further steps, such as saving data generated on the terminal to the mounted logical volume. For example, if new documents are scanned, the mounted logical volume can be selected as the destination storage location.

It is assumed that the terminal, after user data have been generated on the terminal with a scope of 19 blocks, tries to create this user data as a file named

XXX.ABC in the root directory on the filesystem, and, during this attempt, tries to write the contents of the newly-created files XXX. ABC, starting with position Pos2.

It is further assumed, in accordance with an aspect of the present invention, that the terminal does not create an access request directed at describing file names and file size in the root directory of the filesystem for the new file when no user data have yet been defined, and such a request is not made until all user data for these newly-created data have been described.

25 EP 3912 021

The reason for this assumption is the possibility that a method for optimizing read and write access requests is implemented on the terminal.

Thus, if it is assumed that the terminal attempts to write user data before the metadata for the respective file are written by another access request, an uncertainty arises in the sense of the method 404, which is that new blocks to be written are not yet assignable to a file. However, this floating state is terminated at the latest when the terminal still generates an access request that is directed at updating the metadata for the newly-created files on the memory.

In order to fulfill this access request, the following actions can be carried out according to the invention, which are also shown by way of example in Figure 6.

An access request 331 is initiated, which consists of writing 19 blocks, starting with position Pos2, that corresponds to SCN+1.

First, it is to be checked 332 whether these data to be written are held available 206. Since the data in position Pos2 have neither been read nor written, they are also not yet held.

In the next step, it is to be determined whether this request is for user data or additional data 333. Thus, the action 333 is generally to be described as checking during the write process whether additional data or user data are involved, and if they are user data, from which file in the sense of the filesystem they originate.

This cannot yet be unambiguously determined, since these blocks are neither held as metadata 206, nor were they read as user data in the sense of 351. In the next step 334, according to method 405 (see Figure 9), it is first presumed that the data are user data, and the blocks to be written are treated accordingly. Thus, a so- called floating state begins, because the blocks are not yet assignable to a file.

The modeling device will continue to hold the data to be written as user data 206 until later, but, via the communications interface 204, reporting 335 will take place as to the satisfaction of the write operation. The access request 331 is thus completed.

26 EP 3 912 021

It can be assumed that, when the root directory contents for filesystem are updated, another access request 336 is initiated, which is directed at writing a block starting at the position X+99. Specifically, this is the last sector of the root directory.

First, it is to be checked 332 whether these data to be written are held available 206. This is the case here, because the block in position X+99 was already modeled 324 and held 206 in step 321 as the root directory for filesystem1.

If a block of data is already held, and it is metadata, through the application of access rules, it can be determined 339 which specific changes are involved.

Figure 9 shows a corresponding method 406 which consists in gualifying changes in the root directory structure and defining them as an abstract description, from which it can be concluded which corresponding changes are to be made on the filesystem2. In the present case, this is a new entry for the file XXX.ABC, which did not exist previously in the root directory. This change is thus to be described as though the terminal wanted to create a new file called XXX.ABC with size 19 sectors, beginning with Pos2. Such an abstract description of the action can also resemble the Posix standard.

In the further step, according to an aspect of the present invention, the targeted modification is to be applied to the filesystem2 by converting the abstract description into a corresponding reguest to the passive store. As a result, an entry for the data XXX. ABC is created on filesystem2, which, however, does not yet specify a start position of this file on filesystem2, although the start position on filesystem is already specified. It follows from this that, in the floating state, there is still uncertainty in the sense of 404 with regard to the assignability of user data of the specific files on filesystem. However, this uncertainty is resolved with an access request that is directed at updating the area with FAT — to be further discussed later.

Finally, via a communications interface 204, reporting 340 on the completion of the write operation takes place. The access request 336 is thus completed.

After the terminal or its application has completed all necessary user tasks, such as the scanning of documents and the placement of these data on the external

27 EP 3 912 021 medium, or the transport of other user-generated contents, the external medium can be disconnected from the terminal.

Some terminals explicitly require the user to unmount the external device in order to make it possible to ensure data security for these processes. The user would then be solely responsible for a possible loss of data if he removed the external medium before the request to execute the unmount process was issued by the terminal, waiting until its completion took place, and only then disconnecting the external medium and the terminal. Such a secure method of removing an external storage device is not easily enforced as a standard, because users tend to be impatient when it comes to disconnecting an external medium from the terminal.

The user does not expect to have to perform an unmount process and wait; rather, he wants to be able to simply remove the external storage medium as soon as the device activities are finished, and the device is in sleep mode, which can be easily read on the terminal. To meet these user expectations, the operating system of the terminal usually supports a synchronization technique for the file system driver so that it can work with the external storage medium.

This technique always keeps the external storage medium up to date by emptying the contents of the file system data stored in the working memory of the terminal — this is usually initiated by the operating system itself. This means the following:

After the terminal or its application has completed its tasks, in which external storage media may be involved, and has entered sleep mode (and is waiting for further input or instructions from the user), the file system driver or a similar component can empty blocks not yet written on the external medium; this ensures data security should the external storage medium suddenly be disconnected. Such a synchronization technique leads to further access requests to the external memory.

According to the invention, to facilitate such a read and write attempt by the FAT, the following actions can be taken, such as reading the FAT from file system 1.

It should be noted that the access request, which is directed at reading the FAT, is made at the latest with the first attempt to read a file made after the mounting, or after the first attempt to access the subdirectory made after the mounting.

28 EP 3 912 021

Since the FAT (FAT Allocation Table) is the table which defines the area placement of the files in the sense of the filesystem, such structures do not exist in any way on the filesystem2, and they first arise only through the application of access rules to the parallel structures of the filesystem2. As a result, FAT is held available on the modeling device 202. Moreover, such structures do not describe metadata for individual files, but for all files located on the filesystem1, and represent a type of additional data which are not user data.

However, the modeling of the FAT 324 is not done cumulatively for all files present on the filesystem2, but only for files 314 requested during the access request. This means that, as long as a file has not at least been explored on the part of the terminal (whether by requesting the directory contents or by indicating an immediate file path), for this file, no metadata describing its placement will be modeled. The result of such a modeling is the applicability of method 404, which enables the assignability of file user data.

Figure 9 shows a corresponding method, which consists of qualifying changes 405 in the FAT and defining them as an abstract description, from which it can be concluded which corresponding changes are to be made on the filesystem2.

First, it is to be noted that, according to access rule 400, it can readily be determined whether this access request is for the area of the FAT.

Itis assumed that the updating of the FAT is at least directed at mapping the allocation chain for the file XXX. ABC. Since the write operations on the terminal are performed in an optimized manner, it cannot be expected that the updating of the FAT is directed only at a particular allocation chain for a particular file. Rather, it is to be expected that updates of the FAT will take place cumulatively for several files. What changes are specifically intended is to be determined 405 by a comparison of the state for the FAT.

In the present case, this is a new entry for the file XXX ABC, for which no allocation chain yet existed. This change is thus to be described as if the terminal wanted to create, for the new file called XXX.ABC, an unbroken allocation chain including 19 sectors, beginning with (SCN+1).

29 EP 3 912 021

In the further step, the targeted change is to be applied 405 to the filesystem2, in that this abstract description has to make an adjustment to the structures on the filesystem2 that manage the placement of the user data on the file system. This also has the result that the uncertainty about the assignability of the user data in the sense of the method 404 no longer exists, and this user data to be written according to the reguest 331, which was still held in the modeling device, can now be written to the corresponding position of the passive store.

As a result, not only is an entry for data XXX. ABC created on filesystem2, as it was when request 336 was processed, but the placement of file XXX. ABC is also specified, both on file system 1 and on filesystem2.

Finally, via the communications interface 204, reporting on the fulfillment of the write operation takes place. The access request for FAT is thus completed.

Finally, it is to be noted that actions of an otherwise designed terminal can occur in a different order, and all changes on filesystem1 always result immediately in an access request. As a result, above-indicated actions of the modeling device are not different, since the always sequential updating of the filesystem has the result of excluding the floating state in the sense of the method 404.

30 EP 3 912 021

List of reference signs 1 emulator 1 2 emulator 2

M modeling device (100)-(105) see detailed description (201) terminal (202) modeling device (203) passive store (204) communications interface (201)-(202) (205) communications interface (202)-(203) (206) method for holding additional data (207) method for modeling data (301), (310), (311), (312), (313), (315), (325), (351), (355), (356) — see detailed description. (314) modeling of the boot sector structure or file system parameters (324) modeling of directory data (354) specification of user data during reading (331), (332), (333), (335), (336), (349) - see detailed description. (334) specification of user data during writing (339) qualification of the metadata changes (314) modeling of the boot sector structure for (file system 1) using the (filesystem2)

31 EP 3 912 021 (Filesystem1) filesystem (Filesystem2) file system 2 (BytesPerSector) sector size in bytes: parameters that have the original (IN) value (Value1 2) and may possibly receive a new (OUT) value and a new format (Value1_1) by conversion according to the access rule (BS1)

Additional parameters or features of the file system: (SectorPerCluster) number of sectors per cluster (ClusterPerVolume) number of clusters per drive (VolumeLabel) drive name (Etc) - etc. (FSPropertyN) property N of the file system: another parameter on the (filesystem2) that has the original (IN) value (ValueN 2) and potentially receives a new (OUT) value and a new format (ValueN_1) by conversion according to the access rule (BSN) (IN) initial value (ValueN) value N (Rule) rule, access rule (BS2, BSS, etc.) (Out) final value (BSMemberN) (AV) available: availability note for sectors held in (206). (EMPTY) means “not held”; (AV) means “held” (Last) last: the position of the held sector (324) modeling of directory data (StateNow) actual state: current state of the FAT on the file system 1

32 EP 3 912 021 (StateNow-1) previous state of FAT on file system 1, possibly unknown, not-yet- initialized state. (Directory, Filesystem) directory structure on the filesystem1 (modeled) (Directory, Filesystem2) directory structure on the filesystem2 (File... FileN) file 1... file N: file names of the file objects

(Ext1 ... ExtN) extension 1... extension N: file object extensions (Size1..SizeN) size 1...size N: size of the file objects (Sc1... ScN) start clusters 1 ... start cluster N: the first cluster of the file in the sense of FAT.

This value is modeled for filesystem according to (402).

(Nc1 ofN) next cluster 1 of N: the following cluster 1 to N (M+1) the next free position in FAT on the (file system 1) (402) This method models FAT structures on filesystem for files requested by filesystem2. As a result, the placement of the files on filesystem1 is at first not fragmented.

(402a) start the iterative process, "read contents of the master directory from (filesystem2) (402b) determine whether start clusters are defined for the iterated content. (402c) modeling (filesystem1) over the area with iterated content (402d) terminate the iterative process, "read contents of the master directory from

(filesystem2) (405) gualification of the FAT changes (StateNow) actual state: current state of the FAT on file system 1 (StateNow-1) previous state of FAT on filesystem1 (ScN) start cluster N: the first cluster of the file in the sense of FAT N

33 EP 3912 021 (Nc10fN) next cluster 1 of N: the following cluster 1 to N (LcofN) last cluster of N: the last cluster on N (Free) free: unoccupied sector (M+1) the next free position in FAT on (filesystem1) (Last) last section: the position of the held sector (OualifiedDifferenceFAT) evaluation, i.e., the result of the qualification of these changes: the difference from (StateNow) to (StateNow-1) can be described as a new chain for "Create a new file"; the new chain should start at cluster (K+M+1) and be 19 sectors (L) long. (406) qualification of the changes to the directory structure (StateNow) actual state: current state of the directory structure on file system 1 (StateNow-1) actual state 1: original state of the directory structure on file system 1 (File1), (File2), (File3), (FileN) file 1, file 2 ... file N: file names of the file objects, corresponding to the entries in the directory structure, from 1 to N (Ext1), (Ext2), (Ext3), (ExttN) extension 1 ... extension N: file object extensions, corresponding to entries in the directory structure, from 1 to N (Size1),(Size2), (Size3),(SizeN) size 1 ... size N: size of the file objects, corresponding to entries in the directory structure, from 1 to N (Sc1),(Sc2),(Sc3),(ScN), (Sc N+1) start cluster values of the file objects, corresponding to the entries in the directory structure, from 1 to N+1 (OualifiedDifferenceDir) result of the gualification of these changes: the difference from (StateNow) to (StateNow-1) can be described as a new file creation operation; the new file is named XXX with extension ABC, starts at (SC N+1), and has length 19*512 bytes. (404) determination of the association of user data with the files (ScN) start cluster

N: the first cluster of the file in the sense of FAT N

34 EP 3 912 021 (Nc10fN) next cluster 1 of N: the following cluster 1 to N (LcofN) last cluster of N: the last cluster on N (M+1) the next free position in FAT on the (file system 1) (Free) free: unoccupied sector (Last) last sector: the position of the held sector (Range) range: sectors occupied by the file system (Filesystem1) file system 1 (OFFSET) offset: next to the segment portion, the second component (integer value) in a memory address (Size1) size 1: size of file object (File1_fs2) file 1 on file system 2 (File1_fs2) file 1 on file system 2 (Ext1), (Ext2), (Ext3), (ExttN) extension 1...extension N: file object extensions, (Size1),(Size2), (Size3),(SizeN) size 1 ... size N: size of the file object —(File1), (File2), (File3), (FileN) file 1...file N: file names of the file objects

Claims (15)

1 EP3 912 021 TIEDOSTOJARJESTELMIEN YHTEENSOPIVUUDEN DYNAAMINEN MUODOSTAMINEN REAALIAJASSA PATENTTIVAATIMUKSET1 EP3 912 021 DYNAMIC FORMULATION OF COMPATIBILITY OF FILE SYSTEMS IN REAL TIME PATENT CLAIMS 1. Menetelmä tiedostojärjestelmien yhteensopivuuden muodostamiseksi dynaamisestija tietoihin pääsemiseksi tiedostojärjestelmästä riippumattomasti reaaliajassa, joka menetelmä käsittää seuraavaa: - myönnetään pääsy (100) passiivisen datamuistin tiedostojärjestelmään aktiiviselle päätelaitteelle ja mallinnuslaitteelle (M), joka on kytketty passiivisen datamuistin ja aktiivisen päätelaitteen väliin kommunikatiivisesti; - vastaanotetaan (101) pääsypyyntö aktiiviselta päätelaitteelta mallinnuslaitteella (M), jolloin pääsypyyntö määrittelee pääsytiedot ja pääsytoiminnot passiiviseen datamuistiin; - tunnistetaan (102) passiivisen tietovälineen tiedostojärjestelmä mallinnuslaitteella (M); - valitaan (103) tallennetut pääsysäännöt, jotka soveltuvat suorittamaan pääsypyynnön passiivisen datamuistin tunnistetun (102) tiedostojärjestelmän mukaisesti; - sovelletaan (104) valittuja pääsysääntöjä pääsytietoihin mallinnuslaitteella (M), jotka on määritelty pääsypyynnössä, jolloin pääsysäännöt kuvaavat pääsypyynnön sellaisena kuin se on luotu aktiivisen päätelaitteen tiedostojärjestelmällä passiivisen datamuistin tiedostojärjestelmään; ja - suoritetaan (105) pääsytoiminnot pääsypyynnön mukaisesti.1. A method for establishing compatibility of file systems dynamically and accessing data independently of the file system in real time, which method comprises the following: - granting access (100) to the file system of the passive data memory to the active terminal device and the modeling device (M), which is communicatively connected between the passive data memory and the active terminal device; - an access request is received (101) from an active terminal with a modeling device (M), whereby the access request defines the access information and access functions to the passive data memory; - the file system of the passive data medium is identified (102) with the modeling device (M); - selecting (103) the stored access rules suitable for executing the access request according to the identified (102) file system of the passive data memory; - apply (104) the selected access rules to the access data with the modeling device (M) defined in the access request, where the access rules describe the access request as created by the file system of the active terminal to the file system of the passive data memory; and - performing (105) access operations in accordance with the access request. 2. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että pääsyn myöntäminen (100) käsittää käynnistyssektorien tunnistamisen, asennusprosessin, passiivisen tietovälineen integroinnin mallinnuslaitteeseen (M), passiivisen tietovälineen integroinnin aktiiviseen päätelaitteeseen, kommunikatiivisen kytkennän, vähintään yhden plug-in-yhteyden muodostamisen, pääsyn mahdollistamisen, käyttöoikeuksien ja/tai tiedonsiirron asettamisen.2. The method according to claim 1, characterized in that the granting of access (100) comprises the identification of boot sectors, the installation process, integration of the passive data medium into the modeling device (M), integration of the passive data medium into the active terminal device, communicative connection, establishing at least one plug-in connection, enabling access , setting user rights and/or data transfer. 2 EP3 912 0212 EP3 912 021 3. Patenttivaatimuksen 1 tai 2 mukainen menetelmä, tunnettu siitä, että aktiivisella päätelaitteella on käyttöjärjestelmä, joka luo pääsypyynnön.3. The method according to claim 1 or 2, characterized in that the active terminal has an operating system that creates an access request. 4. Patenttivaatimuksen 3 mukainen menetelmä, tunnettu siitä, että soveltaminen (104) ja suorittaminen (105) suoritetaan iteratiivisesti kullekin datavirralle, jolloin käyttöjärjestelmä määrittelee datavirran.4. The method according to claim 3, characterized in that the application (104) and execution (105) are performed iteratively for each data stream, whereby the operating system defines the data stream. 5. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että pääsypyynnössä on vähintään yksi luku- ja/tai kirjoituspyyntö.5. A method according to one of the preceding claims, characterized in that the access request contains at least one read and/or write request. 6. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että pääsypyyntö määrittelee käyttäjätietoja ja/tai lisätietoja.6. A method according to one of the preceding claims, characterized in that the access request defines user data and/or additional information. 7. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että pääsytiedot kuvaavat tiedostonimiä, absoluuttisia muistiosoitteita, suhteellisia muistiosoitteita, tiedostotyyppejä ja/tai tiedosto- ominaisuuksia.7. A method according to one of the preceding claims, characterized in that the access information describes file names, absolute memory addresses, relative memory addresses, file types and/or file properties. 8. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että pääsytoiminnot kuvaavat luku- ja/tai kirjoitustoimintoja.8. A method according to one of the preceding claims, characterized in that the access operations describe reading and/or writing operations. 9. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että pääsysäännöt kuvaavat modulaatiotoimintoja, jotka määrittelevät kuinka pääsytietojen lisätiedot tulee mallintaa siten, että pääsytiedot — luetaan ja/tai kirjoitetaan tiedostojärjestelmän mukaisesti.9. A method according to one of the preceding claims, characterized in that the access rules describe modulation functions that define how the additional information of the access data should be modeled so that the access data — is read and/or written according to the file system. 10. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että pääsysäännöt kuvaavat, kuinka tiedot kirjoitetaan toiseen tiedostojärjestelmään ja/tai luetaan toisesta tiedostojärjestelmästä ensimmäisen tiedostojärjestelmän mukaisesti.10. The method according to one of the preceding claims, characterized in that the access rules describe how data is written to the second file system and/or read from the second file system according to the first file system. 11. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että tiedostojärjestelmän tunnistaminen (102) käsittää käynnistyssektorien tunnistamisen.11. The method according to one of the preceding claims, characterized in that the identification of the file system (102) comprises the identification of boot sectors. 3 EP3 912 0213 EP3 912 021 12. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että kirjoitustoimintojen suorittaminen (105) pääsypyynnön mukaisesti jakaa vastaavan tiedoston vähintään kahdeksi yksittäiseksi tiedostoksi, kun tiedostojärjestelmä rajoittaa tiedostokokoa.12. The method according to one of the preceding claims, characterized in that the execution of writing operations (105) in accordance with the access request divides the corresponding file into at least two individual files when the file system limits the file size. 13. Mallinnuslaite (M), joka voidaan asettaa passiivisen datamuistin ja aktiivisen päätelaitteen väliin kommunikatiivisesti ja joka on järjestetty sallimaan aktiiviselle päätelaitteelle pääsy (100) passiivisen datamuistin tiedostojärjestelmään, jolloin mallinnuslaite (M) on lisäksi järjestetty vastaanottamaan (101) pääsypyyntö aktiiviselta päätelaitteelta, jolloin pääsypyyntö — määrittelee pääsytiedot ja pääsytoiminnot passiiviseen datamuistiin, ja on lisäksi järjestetty tunnistamaan (102) passiivisen tietovälineen tiedostojärjestelmä, ja on lisäksi järjestetty valitsemaan (103) tallennetut pääsysäännöt, jotka soveltuvat suorittamaan pääsypyynnön passiivisen datamuistin tunnistetun (102) tiedostojärjestelmän mukaisesti, ja mallinnuslaite (M) on lisäksi järjestetty soveltamaan (104) valittuja pääsysääntöjä pääsypyynnön määrittämiin pääsytietoihin, jolloin pääsysäännöt kuvaavat pääsypyynnön sellaisena kuin se on luotu aktiivisen päätelaitteen tiedostojärjestelmällä passiivisen datamuistin tiedostojärjestelmään; ja on lisäksi järjestetty saamaan aikaan pääsytoimintojen suoritus (105) pääsypyynnön mukaisesti.13. Modeling device (M) which can be placed between the passive data memory and the active terminal device communicatively and which is arranged to allow the active terminal device to access (100) the file system of the passive data memory, in which case the modeling device (M) is additionally arranged to receive (101) an access request from the active terminal device, in which case the access request — defines the access information and access operations to the passive data storage, and is further arranged to identify (102) the file system of the passive data medium, and is further arranged to select (103) the stored access rules suitable for executing the access request according to the identified (102) file system of the passive data storage, and the modeling device (M) is further arranged to apply (104) selected access rules to the access data specified by the access request, wherein the access rules describe the access request as created by the file system of the active terminal to the file system of the passive data memory; and is further arranged to cause access operations to be performed (105) in accordance with the access request. 14. Järjestelmäjärjestely tiedostojärjestelmien yhteensopivuuden muodostamiseksi ja pääsyn sallimiseksi tietoihin tiedostojärjestelmästä riippumattomasti reaaliajassa, sisältäen seuraavat: - vähintään yksi liitäntäyksikkö, joka on järjestetty sallimaan pääsy (100) passiivisen datamuistin tiedostojärjestelmään aktiiviselle päätelaitteelle ja mallinnuslaitteelle (M), joka on kytketty passiivisen datamuistin ja aktiivisen päätelaitteen välille kommunikatiivisesti; - mallinnuslaite (M), joka on järjestetty vastaanottamaan (101) pääsypyyntö aktiiviselta päätelaitteelta, jolloin pääsypyyntö määrittelee pääsytiedot ja pääsytoiminnot passiiviseen datamuistiin; - mallinnuslaite (M) on järjestetty tunnistamaan (102) passiivisen tietovälineen tiedostojärjestelmä;14. System arrangement for making file systems compatible and allowing access to data independently of the file system in real time, including the following: - at least one interface unit arranged to allow access (100) to the file system of the passive data memory for the active terminal device and the modeling device (M) connected between the passive data memory and the active terminal device communicatively; - a modeling device (M) which is arranged to receive (101) an access request from an active terminal device, whereby the access request defines the access information and access operations to the passive data memory; - the modeling device (M) is arranged to identify (102) the file system of the passive data medium; 4 EP3 912 021 - tietokantayksikkö, joka on järjestetty valitsemaan (103) tallennetut pääsysäännöt, jotka soveltuvat suorittamaan pääsypyynnön passiivisen datamuistin tunnistetun (102) tiedostojärjestelmän mukaisesti; - mallinnuslaite (M) on järjestetty soveltamaan (104) valittuja pääsysääntöjä pääsytietoihin, jotka on määritelty pääsypyynnössä, jolloin pääsysäännöt kuvaavat pääsypyynnön sellaisena kuin se on luotu aktiivisen päätelaitteen tiedostojärjestelmällä passiivisen datamuistin tiedostojärjestelmään; ja - passiivinen datamuisti, joka on järjestetty suorittamaan (105) pääsytoiminnot pääsypyynnön mukaisesti.4 EP3 912 021 - a database unit arranged to select (103) stored access rules suitable for executing an access request according to the identified (102) file system of the passive data memory; - the modeling device (M) is arranged to apply (104) selected access rules to the access data defined in the access request, the access rules describing the access request as it was created by the file system of the active terminal to the file system of the passive data memory; and - a passive data memory arranged to perform (105) access operations according to the access request. 15. Tietokoneohjelmatuote, jossa on ohjauskäskyjä, jotka tietokoneella suoritettuina suorittavat jonkin patenttivaatimuksista 1-12 mukaisen menetelmän.15. A computer program product with control commands which, when executed on a computer, perform a method according to one of claims 1-12.