Apparatus and method for storing time-series data in an in-memory key-value database

Abstract

The present disclosure relates to a receiver-apparatus comprising a receiver-data-interface to an in-memory key-value database and receiver-processing-circuitry. The receiver-processing- circuitry is configured to access the in-memory key-value database and provide one or more keys to the in-memory key-value database for retrieval of one or more respective string-datasets. Each string-dataset corresponds to a string datatype. The receiver-processing-circuitry is further configured to receive the one or more string-datasets from the in-memory key -value database via the receiver-data-interface and to convert each string-dataset from the string datatype to an array datatype. One or more data arrays are obtained with at least one of the data arrays comprising one or more previously generated timestamps. Each timestamp specifies an event related to one or more previously generated data-array-elements within the one or more data arrays. The receiving-processing-circuitry is further configured to use one or more of the data arrays for time-series data processing.

Description

[0001] APPARATUS AND METHOD FOR STORING TIME-SERIES DATA IN AN IN-MEMORY KEY- VALUE DATABASE

[0002] Field

[0003] The present disclosure relates to apparatuses, methods, and a system for storing time-series data in an in-memory key-value database.

[0004] Background

[0005] Many technological applications use models for detection and estimation of risk. In certain applications, risk estimation is time-sensitive and needs to be calculated quickly, often in less than 500 ms. The risk models may also rely on historical data of a specific case (e.g. a certain environment, a certain user, etc.), with the data structured in a time-series format (e.g., using timestamps). Furthermore, risk models often make use of specific data from a large volume that cannot be stored locally. To allow fast access to externally stored time-series data, inmemory key-value databases may be used, where time-series data can be quickly accessed using a reference key and applied for data processing. However, the types of data that can be represented in a time-series format and used for a wide variety of applications are often limited to numerical data (up to 64bit) and aggregation functions. For example, string data, GNSS coordinates or binary blobs cannot be stored or aggregated in a classic time-series format that use simpler approaches to time-series data storage. The advantages related to speed of data access offered by in-memory key-value databases are also limited only to certain types of time-series data.

[0006] Thus, there is a demand for improving storage and access of time-series data for a variety of data structures and formats.

[0007] Summary

[0008] This demand is satisfied by the subject matter of the independent claims. Further beneficial embodiments are given by the dependent claims. According to a first aspect, the present disclosure relates to a receiver-apparatus. The receiverapparatus comprises a receiver-data-interface to an in-memory key-value database, as well as receiver-processing-circuitry. The receiver-processing-circuitry is configured to access the inmemory key-value database and provide one or more keys to the in-memory key-value database for retrieval of one or more respective string-datasets. Each string-dataset corresponds to a string datatype. The receiver-processing-circuitry is further configured to receive the one or more string-datasets from the in-memory key-value database via the receiver-data-interface and to convert each string-dataset from the string datatype to an array datatype. One or more data arrays are obtained with at least one of the data arrays comprising one or more previously generated timestamps. Each timestamp specifies an event related to one or more previously generated data-array-elements within the one or more data arrays. The receiving-processing- circuitry is further configured to use one or more of the data arrays for time-series data processing.

[0009] According to a second aspect, the present disclosure relates to a receiving-method. The receiving-method includes accessing the in-memory key-value database and providing one or more keys to the in-memory key-value database for retrieval of one or more respective string-datasets. Each string-dataset corresponds to a string datatype. The receiving-method further includes receiving the one or more string-datasets from the in-memory key-value database via the receiver-data-interface and converting each string-dataset from the string datatype to an array datatype. One or more data arrays are obtained. At least one of the data arrays comprises one or more previously generated timestamps. Each timestamp specifies an event related to one or more previously generated data-array-elements within the one or more data arrays. The receiving-method further includes using one or more of the data arrays for time-series data processing.

[0010] According to a third aspect, the present disclosure relates to a sender-apparatus. The senderapparatus comprises a sender-data-interface to an in-memory key -value database, as well as sender-processing-circuitry. The sender-processing-circuitry is configured to obtain one or more data arrays, a new timestamp, and one or more new data-array-elements to be appended. The new timestamp specifies an event related to the one or more new data-array-elements. The sender-processing-circuitry is further configured to append the new timestamp to one of the data arrays and append each new data-array-element to one of the data arrays. The sender- processing-circuitry is further configured to convert each data array to a string datatype for obtaining one or more string-datasets corresponding to the string datatype. Furthermore, the sender-processing-circuitry is configured to send each string-dataset with a respective key to the in-memory key -value database via the sender-data-interface.

[0011] According to a fourth aspect, the present disclosure relates to a sending method. The sendingmethod includes obtaining one or more data arrays, a new timestamp, and one or more new data-array-elements to be appended. The new timestamp specifies an event related to the one or more new data-array-elements. The sending-method further includes appending the new timestamp to one of the data arrays and appending each new data-array-element to one of the data arrays. The sending-method further includes converting each data array to a string datatype for obtaining one or more string-datasets corresponding to the string datatype. Furthermore, the sending-method includes sending each string-dataset with a respective key to the in-memory key -value database via the sender-data-interface.

[0012] According to a fifth aspect, the present disclosure relates to a system. The system comprises a sender-apparatus, a server, and a receiver-apparatus. The sender-apparatus comprises a sender-data-interface to an in-memory key-value database and sender-processing-circuitry. The sender-processing-circuitry is configured to obtain one or more data arrays, a new timestamp, and one or more new data-array-elements to be appended. The new timestamp specifies an event related to the one or more new data-array-elements. The sender-processing- circuitry is further configured to append the new timestamp to one of the data arrays and append each new data-array-element to one of the data arrays. The sender-processing-circuitry is further configured to convert each data array to a string datatype for obtaining one or more string-datasets corresponding to the string datatype. Furthermore, the sending-processing-cir- cuitry is configured to send each string-dataset with a respective key to the in-memory keyvalue database via the sender-data-interface.

[0013] The server comprises the in-memory key-value database and server-processing-circuitry configured to receive the one or more string-datasets and the respective keys from the senderapparatus and to store the one or more string-datasets and the respective keys in the in-memory key-value database. Furthermore, the server-processing-circuitry is configured to receive from the receiver-apparatus one or more commands referencing the respective keys of the one or more string-datasets, and to send the one or more string-datasets to the receiver-apparatus in response to the one or more commands.

[0014] The receiver-apparatus comprises a receiver-data-interface to the in-memory key -value database and receiver-processing-circuitry. The receiver-processing-circuitry is configured to access the in-memory key -value database and to provide the one or more respective keys to the in-memory key-value database for retrieval of the one or more string-datasets. The receiver- processing-circuitry is further configured to receive the one or more string-datasets from the in-memory key-value database via the receiver-data-interface and to convert each string-dataset from the string datatype to an array datatype. The one or more data arrays are obtained, Furthermore, the receiver-processing-circuitry is configured to use one or more of the data arrays for time-series data processing.

[0015] Brief description of the Figures

[0016] Some examples of apparatuses and / or methods will be described in the following by way of example only, and with reference to the accompanying figures, in which:

[0017] Fig. 1A schematically illustrates an exemplary receiver-apparatus for receiving one or more string-datasets from an in-memory key-value database;

[0018] Fig. IB schematically illustrates an exemplary sender-apparatus for sending one or more string-datasets to an in-memory key -value database;

[0019] Fig. 2 depicts exemplary complementary features of a sender-data-interface and a receiver-data-interface;

[0020] Fig. 3 schematically illustrates an exemplary send-receive-apparatus for sending one or more string-datasets to an in-memory key-value database, as well as receiving one or more string-datasets from the in-memory key -value database; Fig. 4 illustrates a plurality of send-receive apparatuses, each communicatively connectable to an in-memory key -value database for sending and receiving one or more string-datasets;

[0021] Fig. 5 illustrates an exemplary collection of previously and newly generated data-ar- ray-elements in an embodiment of appending multiple data arrays;

[0022] Fig. 6 illustrates for a subsequent iteration of appending data an exemplary collection of previously and newly generated data-array-elements in an embodiment of appending multiple data arrays;

[0023] Fig. 7 illustrates an exemplary collection of previously and newly generated data-array-elements in an embodiment of appending a single data array;

[0024] Fig. 8 illustrates for a subsequent iteration of appending data an exemplary collection of previously and newly generated data-array-elements in an embodiment of appending a single data array;

[0025] Fig. 9 illustrates a flow chart of an exemplary receiving-method for receiving a stringdataset from an in-memory key -value database; and

[0026] Fig. 10 illustrates a flow chart of an exemplary sending-method for sending a stringdataset from an in-memory key -value database.

[0027] Detailed Description

[0028] Some examples are now described in more detail with reference to the enclosed figures. However, other possible examples are not limited to the features of these embodiments described in detail. Other examples may include modifications of the features as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe certain examples should not be restrictive of further possible examples. Throughout the description of the figures same or similar reference numerals refer to same or similar elements and / or features, which may be identical or implemented in a modified form while providing the same or a similar function. The thickness of lines, layers and / or areas in the figures may also be exaggerated for clarification.

[0029] When two elements A and B are combined using an “or”, this is to be understood as disclosing all possible combinations, i.e. only A, only B as well as A and B, unless expressly defined otherwise in the individual case. As an alternative wording for the same combinations, "at least one of A and B" or "A and / or B" may be used. This applies equivalently to combinations of more than two elements.

[0030] If a singular form, such as “a”, “an” and “the” is used and the use of only a single element is not defined as mandatory either explicitly or implicitly, further examples may also use several elements to implement the same function. If a function is described below as implemented using multiple elements, further examples may implement the same function using a single element or a single processing entity. It is further understood that the terms "include", "including", "comprise" and / or "comprising", when used, describe the presence of the specified features, integers, steps, operations, processes, elements, components and / or a group thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and / or a group thereof.

[0031] The present disclosure relates to apparatuses, methods, and systems for sending and receiving time-series data to an external database. Generally, time-series data may refer to any sequence of datapoints collected and recorded at specified times or time intervals, and are also organized and labeled as such. Time-series data may capture changes in a particular metric or variable over time, which may enable analysis, forecasting, and trend identification for technological applications. Certain applications using time-series data may require storing large volumes of data, where only a small portion thereof may be needed at specific times. Furthermore, the applications may be highly time-sensitive and it may be necessary to access certain stored data in a very short time frame (e.g., on the order of milliseconds). For an external storage of data that is quickly accessible, a connection to a server hosting a key -value database may be established and maintained. Key -value databases are a type of NoSQL (Not only Structured Query Language) database. In contrast to SQL databases, where data is conventionally stored in structured tables of rows and columns and queried using standardized SQL language, NoSQL databases are designed to handle a larger variety of data models, structures, and types. This may provide greater flexibility and scalability without constraints of a fixed schema, which may also enable faster data access. In a key-value system, data is treated as a unified collection that is non-transparent (i.e. with hidden or complex features), where each record within the collection can have varying attributes. In other words, a fixed structure is not enforced for every value in the system, which may provide a much greater flexibility. Furthermore, since optional values are not represented by place holders or input parameters as in most relational databases, key -value databases may use significantly less memory.

[0032] The key-value database, generally, is a data storage paradigm for storing, retrieving, and managing associative arrays with a data structure commonly known as a dictionary or a hash table. More specifically, key-value databases store data in a simple key-value format. Each piece of data (i.e. value) is associated with a unique key to form a key-value pair. In an exemplary keyvalue pair, the key may be a descriptor of the value (e.g., name, age, etc.), while the value may be data associated with the descriptor (e.g., Alice, 32, etc.). Unlike prior relational databases (e.g., SQL) storing data in defined tables and columns, a key-value database instead uses individual or combinations of keys to retrieve associated values. These values can be anything from simple datatypes like strings or integers to complex objects with multiple nested values. Each key is a unique identifier that maps to a value or a location of data being stored. Configurations of keys and their associated values may be adapted for efficient data management. As such, key-value databases are versatile and can handle various datatypes and data structures, making them suitable for a wide range of use cases.

[0033] Furthermore, in-memory key -value databases may be used, for which all data is stored in RAM (random access memory), rather than on disk. This provides a significant improvement in performance of read and write operations. By storing data in RAM, response times for data retrieval are maintained at a consistently low level (i.e. low latency). In many cases, RAM may be 50 times faster for sequential data reads compared to on disk storage. Thus, for applications requiring an external storage of quickly accessible data, in-memory key-value databases may offer a highly advantageous means for quickly accessing data. For example, the in-memory key-value database platform may be a Redis database, among other possibilities. Redis, also known as remote dictionary server, is an open-source inmemory data structure store that is used as a distributed, in-memory key database, as well as a cache and message broker. In particular, Redis supports various types of data structures, including strings, lists, maps, sets, sorted sets, bitmaps, streams, and spatial indices, among others. Further examples of in-memory key -value databases may include Memcached, Aerospike, Couchbase, and Tarantool, among others.

[0034] While (in-memory) key-value databases offer greater flexibility in the range of datatypes and data structures to be stored, they may not be optimal or even functional for certain forms of time-series data. In some cases, the datatypes and / or data structures that may be used for timeseries data may be limited by the architecture and features of the chosen key-value database. Conversion of the time-series data (i.e. serialization and de-serialization) to a string-dataset may enable better use of key -value databases, increasing the range of possible datatypes and structures, as well as possible aggregation forms for the time-series data, to be stored.

[0035] For example, if time-series data marked by timestamps within a dataset corresponds to multiple datatypes, data structures or formats, etc., then its conversion (i.e. serialization) to a stringdataset may enable more efficient processing according to various configurations. As will be presented, this may be performed either as a single unit or multiple units. Duplicating timestamp information of the event for each datatype or reordering of the data may no longer be necessary or reduced. Item-by-item serialization may also be avoided or reduced, as needed. Furthermore, the range of datatypes and operations that may be performed and stored using a time-series format may be free from limitation by the specifications of the key -value database platform. Generally, the data structures can be maintained in large volumes in an external database, and in a more flexible and quickly accessible manner, which can be adapted to the needs of a variety of pre-specified applications.

[0036] Furthermore, providing a definite structure to the time-series data to be stored and periodically retrieved may further enhance its long-term use. For example, a consistent dimension of arrays or subarrays may provide an organizational structure for an efficient means of comparison of various data portions. The time-series data may be arranged as a collective dataset including timestamps in one or more data arrays. Converting to and from a string format for periodic storage of such data in an in-memory key-value database may enable a streamlined, fast, and reliable means of time-series data processing. This may be particularly advantageous for highly time-sensitive technological applications.

[0037] For this, an apparatus for data conversion and sending data (with reference to Fig. IB) to an in-memory key -value database, as well as an apparatus for receiving data from the in-memory key-value database and re-converting the data (with reference to Fig. 1 A) are presented. The two apparatuses are complementary (see Fig. 2) within a system for maintaining time-series data in an external centralized location that remains quickly accessible. Such a system may meet the specific needs of technological applications that require an external storage of large volumes of time-series data and an evaluation of a certain portion thereof at a specified time, particularly within a short time span. Furthermore, an apparatus with a combined functionality of sending and converting time-series data, as well as receiving and re-converting the timeseries data is presented (see Figs. 3 and 4). Further specific details related to comparisons of certain portions of the time-series data (e.g., historic data vs. current data) are also presented (with reference to Figs. 5 to 8).

[0038] Fig. 1A schematically illustrates an exemplary receiver-apparatus 100A for receiving data from an in-memory key-value database. The receiver-apparatus 100A comprises a receiver- data-interface 104A to an in-memory key -value database, IMKV database 210, which is hosted on a server 200. The receiver-apparatus 100A may communicate with and receive data from the IMKV database 210 by means of the receiver-data-interface 104 A. The receiving- data-interface 104A may define how data (e.g., time-series data) is organized and exchanged between the receiver-apparatus 100 A and the IMKV database 210, which may include acceptable data formats, communication protocols, error handling, as well as authentication and security of the data exchange. As will be explained, such formats and protocols may be particularly useful for maintaining a compatible use of the data stored in the IMKV database 210 with other apparatuses (e.g., sender-apparatus 100B of Fig. IB) that also comprise an analogous data interface with similar or equivalent formats and protocols for communication with the IMKV database 210. The receiver-apparatus 100A further comprises receiver-processing-circuitry 102A. For example, the receiver-processing-circuitry 102 A may be a single dedicated processor, a single shared processor, or a plurality of individual processors, some of which or all of which may be shared. Alternatively, the receiver-processing-circuitry 102 A may be a digital signal processor (DSP) hardware, an application specific integrated circuit (ASIC), a neuromorphic processor or a field programmable gate array (FPGA). The receiver-processing-circuitry 102A may optionally be coupled to, e.g., read only memory (ROM) for storing software, random access memory (RAM) and / or non-volatile memory. Optionally, the receiver-apparatus 102A may comprise further circuitry.

[0039] The receiver-apparatus 100A may further comprise a receiver-application-processing-unit, or receiver- APU 300 A, shown as part of the receiver-processing-circuitry 102 A. The receiver- APU 300 A may be configured as necessary to perform a pre-specified technological application making use of time-series data (e.g., time-sensitive data evaluation, pattern detection, risk estimation etc.). Alternatively, the receiver-APU 300A may be an extension of the receiver- processing-circuitry 102A, but located externally with a communication and / or electronic connection. In either case, the features of the receiver-apparatus 100 A as presented herein may enable providing previously generated time-series data from the IMKV database 210 for timeseries data processing, such as for a comparison of historical time-series data with a current iteration of time-series data.

[0040] For this, the receiver-processing-circuitry 102A is configured to access the IMKV database 210 and to provide one or more keys 108 to the IMKV database 210 for retrieval of one or more desired string-datasets 110. While only one string dataset 110 and one key 108 are depicted, multiple desired string-datasets 110 may be obtained using a plurality of respective keys 108. Furthermore, the receiver-processing-circuitry 102A is configured to receive each string-dataset 110 from the IMKV database 210 via the receiver-data-interface 104 A.

[0041] The accessing of the IMKV database 210 may include establishing a connection with the server 200 of the IMKV database 210. The established connection may enable an interaction with the IMKV database 210 for specifying the one or more desired string-datasets 110. While establishing a connection, the receiver-processing-circuitry 102A may specify an IP address, port, and other connection parameters corresponding to the server 200. Authentication mechanisms may also be used to ensure only authorized access. Various access methods and programming languages may be used for establishing the connection. For example, languages such as Python, Java, Node.j s, etc. may be used for a suitable development environment, which may enable installation of necessary tools, IDEs, and packages. A package manager (e.g., pip for Python, Maven for Java, or npm for Node.j s) may be used to install a client library corresponding to a selected programming language, which may be used to facilitate communication between the receiver-processing-circuitry 102A and the IMKV database 210.

[0042] The one or more keys 108 may be provided in one or more commands. Generally, the command may also be referred to as a request, query, or instruction, etc. The command provided for retrieval of each string-dataset 110 may be in a format specified for the IMKV database 210. For example, for the case of the IMKV database 210 being a Redis database, the command may be a ‘get’ command, which may be specified for a certain key. The ‘get’ command may be used by a variety of programming languages for retrieval of the string dataset 110 from a Redis database. Other IMKV databases may also apply the ‘get’ command or other similar commands may be used (e.g., ‘get-item’, ‘getMap’, etc.). Furthermore, a ‘multi-get’ command or similar versions thereof may be used for providing multiple keys and retrieving multiple string-datasets 110 simultaneously.

[0043] By providing the command in association with a specific key, a protocol may be initiated for the IMKV database 210 to process the command. The key 108 may provide the necessary information to retrieve the respective dataset (i.e. the string-dataset 110). By storing the key 108 locally and / or in an external accessible location, it may be ensured that the key 108 remains available for use, as necessary. Furthermore, by storing the key 108 in the IMKV database 210, the respective dataset corresponding to the key 108 remains accessible. Each key 108 may be labeled in a certain way to provide information about the respective string-dataset 110 for easy reference. In some embodiments, a separate key -tracking system for external tracking may be maintained (i.e. maintenance of keys in an external location). Each data array may have its key -value information for the IMKV database 210 stored in the separate keytracking system, which can be separately accessed to obtain the key, enabling an appropriate command to the IMKV database 210. Generally, methods for providing commands to the IMKV database 210 may rely on a predefined system of data access using key -values, such as naming and re-naming schemes, etc. (discussed in greater detail with reference to Fig. 2). The string-dataset 110 is specified to correspond to a string datatype. While the key may be of various datatypes, including a string datatype (e.g., for readability), it is specified for the present disclosure that the data being accessed from the IMKV database 210 (e.g., the value corresponding to the key) is of a string datatype. It is further specified that the receiver-processing-circuitry 102A is configured to convert each of the one or more string-datasets 110 from the string datatype to an array datatype for obtaining one or more data arrays 112.

[0044] More information related to string datatypes and array datatypes, as well as the conversion and re-conversion process (i.e. serialization and de-serialization) is provided with reference to Fig. 2. Each string-dataset 110 corresponds to a data array comprising time-series data, which may be organized according to a pre-specified structure. This may take the form of a single data array 112 (as shown in Figs. 7 and 8) or multiple data arrays (shown in Figs. 5 and 6).

[0045] The time-series data of the one or more data arrays 112 comprises one or more previously generated timestamps. Generally, the timestamp may be data within the timestamp-array-ele- ment representing a specific point in time (e.g., a date and time of day). The timestamp may be used as a reference for when exactly data was generated. The timestamp may include a year, month, day, hour, minute, second, and may also include more precise units, such as milliseconds or microseconds. The timestamp may follow a certain timestamp form, such as the ISO 8601 Format, the RFC 2822 Format, the UNIX timestamp, among others, such as a customized format.

[0046] In a configuration with multiple data arrays, the one or more timestamps may also be within a single data array (e.g., a timestamp data array) or distributed throughout multiple data arrays (e.g., a timestamp-array-element for each data array). The multiple data arrays, for such embodiments, may have a common association, such as a set of sensors measuring a common environment or a set of devices obtaining inputs from a common user, etc.

[0047] Furthermore, the one or more data arrays 112 comprise one or more previously generated data- array-elements. Each timestamp specifies a time of an event related to the one or more data- array-elements (e.g., time of a sensor measurement, time of a recording, etc.). The data-array- elements may also be organized in a single data-array 112 (either with the timestamps in the same data array or separate from the timestamps in a different array) or distributed throughout multiple data arrays 112. Various configurations are possible to store the time-series data information including the timestamps and the corresponding data-array-elements.

[0048] Furthermore, the receiver-processing-circuitry 102A is configured to use one or more of the data arrays 112 after obtaining and de-converting them for time-series data processing. Generally, the one or more data arrays 112 may comprise information to be referenced or used for comparison for a pre-specified application. For example, historical data (previously generated) that has been measured and recorded according to a specific structure and / or format may need to be referenced for insight related to new measurements or calculations. The referencing and using may include further processing or computation of the previously generated data-array- elements.

[0049] For comparison to the previously generated data, the receiver-processing-circuitry may be configured to generate a new timestamp 122-TS and new data-array-elements 122 corresponding to the new timestamp 122-TS. Similar to the previously generated data-array-elements and timestamps, the new data-array-elements 122 may be based on an input that is received at a time indicated by the new timestamp 122-TS. The one or more previously generated data- array-elements (i.e. historical data) may be compared to one or more newly generated data- array-elements (i.e. current data) following the same pre-specified structure and / or format. Specifically, each of the uses listed above may related to a highly time-sensitive application (e.g., time-sensitive data evaluation or pattern detection, risk estimation, etc.).

[0050] Once the one or more data arrays 112 have been used (referenced, compared, etc.), they may be re-converted to the string-dataset 110 and sent back to the IMKV database 210 for future reference. For this, a complementary sender-apparatus may be used. Such a sender-apparatus could obtain the data arrays 112 directly or indirectly from the receiver apparatus 100 A and send them to the IMKV database 210. Alternatively, generated data for comparison may be exclusively provided by such a sender-apparatus. In either case, it is noted that the abovedescribed features of the receiver-apparatus 100A is dependent on a previous transfer of the string-dataset 110 and its contents to the IMKV database 210 for retrieval. In this sense, the methods of accessing and conversion by the receiver-apparatus 100 A may be complementary to the sending apparatus for past and future iterations of data transfer or exchange involving the IMKV database 210. As such, a complementary sender-apparatus is presented.

[0051] Fig. IB schematically illustrates an exemplary sender-apparatus 100B for converting and sending a dataset to the IMKV database 210. The sender-apparatus 100B comprises a sender- data-interface 104B to the IMKV database 210. The sender-apparatus 100B, analogous to the receiver-apparatus 100 A, may communicate with and send data to the IMKV database 210 by means of the sender-data-interface 104B. The sender-data-interface 104B may likewise define how data (e.g., time-series data) is organized and exchanged between the sender-apparatus 100B and the IMKV database 210. This may analogously include pre-specified data formats, communication protocols, error handling, as well as authentication and security of the data exchange. In general, various features of the sender-data-interface 104B (e.g., predefined formats and protocols) may be equivalent and / or analogous to the features of the receiver-data- interface 104A. This may enable a compatible use of the data stored in the IMKV database 210 with the receiver apparatus 100 A and providing its associated benefits.

[0052] The sender-apparatus 100B further comprises a sender-processing-circuitry 102B, which may comprise equivalent and / or analogous features compared to the receiver-processing-circuitry 102A. Furthermore, the sender-apparatus 100B may analogously comprise a sender-application-processing-unit, or sender- APU 300B, shown as part of the sender-processing-circuitry 102B. Alternatively, the sender- APU 300B may be an extension of the sender-processing- circuitry 102B, but located externally with a communication and / or electronic connection. The features of the sender-apparatus 100B as presented herein may enable generating time-series data with a pre-specified structure and storing it in the IMKV database 210 to be retrieved by the receiver-apparatus 100A as necessary. For example, the sender-APU 300B may be configured to provide time-series data as necessary for the receiver-apparatus 100A to perform the aforementioned pre-specified application (e.g., time-sensitive data evaluation, pattern detection, risk estimation, etc.).

[0053] For this, the sender-processing-circuitry 102B is configured to obtain one or more data arrays 112, a new timestamp 122-TS, and one or more new data-array-elements 122 and to append the new timestamp 122-TS to one of the data arrays 112 and to append each new data-array- element to one of the data arrays 112. After appending, the sender-processing-circuitry 102B is configured to convert each data array 112 to a string datatype for obtaining one or more string datasets 110 (i.e. one string-dataset 110 for each data array 112) corresponding to the string datatype. The sender-processing-circuitry 102B is further configured to send each string-dataset 110 with a respective key to the IMKV database 210 via the sender-data-inter- face 104B.

[0054] The respective keys are sent to the IMKV database 210 so that the one or more string-datasets 110 may be retrieved, as discussed for the receiver-apparatus 100A. Compared to a previous iteration of using the respective key for retrieval, the keys may be the same or different. For example, the respective key may keep the same label if it is labeled by a characteristic inherent to its data array 112 that does not change over time or iterations. Alternatively, the respective key may change for each iteration or at specific iterations of data exchange.

[0055] The new timestamps and new data-array-elements being sent to the IMKV database 210 by the sender apparatus 100B and stored on the server 200 may be retrieved at a later time by the receiver apparatus 100A. In this sense, the new (i.e. newly generated) timestamps 122-TS and data-array-elements 122 may then become the previously generated timestamps 120-TS and data-array-elements 120 presented for the receiver-apparatus 100 A. Furthermore, the example of Fig. IB depicts the same data array 112 and the same string-dataset 110 of Fig. 1A. More specifically, the appended data array 112 that is sent to and stored in the IMKV database 210 as the converted string dataset 110 in Fig. IB is shown to be the same data array 112 obtained from receiving and re-converting the string dataset 110 in Fig. 1 A.

[0056] For a first iteration of appending and converting to the respective string-dataset 110, the sender-processing-circuitry 102B may be configured to generate each data array 112 and then append a first iteration of new timestamps 122-TS and new data-array-elements 122. Each data array 112 with its appended data may then be sent to the IMKV database 210 by the sender-apparatus 100B to be retrieved later by the receiver-apparatus 100 A. The comparisons performed for time-series data processing by the receiver apparatus 100 A may then involve only the first iteration of appended data. For future iterations, the sender-processing-circuitry may obtain the one or more data arrays 112 already comprising the data (which may be obtained from the receiver apparatus 100A or an intermediary device). While the receiver-apparatus 100A may be configured to generate new timestamps 122-TS and new data-array-elements 122, the sender-apparatus 100B may also be configured to do so as well. In this case, the new timestamps 122-TS and new-data-array-elements 122 may be directly transferred to the IMKV database 210 and be stored therein until being transferred to the receiver-apparatus 100A. In this sense, data may be accumulated in large amounts by sender-only stations and be used for reference at a later time for further data processing, such as a comparison to other data by the receiver-apparatus 100A.

[0057] In this sense, one or more of the obtained data arrays 112 may already comprise previously generated timestamps 120-TS and previously generated data-array-elements 120 corresponding to a respective previously generated timestamp 120-TS. For maintaining compatibility over multiple iterations of data exchange and time-series data processing, the new timestamps 122-TS and new data-array-elements 122 may be generated (e.g., by the receiver apparatus 100 A) and appended (by the sender apparatus 100B) according to a pre-specified array-element datatype, a pre-specified array-element-format, and / or a pre-specified array-element- byte-length. Maintaining a compatible structure may ensure that each of the data-array-ele- ments, previous 120 and new 122, may be generated within certain requirements for a prespecified application. This may be performed by various means, such as by a sensor input or a user input, among other possibilities. As such, new sensor inputs or new user inputs may be sent to the IMKV database 210 and become previously generated sensor or user inputs in future iterations of data exchange.

[0058] For some applications, particularly those requiring frequent iterations of data-exchange and appendage to the data arrays 112, the data arrays 112 may eventually become large in volume, requiring a large amount of memory space. In addition to appending new timestamps 122-TS and new data-array-elements 122, the sender-processing-circuitry 102B may also be configured to delete previously generated timestamps 120-TS and data-array-elements 120. For example, a respective size threshold (e.g., corresponding to a pre-specified amount of memory space) may be established for each data array 112. The sender-processing-circuitry 102B may be configured to determine if appending the data array with the new timestamps 122-TS and new data-array-elements 122 would surpass this threshold and to delete one or more previously generated timestamps 120-TS and data-array-elements 120, as necessary. Based on their complementary features, the sender-apparatus 100B enables the receiver-apparatus 100 A to make efficient use of time-series data (e.g., data array 112) by receiving it exactly at a time and in a format, as desired. The complementary features may also be configured specifically for the functionality of an IMKV database (e.g., IMKV database 210), enabling the receiver-apparatus 100 A to receive the time-series data in a very short time span (e.g., on a scale of ms). Thus, the complementary features of the receiver-apparatus 100A and the sender-apparatus 100B provide particular advantages in applications that are highly time-sensitive. More specifically, the complementary functionality of generating the time-series data by the sender-apparatus 100B to be used by the receiver-apparatus 100A may be provided by means of the respective data interfaces.

[0059] Fig. 2 depicts more specific features of the sender-data-interface 104B and the receiver-data- interface 104 A. Specifically, each data interface 104 A; 104B may include complementary features for conversion, key-generation, and validation. In one aspect, a complementary serialization may be performed for the conversion of the one or more data arrays 112 into the stringdataset 110 (e.g., a format that can be easily stored for time-series data) and re-converted using a complementary de-serialization. In a further aspect, a key corresponding to the string-dataset 110 comprising the one or more data arrays 112 may be generated, which may remain accessible and used at a later point in time to retrieve the string-dataset 110. In yet a further aspect, the respective data interfaces 104 A; 104B of the receiver-apparatus 100 A and sender-apparatus 100B may also have complementary features to perform validation procedures, ensuring that the time-series data sent and received from the IMKV database 210 is maintained to ensure its long-term reliability. Each of the complementary features may also be customized for the IMKV database 210 and for the pre-specified technological applications, as needed.

[0060] As previously described, the sender-apparatus 100B may be configured to convert (i.e. serialize) the data array 112 to the string-dataset 110 (i.e. from its original array datatype to the string datatype) and the receiver-apparatus 100 A may be configured to re-convert (i.e. deserialize) the string-dataset 110 from the string datatype back to its original array datatype. In such a configuration, a wide variety of structures and formats of the time-series data in the data array 112 may be sent, stored, and quickly retrieved from the IMKV database 210. Generally, in computer programming and data storage, a string is a fundamental datatype used to represent a sequence of characters (e.g., letters, digits, punctuation marks, spaces, etc.). The sequence of characters may be a collection of data that may be “packed” by a concatenation for enclosure into a form (e.g. string-dataset 110) that is easy to “unpack”. For simple data structures, the sequence of characters may be concatenated, such as by quotation marks. For example, an integer value (e.g., 42), a float value (e.g., 4.2), or a Boolean value (e.g., True) may be converted to a respective string (e.g., “42”, “4.2”, or “True”), or may be converted to an array or dataset comprising each of the three values as separate elements (e.g. [

[0042] , [4.2], [True] ]) in a single string (e.g. “[

[0042] , [4.2], [True] ]”). Depending on the programming language, other characters for enclosure may be used. Additionally, explicit functions or commands may be used, such as str(value) for python, value. toString() for JavaScript, and String. valueOf for Java, among others, as well as customized commands. The string expressed as a string representation may then be re-converted to its original datatype by removing the concatenation.

[0061] More complex forms of data may also be converted from its original datatype to a string datatype and re-converted back to its original datatype, also while maintaining its features and characteristics. Beyond the examples above, more complicated datatypes may include coordinates (e.g., GNSS coordinates), binary blobs (i.e. binary large objects), such as image files, audio files, video files, CAD drawings, or other various complex forms of data.

[0062] For such complex data structures, a more structured approach applying more complex tools may be required. More specifically, a serialization format may be chosen to be used for both serialization (i.e. conversion from an original form to the string-dataset 110) and de-serializa- tion (i.e. re-conversion from the string-dataset 110 back to the original form). This may be provided by a third-party serialization library, which may provide tools and functions for both processes.

[0063] Generally, different programming languages and libraries have their own methods and syntax for importing external packages. The sender-processing-circuitry 102B and receiver-processing-circuitry 102 A may be configured to import a third-party serialization library for serialization and de-serialization, respectively, each of which may include a verification of a proper (i.e. compatible) format. Examples of serialization formats may include MessagePack, Protocol Buffers, JSON (JavaScript Object Notation), or XML (extensible Markup Language), among others.

[0064] In particular, the serialization library may be a fast serialization library. Compared to a conventional serialization library, a fast serialization library may be optimized for speed by using more efficient algorithms and data structures. Examples of a fast serialization library previously mentioned include MessagePack or Protocol Buffers. Further examples include Flat- Buffers, Cap’n Proto, Avro, CBOR (Concise Binary Object Representation), BSON (Binary JSON), Thrift, ORC (Optimized Row Columnar), and Parquet, among others. Each library and format may have its particular strengths for different scenarios and use cases. In some cases, a binary format may be used to improve speed compared to text-based formats (e.g., JSON or XML). Other differences may include lower overhead, optimized code paths, cross-language support, various mechanisms for error handling, schema evolution, and pre-compiled schemas, among others.

[0065] In addition to a compatible conversion procedure, a procedure for generating a key to assign to the string-dataset 110 by the sender apparatus 100B and using the key to retrieve the stringdataset 110 by the receiver-apparatus 100A may be used. A list of keys may be maintained in an interface of the IMKV database 210, as well as in a separate apparatus communicatively connectable to both the sender-apparatus 100B and receiver apparatus 100 A. The form and label of the key may vary and may be customized for the requirements of the pre-specified technological application.

[0066] For example, a key may be generated by the sender-apparatus 100B using a predefined pattern or format that the receiver-apparatus 100A is programmed to understand, such as according to the timestamps in the data array 112. The key may also be given a label with a unique identifier based on a measurement device (e.g. sensor) or any association therewith (e.g. a particular environment measured by the sensor or a particular user using the sensor, etc.). In some embodiments, the receiver-apparatus 100 A may be programmed to search for and find relevant historical data for its technological application that is stored in the IMKV database 210 based on the labeling of the key. In other words, the key for a relevant data array (e.g., 112) may be stored or may be found based on its labeling scheme. For example, the time-series data may be a series of temperature measurements of a surrounding environment of a temperature sensor, and the unique identifier may include an identifier of the environment and a specific time interval, which may include a year, a month or season of the year, a time of day, etc. Examples of a unique identifier of a key may be “ Sensor- A- 2021-Winter”, or “Sensor-B-2022-Summer”, etc., which may communicate that the key may be used to obtain a data array containing all measurements performed by a specific sensor within a specific time period. Such examples may also be referred to as topic-based or tag- based organization. In other examples, a user or username may be used as a unique identifier.

[0067] Further complementary features may include a validation of the time-series data before converting and sending the data by the sender-apparatus 100B and another validation after receiving and re-converting the data by the receiver-apparatus 100 A. In some embodiments, each apparatus may comprise a respective application programming interface for validating the time-series data. For example, the sender-data-interface 104B may comprise a sender-API for validating the conversion (i.e. serialization) of the data array 112 to the string-dataset 110. This may ensure a pre-specified level of quality and integrity (e.g., limitation of errors) of any data being stored in the IMKV database 210.

[0068] For example, the sender-API may be configured to validate key uniqueness, so that the timeseries data obtained by the receiver-apparatus 100 A is unique and accurate. Generally, duplicates or conflicting keys may lead to unpredictable behavior or potential data corruption. Further validations may be performed to ensure proper conversion. The data array 112 may be configured to validate the data array 112 before serialization according to a pre-specified datatype, data format, and / or byte-length, among other possibilities to ensure maintaining accurate data. Validation may also be performed after serialization to check that the string dataset 110 corresponds to a specific format and / or byte-length, etc. This may ensure acceptance and efficient processing by the IMKV database 210.

[0069] Analogously, the receiver-data-interface 104B may comprise a receiver- API, which may be configured to validate the re-converted data array 112. For example, the receiver-API may validate the string dataset 110 to ensure properly obtaining the desired data from the IMKV database 210. Furthermore, after de-serialization, the receiver-API may validate features of the data array 112. For example, the receiver-API may be configured to validate a datatype, data format, and / or byte-length, etc., of the data array 112 or of a subarray. Furthermore, one or more array elements of the subarray 112 may also be validated. This may ensure a proper comparison between newly generated subarrays and previously generated subarrays.

[0070] Further features of the sender-API and receiver- API may relate to error handling, in the case that a validation fails to meet pre-specified criteria. This may occur, for example, based on updates to the IMKV database 210 or other external causes. In the case that a dataset (meant to be the string dataset 110) does not correspond to pre-specified criteria for the string datatype, either an automated correction mechanism may be performed and validation re-at- tempted and / or a message may be sent to an external administrator for correction. In some embodiments, data sanitization (i.e. data cleansing or data scrubbing) may be performed, which may include identifying, cleaning, and / or transforming data to remove any errors, inconsistencies, inaccuracies, or potentially harmful content. As such, any data (e.g., the stringdataset 110) obtained from the IMKV database 210 by the receiver-apparatus 100 A may be assured to maintain pre-specified standards, which may include a low error level.

[0071] In addition to their compatibility, the receiver apparatus 100 A and the sender-apparatus 100B may be (directly or indirectly) communicatively connectable or may be installed within a common send-receive apparatus, as presented in Fig. 3. This may be configured as needed for enabling comparisons of new and previous data-array-elements over multiple iterations (e.g., with each iteration including a data exchange with IMKV database 210).

[0072] Fig. 3 schematically illustrates an exemplary send-receive apparatus 100C for communicating with the IMKV database 210 hosted on the server 200. The functionality of the apparatus 100C may comprise the functionality of both the receiver-apparatus 100A and the sender-apparatus 100B, including a send-receive processing circuitry 102C and a send-receive-data-interface 104C. The send-receive-apparatus 100C is provided as an example to demonstrate that the functionality related to the receiver-apparatus 100 A and the functionality related to the senderapparatus 100B may either be separated, such as within two separate apparatuses (e.g., 100A and 100B) in two separate locations, or may also be combined within a single apparatus (e.g., 100C) in a single location. As depicted, the send-receive processing circuitry 102C may be configured with compatibility for the IMKV database 210 to receive the one or more string-datasets 110 via the send-receive data interface 104C. The one or more string-datasets 110 may be re-converted (i.e. de-serial- ized) from the string datatype to the array datatype for obtaining the one or more data arrays 112 comprising previously generated timestamps 120-TS and data-array-elements 120. The previously generated data may then be used for time-series data processing by the application processing unit 300C, as presented for the receiver-apparatus 100A (by 300A). The time-series data processing may also include generation of new timestamps 122-TS and new data-array- elements 122, which may be appended to respective data arrays 112. Subsequently, the send- receive processing circuitry 102C may be configured to convert (i.e. serialize) each data array from the array datatype to the string datatype and send the one or more string-datasets 110 to the IMKV database.

[0073] For a first iteration (not depicted), the send-receive processing circuitry 102C may be configured to generate and append new timestamps 122-TS and new data-array-elements 122 to newly generated data arrays and convert and send the data arrays 112 to the IMKV database for future retrieval. This cycle may be repeated indefinitely, as depicted by the circular flow of data in Fig. 3. This may be particularly useful for a technological application that may be completed solely by the send-receive apparatus 100C, which may require storing a large volume of data and where only certain portions of the data need to be periodically retrieved, used, and updated.

[0074] While certain applications may only require a single send-receive apparatus 100C, other applications may make use of a network of multiple send-receive apparatuses 100C.

[0075] Fig. 4 presents a sharing system 400 including five send-receive apparatuses lOOC-i; lOOC-ii; lOOC-iii; lOOC-iv; 100-v. Each send-receive-apparatus is depicted as communicatively connectable (represented by its respective dashed line) to the IMKV database 210 hosted on the server 200. The depicted example may serve as a representation of a network of a much larger number of send-receive-apparatuses, each with the functionality of the send-receive-apparatus 100C. Each of the send-receive-apparatuses 100C may be configured with the functionality of the sender-apparatus 100B to send each data array 112 as a respective string dataset 110 to the IMKV database stored on the server 200. Furthermore, each send-receive apparatus 100C may be configured with the functionality of the receiver-apparatus 100 A to obtain the same data arrays from the IMKV database 210.

[0076] Instead of being limited to its own capabilities for time-series data generation, each send-re- ceive apparatus 100C in the system 400 may benefit from the capabilities of data generation associated with all send receive apparatuses (e.g., lOOC-i to lOOC-v). In other words, the newly generated data by one send-receive apparatus 100C may become part of the historical data for a future iteration of receiving the data array by any of the send-receive-apparatuses 100C of the system 400.

[0077] The system 400 may also include a plurality of receiver-apparatuses 100A and / or sender apparatuses 100B, with their respective functionalities restricted accordingly. This may be customized for the technological application as needed. For example, for generating sensor data to be referenced at a later time, it may be beneficial to have many sensor stations with the functionality of only the sender-apparatus 100B, whereas the number of receiver-apparatuses 100 A or send-receive-apparatuses 100C may be lower to save resources, among other examples. The generation of data may also be performed at varying points, such as only by the sender-apparatuses 100B or by any combination of the apparatuses 100A; 100B; 100C.

[0078] In particular the receiver-apparatuses 100 A or send-receive-apparatuses 100C obtaining the data arrays 112 may use the time-series data therein as necessary for a pre-specified application of the system 400. As previously described, certain applications may perform a comparison between one or more newly generated data-array-elements 122 (e.g., as current data) and one or more previously generated data-array-elements 120 (e.g., as historical data).

[0079] The server 200 comprising the IMKV database 210 may comprise server-processing-circuitry configured to receive the one or more string-datasets 110 from the respective send-receive- apparatus 100C and store each string-dataset 110 in the IMKV database 210. The server 200 may further be configured to receive a command including one or more keys 108 for sending one or more respective data arrays 112. Within the system 400, the string-datasets 110 are sent according to the commands including the keys independent from where the data array 112 was originally received. The details of comparisons between one or more newly generated data-array-elements 122 and previously generated data-array-elements 120 will be explained in greater depth with reference to Figs. 5 to 8. In particular, organizational schemes using a single data array (in Figs. 5 and 6) and multiple data arrays (in Figs. 7 and 8) are presented.

[0080] Fig. 5 depicts the data array 112 as comprising one or more previously generated subarrays 114-1; 114-2; 114-3. Furthermore, a newly generated subarray 114-x is shown. Each of the previously generated subarrays 114-1; 114-2; 114-3 and the newly generated subarray 114-x share a common data structure. This includes a respective timestamp TS-1; TS-2; TS-3 and TS-x, which may provide a means of organizing the subarrays as time-series data. TS-1 may be the earliest timestamp, followed by TS-2 and then TS-3. The newly generated subarray 114-x including the timestamp TS-x and the new data array elements 122 may be appended to the data array 112 as the most recent subarray.

[0081] Below each timestamp are n respective data-array-elements, shown with a first, second, and third data-array element leading toward an / / -th array element for the respective subarray 114. The first previously generated subarray 114-1 comprises n respective data-array elements, including 114-1-i, 114-1-ii, and 114-1-iii leading to 114-1-n. The analogous description applies for the second and third previously generated subarrays 114-2; 114-3, as well as the newly generated subarray 114-x.

[0082] For a more precise comparison between the newly generated subarrays and previously generated subarrays 114, data of corresponding data-array-elements may be directly compared. The data-array-elements used for comparison may comprise a common position and / or index within the respective n data-array-elements. For example, the first data-array-element 114-x-i of the newly generated subarray 114-x may be compared to the analogous first data-array- elements 114-1-i; 114-2-i; 114-3 -i of the previously generated subarrays (i.e. of a first position or index 1).

[0083] In certain programming languages, an array may be considered as a data structure comprising data of a single datatype (e.g., a NumPy array in Python). While the data array 112 may broadly correspond to an array datatype, the data array and subarrays within the data array may include data structures specified for individual data-array-elements of a certain position and / or index. The data-array-elements of various subarrays may be consistent with reference to its datatype, format, and / or byte-length for ease of comparison.

[0084] Depicted in each of the data-array-elements of position or index “i” is the “datatype A” as an example for all data-array-elements. Each of the respective n data-array-elements of a common position or index may comprise data of a pre-specified data datatype (e.g., 114-1-i; 114- 2-i; 114-3-i; 114-x-i may have a common datatype, 114-1-ii; 114-2-ii; 114-3-ii; 114-x-ii may have a common datatype, etc.). The common datatype may be an integer, a float, a Boolean, etc., or a more complex datatype, as previously described. In some embodiments, all positions or indices of a respective subarray may correspond to the same datatype, whereas in other embodiments, the datatype may vary according to the position or index.

[0085] The same may apply analogously for a “format B”. For example, each of the respective n data- array-elements of a common position or index may comprise data of a pre-specified data format (e.g., 114-1-i; 114-2-i; 114-3-i; 114-x-i may have a common data format, 114-1-ii; 114- 2-ii; 114-3-ii; 114-x-ii may have a common data format, etc.). The common data format B may be dependent on the common datatype A. For example, for an integer datatype, the common data format B may be a 32-bit-integer, a 16-bit-integer, or an 8-bit-integer. For a float datatype, the common data format B may be a single precision (32-bit) floating-point or a double precision (64-bit) floating-point. For certain datatypes, the data format B may have a default format (e.g., a default Boolean format for a Boolean datatype). In further examples, certain binary datatypes may correspond to a pre-specified binary data format, while certain text datatypes may correspond to a pre-specified text data format (e.g., plain text, JSON, XML, etc.). Other data formats may correspond to compressed or encoded data formats, which may also be customized. In some embodiments, all positions or indices correspond to the same data format, whereas in other embodiments, the data format may vary according to the position or index.

[0086] The same may also apply for a “byte-length C”. For example, each of the respective n data- array-elements of a common position or index may comprise data of a pre-specified bytelength (e.g., 114-1-i; 114-2-i; 114-3-i; 114-x-i may have a common byte-length, 114-1-ii; 114- 2-ii; 114-3-ii; 114-x-ii may have a common byte-length, etc.). In some embodiments, the bytelength may vary according to the common position or index (e.g., a byte-length of 5 bytes for index i, a byte-length of 10 bytes for index ii, etc.). In other embodiments, data-array-elements of all positions or indices comprise data of a common byte-length.

[0087] Embodiments may vary in how certain data-array-elements of a common position or index correspond to a common datatype, common data format, and / or common byte-length, etc. Other examples of properties that remain consistent (not depicted) may include a sub-data structure (e.g., a consistent structure of sub-subarrays), or a byte-order (e.g., by endianness to organize the byte order of multi-byte datatypes), among other possibilities.

[0088] The position or index n corresponding to the data array elements 114-1 -n; 114-2-n; 114-3-n; 114-x-n are depicted with an element value (element-value- 1; element-value-2; element- value-3; and element-value-x, respectively). These element values are provided as an example of how data within a data-array-element of the newly generated subarray may be compared to corresponding data of previously generated subarrays (e.g., of a corresponding data-array-el- ement with a corresponding index) for a pre-specified application. An element value of the newly generated subarray, such as element-value-x, may be compared to element-value- 1, el- ement-value-2, and / or element-value-3.

[0089] In general, any function may be performed using the data-array-elements 114-1-n, 114-2-n, and 114-3-n for the comparison with data-array-element 114-x-n. The data-array-elements 114-1-n; 114-2-n; 114-3-n may be provided as an input to such a function. The function may then provide an output based thereon, which may be used for the comparison. For example, an average may be computed based on the corresponding values (element-value- 1; element- value-2; element-value-3). Such averaging may use an arithmetic mean, geometric mean, harmonic mean, weighted average, median, and / or other aggregation functions. Particularly for larger collections of element values, various statistical methods may also be applied, such as removing outliers of the data.

[0090] In other examples, functions used for determining similarity or dissimilarity between data- array-elements 114-1-n; 114-2-n; 114-3-n of the previously generated subarrays and the analogous data-array-element 114-x-n. The similarity may be defined in terms of a distance and / or angle between points or vectors that are provided based on the values of the corresponding data-array-element. In some embodiments, data-array-elements may themselves comprise subarrays, which may be applied in such functions. Examples may include applying a Euclidean distance (measuring a geometric distance in Euclidean space), cosine similarity (measuring a cosine of the angle between two vectors), Jaccard similarity (measuring a similarity between sets of items), Hamming distance (measuring a number of differing elements between two binary strings or sequences), Manhattan distance (measuring a sum of absolute distances between corresponding elements), Minkowski distance (enabling a controlled level of emphasis on individual dimensions for Euclidean or Manhattan distances), and / or Mahalanobis distance (measuring a distance between a point and a distribution, accounting for the covariance between variables), among other examples.

[0091] Based on such functions, such as the above-presented average or similarity functions, a threshold may be computed that may serve as a basis of comparison for the corresponding value (element-value-x). Based on whether the corresponding value (element-value-x) exceeds a threshold, a pre-determined action based on the technological application (e.g., activate an alert) may be undertaken.

[0092] Generally, the basis of comparison may be any common association of data, which is labeled as an identification for the data array 112, depicted as “ID: name-1”. For example, such an association may be a pre-specified sensor. In one example previously discussed, the data array 112 may be a series of temperature measurements (among other possibilities, such as pressure, moisture, etc.) of a particular environment, as measured by the sensor. Each subarray 114-1 to 114-x may correspond to one set of such measurements. For example, the pre-specified sensor may be identified with a sensor-ID or another uniquely distinguishable feature. Alternatively, the common association may also be a pre-specified environment in which a plurality of such sensors have been configured for such measurements. For example, the data array 112 may be associated only with the environment without distinguishing which sensor measured or captured the data.

[0093] Another example of such an association is a pre-specified event within a pre-specified environment. For example, a sensor in the environment may be configured to record data for a subarray 114-1 to 114-x for each such event. This may be based on a physical phenomenon within the environment, such as a detected motion, sound, magnetic field, change in light intensity, type of gas, number of objects entering the environment etc., each of which may pass a pre-specified threshold for detection by the sensor. Applications may relate to undesired events (e.g., disturbances, pollution, etc.) or expected (periodic) events (e.g., weather changes, thunderstorms, traffic, etc.). Sensors may also be used to measure a current and / or voltage of an electronic device to maintain a record of instances of a more demanding use, among other examples. In the above-listed examples, an identification (ID) of a substance, object, or phenomenon may be maintained with a uniquely assigned data array to be stored in and periodically accessed from the IMKV database 210.

[0094] Further examples for a basis of comparison may include a common user of one or more of the apparatuses 100A; 100B; 100C or a service associated with the respective apparatus 100A; 100B; 100C. For example, the newly generated subarray 112-x and each of the previously generated subarrays 114-1; 114-2; 114-3 may each be associated with a common user. In some embodiments, the ID may be a user ID (e.g., the depicted name-1 may be a user ID, among other examples). In this case the respective timestamp of the each of the subarrays (previously or newly generated) may correspond to a respective time of an event of the user performing an action while using (being represented by) the user ID. For example, a user may log into an online account that enables the user to access a pre-specified application. Each iteration of use by the user may lead to the generation of a subarray with the data-array-elements according to a pre-specified structure, as previously discussed. In other embodiments, a common association may be a tenant (e.g., a group of users or distinct groups that share a common network infrastructure while being logistically isolated from each other), or a service, which may be related to defined tasks for users or tenants. The ID (e.g., name-1) is shown in each of Figs. 5 to 8 to demonstrate that the group of subarrays in the data array 112 or multiple data arrays have a common association as discussed above.

[0095] In some embodiments, each subarray 114-1 to 114-x may be automatically generated and appended to the data array 112. Alternatively or additionally, input may be given by an automated mechanism or as a manual input by a user. By organizing the respective data array 112 by a user, such as by a user ID for accessing an application, the functionality of the abovedescribed apparatuses 100A; 100B; 100C may be provided to serve a large group of people that can maintain a profile or a personal record according to their personal history of use. For example, many iterations of sensor data, location data, usage data, etc. may be recorded and maintained for each user. Generally, users, surveillance bodies, scientific institutions, etc. may organize data related to iterations of a pre-specified activity over a long period of time. Specifically based on the functionality applying serialization and de-serialization of the string-dataset 110, as well as sending and receiving the string-dataset 110 to and from the IMKV database 210, the comparisons and related analyses may be performed for each user, sensor, environment, etc., at a very rapid speed, making it particularly useful for highly time-sensitive applications. The unique ID may also aid in generating keys for the IMKV database 210, as previously described.

[0096] For the next iteration of activity, the newly generated subarray 114-x may be appended to the data array 112 as a fourth previously generated subarray 114-4 (as depicted in the following Fig. 6). The data array 112 may be converted again to the string-dataset 110, which may be stored in the IMKV database 210. The string-dataset 110 may remain quickly accessible from the IMKV database 210 until a following point in time arrives requiring another accessing of the data array 112.

[0097] Fig. 6 depicts a later iteration of accessing and usage of the data array 112 at a later point in time compared to the depiction of Fig. 5. The newly generated subarray 112-x of Fig. 5 was appended to the data array 112 as a fourth previously generated subarray 112-4. The newly appended data array 112 was then sent to the IMKV database 210 as the string dataset 110 to be accessed at a later point in time for a following iteration of access. In the following iteration of access (by a receiver-apparatus 100 A or a send-receive-apparatus 100C), the data array 112 with the now four subarrays may now be used in an analysis, which may offer more historical data compared to the previous iteration described in Fig. 5, particularly for a new (newly generated) subarray 114-y.

[0098] All properties of the data array, including the user ID (name-1), the first three respective timestamps and the properties of the data-array elements, such as the pre-specified datatypes, data formats, and / or byte-lengths, as described above, remain as before. The only difference is that the number of previously generated subarrays 114 within the data array 112 has grown larger based on a further usage of the pre-specified application. In a new iteration, a new (newly generated) subarray (e.g., H4-y) may be compared to the now larger data array 112. In other examples not depicted, a plurality of subarrays may be compared with the previously generated subarrays and appended in a single iteration of accessing the data array 112.

[0099] This cycle may repeat indefinitely. For certain technological applications, the volume of data stored within each subarray may be significant, which may be to a point, where only a limited number of subarrays may be added to the data array 112. There may also be other reasons for limiting the number of subarrays for each data array, such as for statistical purposes. For example, the new subarray (114-x in Fig. 4, 114-y in Fig. 5) may be appended to the data array 112 on the condition that the data array 112 is within a threshold (e.g., a size threshold). The threshold may correspond to a pre-specified amount of memory space or a pre-specified number of subarrays, among other possibilities. Other reasons may include a naming scheme, such as for generating keys. For example, subarrays for data corresponding to a certain month or year may be added until the respective month or year has ended.

[0100] In some embodiments, in addition to being appended, one or more subarrays 112-1; 112-x may also be deleted after being stored in and retrieved from the IMKV database 210. For example, the receiver apparatus 100 A may be configured to delete one or subarrays 112-1 to 112-x of the data array 112 using an automated mechanism. Additionally or alternatively, some embodiments may also use a size threshold corresponding to a pre-specified amount of memory space. If the size threshold is surpassed, one or more previously generated subarrays may be deleted before appending one or more newly generated subarrays.

[0101] The selection of a subarray for deletion may be based on a characteristic of the data within the respective subarray. For example, this may be based on the timestamp when the data was recorded. The receiver apparatus 100 A may be configured to delete one or more subarrays 114-1 to 114-x if the timestamp is of a time and date beyond a pre-specified amount of time from the current date and time (e.g., 1 month or 1 year, etc.). In other examples, one or more subarrays may be determined to be statistical outliers, which may correspond to corrupt or inaccurate data. For example, such outliers may only be detected only after further subarrays have been appended (e.g., by an averaging and comparing mechanism). In other embodiments, the information included in two or more subarrays may be included into a single subarray (e.g., by averaging) for cases where only broad trends within previously generated subarrays are necessary to maintain in the IMKV database 210. As such, subarrays may be deleted without losing the most relevant information related thereto.

[0102] Figs. 7 and 8 depict a similar organizational scheme compared to Figs. 5 and 6, but with multiple data arrays. Included are a data array for timestamps 112-TS with timestamps TS-1; TS-2; TS-3, and n data arrays 112-1; 112-2; 112-3; up to 112-n. The data and information provided by the data presented in Fig. 5 is also presented in Fig. 7. Likewise, a further iteration of appending a timestamp and n data array elements presented in Fig. 6 is also presented in Fig. 7. The difference is the use of multiple smaller data arrays 112-TS; 112-1 to 112-n compared to a single large data array 112.

[0103] For such an embodiment of multiple data arrays, each data array 112-TS and 112-1 to 112-3 may correspond to a respective string-dataset (i.e. 110-TS and 110-1 to 110-3, not depicted). Each string-dataset may be de-serialized for obtaining the respective data array 112-1 to 112- 3. The data-array-elements of a common position within each respective data array may be compared. This is in contrast to the subarray format, for which analogous data-array-elements for comparison shared a common index within each subarray.

[0104] Furthermore, when appending data, each data array 112-TS and 112-1 to 112-3 may have one respective data-array-element. For example, the new timestamp TS-x and new element-value- x in Fig. 7 may become for a future iteration the previously generated timestamp TS4 and element-value-4, as depicted in Fig. 8. Furthermore, each data array may be serialized to a respective string-dataset and sent with one or more commands to the IMKV database 210 (e.g., with multiple “get” commands or a single “multi-get” command). The process for the multiple data arrays may then be repeated for a new timestamp and new data-array-elements shown in Fig. 8 (including TS-y and element-value-y).

[0105] The pre-specified application may adopt an organizational scheme of either a single data array 112 or multiple data arrays 112-TS; 112-1 to 112-y, or a combination thereof, as needed. The embodiments presented in the figures are provided as examples to include a large variety of embodiments. Generally, the sending and receiving of the string-dataset 110 to and from the IMKV database 210, as presented herein, may be performed for multiple repetitions, with each repetition enabling a comparison for a measurement and / or computation between a current iteration of data and previous iterations of data (i.e. historical data). In each repetition, the data array(s) 112 storing the previous iterations of data may be accessed very quickly, so that the comparison may be used for highly time-sensitive applications (e.g., data evaluation, pattern recognition, risk estimation, etc.). The datatypes, formats, and byte-lengths of the time-series data, including the timestamps and data-array-elements, may be consistent with the requirements of the IMKV database 210 and organized according to a pre-specified scheme, as needed for even faster comparison. The methods that may be used for each repetition are presented in Figs. 9 and 10 for the receiver apparatus 100A and the sender apparatus 100B, respectively.

[0106] Fig- 9 illustrates a flow chart of an exemplary receiving-method 900. The receiving-method 900 includes accessing 910 the in-memory key -value database and providing 920 one or more keys to the in-memory key-value database for retrieval of one or more respective string-datasets. Each string-dataset corresponds to a string datatype. The receiving-method 900 further includes receiving 930 the one or more string-datasets from the in-memory key -value database via the receiver-data-interface and converting 940 each string-dataset from the string datatype to an array datatype. One or more data arrays are thereby obtained. At least one of the data arrays comprises one or more previously generated timestamps, with each timestamp specifying an event related to one or more previously generated data-array-elements within the one or more data arrays. The receiving-method 900 further includes using 950 one or more of the data arrays for time-series data processing.

[0107] Fig. 10 illustrates a flow chart of an exemplary sending-method 1000. The sending-method 1000 includes obtaining 1010 one or more data arrays, a new timestamp, and one or more new data-array-elements to be appended. The new timestamp specifies an event related to the one or more new data-array-elements. The sending-method 1000 further includes appending the new timestamp 1020 to one of the data arrays and appending each new data-array-element 1030 to one of the data arrays. Furthermore, the sending-method 1000 includes converting 1040 each data array to a string datatype for obtaining one or more string-datasets corresponding to the string datatype. The sending-method 1000 further includes sending 1050 each string- dataset with a respective key to the in-memory key-value database via the sender-data-inter- face.

[0108] The methods presented in Figs. 9 and 10 may optionally be expanded in accordance with the features presented for the receiver-apparatus 100 A and sender-apparatus 100B, as presented in Figs. 1 A to 4, and as further explained with regards to data format in Figs. 5 to 8.

[0109] The following examples pertain to further embodiments:

[0110] (1). A receiver-apparatus comprising a receiver-data-interface to an in-memory key-value database, and receiver-processing-circuitry configured to access the in-memory key -value database, provide one or more keys to the in-memory key -value database for retrieval of one or more respective string-datasets, each string-dataset corresponding to a string datatype, receive the one or more string-datasets from the in-memory key -value database via the receiver-data- interface, convert each string-dataset from the string datatype to an array datatype for obtaining one or more data arrays, wherein at least one of the data arrays comprises one or more previously generated timestamps, each timestamp specifying an event related to one or more previously generated data-array-elements within the one or more data arrays, and use one or more of the data arrays for time-series data processing.

[0111] (2) The receiver-apparatus of (1), wherein the receiver-processing-circuitry is configured to generate a new timestamp and one or more new data-array-elements corresponding to the new timestamp, wherein the time-series data processing includes a comparison of at least one of the new data-array-elements with one or more of the previously generated data-array-ele- ments with a common position and / or common index.

[0112] (3) The receiver-apparatus of (2), wherein each new data-array-element matches at least one previously generated data-array-element according to a pre-specified array-element- datatype, a pre-specified array-element-format, and / or a pre-specified array-element-byte- length.

[0113] (4) The receiver-apparatus of (2) to (3), wherein each new data-array-element and each previously generated data-array-element are associated with a common ID, and wherein each new timestamp and each previously generated timestamp correspond to a time of a respective event associated with the ID.

[0114] (5) The receiver-apparatus of any one of (2) to (4), wherein the receiver-processing-circuitry is configured to compare a value of one of the new data-array-elements to a threshold based on one or more of the previously generated data-array-elements corresponding to a common index and / or position, and wherein the receiver-processing-circuitry is configured to activate an alert if the value exceeds the threshold.

[0115] (6) The receiver-apparatus of any one of (1) to (5), wherein the receiver-processing-circuitry is configured to convert the one or more string-datasets from the string datatype to the array datatype by a de-serialization using a third party fast serialization library.

[0116] (7) The receiver-apparatus of any one of (1) to (6), wherein the receiver-data-interface is an application programming interface, API, and wherein each string-dataset is received from the in-memory key-value database via the API and validated by the API according to a prespecified string datatype, a pre-specified string-data-format and / or a pre-specified byte-length.

[0117] (8) A receiving-method comprising accessing the in-memory key-value database, providing one or more keys to the in-memory key -value database for retrieval of one or more respective string-datasets, each string-dataset corresponding to a string datatype, receiving the one or more string-datasets from the in-memory key -value database via the receiver-data-interface, converting each string-dataset from the string datatype to an array datatype for obtaining one or more data arrays, wherein at least one of the data arrays comprises one or more previously generated timestamps, each timestamp specifying an event related to one or more previously generated data-array-elements within the one or more data arrays, and using one or more of the data arrays for time-series data processing.

[0118] (9) A sender-apparatus, comprising a sender-data-interface to an in-memory key -value database, and sender-processing-circuitry configured to obtain one or more data arrays, a new timestamp, and one or more new data-array-elements to be appended, wherein the new timestamp specifies an event related to the one or more new data-array-elements, append the new timestamp to one of the data arrays, append each new data-array-element to one of the data arrays, convert each data array to a string datatype for obtaining one or more string-datasets corresponding to the string datatype, and send each string-dataset with a respective key to the in-memory key -value database via the sender-data-interface.

[0119] (10) The sender-apparatus of (9), wherein the new timestamp and the one or more new data- array-elements to be appended are generated according to a pre-specified array-element- datatype, a pre-specified array-element-format, and / or a pre-specified array-element-byte- length.

[0120] (11) The sender-apparatus of (9) or (10), wherein the sender-processing-circuitry is configured to generate the new timestamp and the one or more new data-array-elements according to a pre-specified array-element-datatype, a pre-specified array-element-format, and / or a prespecified array-element-byte-length.

[0121] (12) The sender-apparatus of (11), wherein each new data-array-element and each previously generated data-array-element are associated with a common ID, and wherein each new timestamp and each previously generated timestamp correspond to a time of a respective event associated with the ID.

[0122] (13) The sender-apparatus of (11) or (12), wherein the sender-processing-circuitry is configured to delete one or more of the previously generated data-array-elements using an automated mechanism and / or based on a size threshold for the respective data array, wherein the size threshold corresponds to a pre-specified amount of memory space.

[0123] (14) The apparatus of (9) to (13), wherein the sender-processing-circuitry is configured to convert the appended data array from the array datatype to the string datatype by a serialization using a third party fast serialization library.

[0124] (15) The sender-apparatus of any one of (9) to (14), wherein the sender-data-interface is an application programming interface, API, and wherein each string-dataset is validated by the API according to a pre-specified string datatype, a pre-specified string-data-format, and / or a pre-specified byte-length, and wherein each string-dataset is sent to the in-memory key -value database via the API. (16) A sending-method, comprising obtaining one or more data arrays, a new timestamp, and one or more new data-array-elements, wherein the new timestamp specifies an event related to the one or more new data-array-elements to be appended; appending the new timestamp to one of the data arrays; appending each new data-array-element to one of the data arrays; converting each data array to a string datatype for obtaining one or more string-datasets corresponding to the string datatype; and sending each string-dataset with a respective key to the in-memory key -value database via the sender-data-interface.

[0125] (17) A system comprising a sender-apparatus, a server, and a receiver-apparatus, the sender-apparatus comprising a sender-data-interface to an in-memory key-value database and sender-processing-circuitry configured to: obtain one or more data arrays, a new timestamp, and one or more new data-array-elements to be appended, wherein the new timestamp specifies an event related to the one or more new data-array-elements; append the new timestamp to one of the data arrays; append each new data-array-element to one of the data arrays; convert each data array to a string datatype for obtaining one or more string-datasets corresponding to the string datatype; and send each string-dataset with a respective key to the in-memory keyvalue database via the sender-data-interface; wherein the server comprises the in-memory keyvalue database and server-processing-circuitry configured to: receive the one or more stringdatasets and the respective keys from the sender-apparatus, store the one or more string-datasets and the respective keys in the in-memory key -value database, receive one or more commands referencing the respective keys of the one or more string-datasets, from the receiverapparatus, send the one or more string-datasets to the receiver-apparatus in response to the one or more commands; wherein the receiver-apparatus comprises a receiver-data-interface to the in-memory key-value database and receiver-processing-circuitry configured to: access the inmemory key-value database, provide the one or more respective keys to the in-memory keyvalue database for retrieval of the one or more string-datasets, receive the one or more stringdatasets from the in-memory key -value database via the receiver-data-interface, convert each string-dataset from the string datatype to an array datatype for obtaining the one or more data arrays, and use one or more of the data arrays for time-series data processing.

[0126] The aspects and features described in relation to a particular one of the previous examples may also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the features into the further example.

[0127] Examples may further be or relate to a (computer) program including a program code to execute one or more of the above methods when the program is executed on a computer, processor, or other programmable hardware component. Thus, steps, operations, or processes of different ones of the methods described above may also be executed by programmed computers, processors, or other programmable hardware components. Examples may also cover program storage devices, such as digital data storage media, which are machine-, processor- or computer-readable and encode and / or contain machine-executable, processor-executable, or computer-executable programs and instructions. Program storage devices may include or be digital storage devices, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media, for example. Other examples may also include computers, processors, control units, (field) programmable logic arrays ((F)PLAs), (field) programmable gate arrays ((F)PGAs), graphics processor units (GPU), application-specific integrated circuits (ASICs), integrated circuits (ICs) or system-on-a-chip (SoCs) systems programmed to execute the steps of the methods described above.

[0128] It is further understood that the disclosure of several steps, processes, operations, or functions disclosed in the description or claims shall not be construed to imply that these operations are necessarily dependent on the order described, unless explicitly stated in the individual case or necessary for technical reasons. Therefore, the previous description does not limit the execution of several steps or functions to a certain order. Furthermore, in further examples, a single step, function, process, or operation may include and / or be broken up into several sub-steps, - functions, -processes or -operations.

[0129] If some aspects have been described in relation to a device or system, these aspects should also be understood as a description of the corresponding method. For example, a block, device or functional aspect of the device or system may correspond to a feature, such as a method step, of the corresponding method. Accordingly, aspects described in relation to a method shall also be understood as a description of a corresponding block, a corresponding element, a property or a functional feature of a corresponding device or a corresponding system. The following claims are hereby incorporated in the detailed description, wherein each claim may stand on its own as a separate example. It should also be noted that although in the claims a dependent claim refers to a particular combination with one or more other claims, other examples may also include a combination of the dependent claim with the subject matter of any other dependent or independent claim. Such combinations are hereby explicitly proposed, unless it is stated in the individual case that a particular combination is not intended. Furthermore, features of a claim should also be included for any other independent claim, even if that claim is not directly defined as dependent on that other independent claim.

Claims

Claims1. A receiver-apparatus comprising: a receiver-data-interface to an in-memory key-value database, and receiver-processing-circuitry configured to: access the in-memory key-value database; provide one or more keys to the in-memory key -value database for retrieval of one or more respective string-datasets, each string-dataset corresponding to a string datatype; receive the one or more string-datasets from the in-memory key -value database via the receiver-data-interface; convert each string-dataset from the string datatype to an array datatype for obtaining one or more data arrays, wherein at least one of the data arrays comprises one or more previously generated timestamps, each timestamp specifying an event related to one or more previously generated data-array-elements within the one or more data arrays; and use one or more of the data arrays for time-series data processing.

2. The receiver-apparatus of claim 1, wherein the receiver-processing-circuitry is configured to generate a new timestamp and one or more new data-array-elements corresponding to the new timestamp, wherein the time-series data processing includes a comparison of at least one of the new data-array-elements with one or more of the previously generated data-array- elements with a common position and / or common index.

3. The receiver-apparatus of claim 2, wherein each new data-array-element matches at least one previously generated data-array-element according to a pre-specified array-element- datatype, a pre-specified array-element-format, and / or a pre-specified array-element-byte- length.

4. The receiver-apparatus of claim 2, wherein each new data-array-element and each previously generated data-array-element are associated with a common ID, and wherein each new timestamp and each previously generated timestamp correspond to a time of a respective event associated with the ID.

5. The receiver-apparatus of claim 2, wherein the receiver-processing-circuitry is configured to compare a value of one of the new data-array-elements to a threshold based on one or more of the previously generated data-array-elements corresponding to a common index and / or position, and wherein the receiver-processing-circuitry is configured to activate an alert if the value exceeds the threshold.

6. The receiver-apparatus of claim 1, wherein the receiver-processing-circuitry is configured to convert the one or more string-datasets from the string datatype to the array datatype by a de-serialization using a third party fast serialization library.

7. The receiver-apparatus of claim 1, wherein the receiver-data-interface is an application programming interface, API, and wherein each string-dataset is received from the in-memory key-value database via the API and validated by the API according to a pre-specified string datatype, a pre-specified string-data-format and / or a pre-specified byte-length.

8. A receiving-method comprising: accessing the in-memory key-value database; providing one or more keys to the in-memory key -value database for retrieval of one or more respective string-datasets, each string-dataset corresponding to a string datatype; receiving the one or more string-datasets from the in-memory key-value database via the re- ceiver-data-interface; converting each string-dataset from the string datatype to an array datatype for obtaining one or more data arrays, wherein at least one of the data arrays comprises one or more previously generated timestamps, each timestamp specifying an event related to one or more previously generated data-array-elements within the one or more data arrays; and using one or more of the data arrays for time-series data processing.

9. A sender-apparatus, comprising: a sender-data-interface to an in-memory key-value database, and sender-processing-circuitry configured to:obtain one or more data arrays, a new timestamp, and one or more new data-array- elements to be appended, wherein the new timestamp specifies an event related to the one or more new data-array-elements; append the new timestamp to one of the data arrays; append each new data-array-element to one of the data arrays; convert each data array to a string datatype for obtaining one or more string-datasets corresponding to the string datatype; and send each string-dataset with a respective key to the in-memory key -value database via the sender-data-interface.

10. The sender-apparatus of claim 9, wherein the new timestamp and the one or more new data-array-elements to be appended are generated according to a pre-specified array-element- datatype, a pre-specified array-element-format, and / or a pre-specified array-element-byte- length.

11. The sender-apparatus of claim 9, wherein at least one data array comprises a previously generated timestamp and at least one data array comprises one or more previously generated data-array-elements corresponding to the previously generated timestamp.

12. The sender-apparatus of claim 11, wherein each new data-array-element and each previously generated data-array-element are associated with a common ID, and wherein each new timestamp and each previously generated timestamp correspond to a time of a respective event associated with the ID.

13. The sender-apparatus of claim 11, wherein the sender-processing-circuitry is configured to delete one or more of the previously generated data-array-elements using an automated mechanism and / or based on a size threshold for the respective data array, wherein the size threshold corresponds to a pre-specified amount of memory space.

14. The sender-apparatus of claim 9, wherein the sender-processing-circuitry is configured to convert the appended data array from the array datatype to the string datatype by a serialization using a third party fast serialization library.

15. The sender-apparatus of claims 9, wherein the sender-data-interface is an application programming interface, API, and wherein each string-dataset is validated by the API according to a pre-specified string datatype, a pre-specified string-data-format, and / or a pre-specified byte-length, and wherein each string-dataset is sent to the in-memory key-value database via the API.

16. A sending-method comprising: obtaining one or more data arrays, a new timestamp, and one or more new data-array-elements to be appended, wherein the new timestamp specifies an event related to the one or more new data-array-elements; appending the new timestamp to one of the data arrays; appending each new data-array-element to one of the data arrays; converting each data array to a string datatype for obtaining one or more string-datasets corresponding to the string datatype; and sending each string-dataset with a respective key to the in-memory key -value database via the sender-data-interface.

17. A system comprising a sender-apparatus, a server, and a receiver-apparatus, the senderapparatus comprising a sender-data-interface to an in-memory key-value database and sender- processing-circuitry configured to: obtain one or more data arrays, a new timestamp, and one or more new data-array- elements to be appended, wherein the new timestamp specifies an event related to the one or more new data-array-elements; append the new timestamp to one of the data arrays, append each new data-array-element to one of the data arrays, convert each data array to a string datatype for obtaining one or more string-datasets corresponding to the string datatype, andsend each string-dataset with a respective key to the in-memory key -value database via the sender-data-interface; wherein the server comprises the in-memory key-value database and server-processing-circuitry configured to: receive the one or more string-datasets and the respective keys from the sender-apparatus, store the one or more string-datasets and the respective keys in the in-memory keyvalue database, receive one or more commands referencing the respective keys of the one or more string-datasets, from the receiver-apparatus, and send the one or more string-datasets to the receiver-apparatus in response to the one or more commands; wherein the receiver-apparatus comprises a receiver-data-interface to the in-memory keyvalue database and receiver-processing-circuitry configured to: access the in-memory key-value database, provide the one or more respective keys to the in-memory key-value database for retrieval of the one or more string-datasets, receive the one or more string-datasets from the in-memory key -value database via the receiver-data-interface; convert each string-dataset from the string datatype to an array datatype for obtaining the one or more data arrays, and use one or more of the data arrays for time-series data processing.

Images