System and method for distributing data

Abstract

Embodiments configured according to the principles of the present application provide for identifying a message corresponding to an event, encoding the message, defining an encoded message, and encapsulating the encoded message in a payload. The payload is encapsulated in an envelope for transmission. Embodiments of methods configured according to the principles of the present application provide for decapsulating the payload, revealing the message, and decoding the message. Prior to decoding, the message is routed to an appropriate dispatcher, which routes the message to an appropriate event bus.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 63 / 565,977, filed March 15, 2024, entitled “System and Method for Distributing Data,” the entire contents of which are incorporated herein by reference.

[0003] Copyright reserved

[0004] The public portion of this document contains copyrighted material. The copyright holder does not object to any reproduction of this document or in the form presented publicly in official records, but reserves all remaining rights under the copyright. Background Technology

[0005] This disclosure relates to electronic messaging, and more specifically to secure, high-capacity electronic messaging applicable to, but not limited to, medical systems, devices, and treatments.

[0006] Providing patient care increasingly requires interaction between numerous professionals and caregivers (e.g., physicians, nurses, pharmacists, technicians, registered nurses, etc.) and any number of medical devices / systems needed to treat a given patient. Existing communication systems facilitate care processes, including secure access to electronic health records (“EMRs”), computerized prescription entry (“CPOEs”), and management of medical devices / treatments. Medical activities often involve event-driven messaging, such as issuing alarms when an infusion pump experiences a blockage. As healthcare professionals and patients become increasingly reliant on communication systems, electronic traffic is increasing significantly. This jeopardizes the smooth execution of treatment procedures and the collection of data used to evaluate and improve numerous aspects of treatment.

[0007] What is needed is a system and method for distributing data that is secure, minimizes the computational resources required to generate and transmit data, and allows for the orderly processing of massive amounts of data received from different devices. Summary of the Invention

[0008] This invention provides a secure method for distributing data, minimizing the computational resources required for data generation and transmission, and allowing for the orderly processing of massive amounts of data from different devices. An embodiment of the method configured according to the principles of this invention provides: identifying a message corresponding to an event, encoding the message, defining the encoded message, and encapsulating the encoded message in a payload. The payload is encapsulated in an envelope for transmission.

[0009] An embodiment of the method configured according to the principles of the present invention provides: decapsulating the payload, exposing the message, and decoding the message. Before decoding, the message is routed to an appropriate dispatcher, which in turn routes the message to an appropriate event bus.

[0010] The present invention provides improved elements and arrangements thereof for the described purposes, which are inexpensive, reliable and capable of effectively achieving the intended purpose of the invention.

[0011] Other features and advantages of the invention will become apparent from the following description of preferred embodiments with reference to the accompanying drawings. Attached Figure Description

[0012] The invention will now be described in detail with reference to the following accompanying drawings, in which similar reference numerals always denote corresponding features, wherein: Figure 1 This is a schematic diagram of an implementation of a system for distributing data configured according to the principles of the present invention; Figure 2 and Figure 4 This is a graphical view of an embodiment of a data distribution method configured according to the principles of the present invention; and Figure 3 It is a graphical view of the messages configured according to the principles of the present invention. Detailed Implementation

[0013] The examples shown in the figures are for illustrative purposes only. The figures are illustrative and not restrictive. In the figures, some elements may be enlarged for illustrative purposes and may not be drawn to scale. Furthermore, elements with the same reference numerals in the figures may be the same or similar elements, depending on the context.

[0014] When the term “comprising” is used in this specification and claims, it does not exclude other elements or steps. When an indefinite or definite article—for example, “a,” “an,” or “the”—is used to refer to a singular noun, it includes the plural form of that noun unless expressly stated otherwise. Therefore, the term “comprising” should not be construed as limited to the items listed thereafter; it does not exclude other elements or steps, and thus the scope of “an apparatus comprising items A and B” should not be limited to an apparatus consisting only of components A and B. Furthermore, within the scope of the use of terms such as “comprising,” “having,” and “possessing” in this specification and claims, these terms are intended to be inclusive in a manner similar to that of the term “comprising,” as interpreted when “comprising” is used as a transitional word in the claims.

[0015] Furthermore, whether used in the specification or claims, the terms "first," "second," "third," etc., are used to distinguish similar elements and are not necessarily used to describe a sequence or chronological order. It should be understood that, where appropriate (unless explicitly disclosed otherwise), such terms are interchangeable, and the aspects of this disclosure described herein can be operated in a different order and / or arrangement than those described or illustrated herein.

[0016] Numerous specific details are set forth in the following description to provide a comprehensive understanding of the various aspects and arrangements. However, it should be recognized that the techniques described herein can be implemented without one or more of these specific details, or can be implemented using other methods, components, materials, etc. In other cases, well-known structures, materials, or operations may not have been shown or described in detail to avoid obscuring certain aspects.

[0017] Throughout this specification, references to "in one aspect," "an arrangement," "a configuration," or "an example" indicate a description of a particular feature, structure, or characteristic. Therefore, phrases such as "in one aspect," "in one arrangement," "in one configuration," "in some examples," etc., appearing throughout this specification do not necessarily refer to the same aspect, feature, configuration, example, or arrangement, respectively. Furthermore, the specific features, structures, and / or characteristics described may be combined in any suitable manner.

[0018] Within the scope of this disclosure and the claims, the terms “component,” “system,” “platform,” “layer,” “selector,” “interface,” etc., are intended to refer to a computer-related entity or an entity related to an operating device having one or more specific functions, wherein the entity can be hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. By way of illustration and not limitation, applications running on a server and the server itself can both be components. One or more components may reside within a process and / or an execution thread, and components may reside on a single computer and / or be distributed across two or more computers. Furthermore, components can be executed from various computer-readable media, device-readable storage devices, or machine-readable media on which various data structures are stored. Components can communicate via local and / or remote processes, such as based on signals having one or more data packets (e.g., data from one component interacting with another in a local system, one component interacting with another in a distributed system, and / or data interacting with other systems across a network such as the Internet via said signals). As another example, a component can be a device having specific functions provided by mechanical parts operated by electrical or electronic circuitry, which can be operated by software or firmware applications executed by a processor, wherein the processor can be located inside or outside the device and executes at least a portion of the software or firmware application. As yet another example, a component can be a device providing specific functions through electronic parts that do not contain mechanical parts; the electronic parts may include a processor to execute software or firmware that at least partially endows the electronic parts with functionality.

[0019] Within the scope of use in this specification, terms such as “storage,” “storage device,” “data storage,” “data storage apparatus,” “database,” etc., refer to memory components, entities embodied in memory, or components that include memory. It should be understood that the memory components described herein may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.

[0020] Furthermore, the term "or" is intended to mean an inclusive "or," not an exclusive "or." That is, unless otherwise stated or obvious from the context, "X adopts A or B" is intended to mean any natural inclusive combination. That is, "X adopts A or B" is satisfied in any of the above cases if X adopts A, X adopts B, or X adopts both A and B. Additionally, unless otherwise stated or obvious from the context to the singular form, the articles "a" and "an" as used in this disclosure and claims should generally be interpreted as "one or more."

[0021] Within the scope of its use herein, the terms “exemplary” and / or “illustrative” are used to indicate examples, instances, or descriptions. For the avoidance of ambiguity, the subject matter disclosed herein is not limited to the disclosed examples. Furthermore, any aspect or design described herein as “exemplary” and / or “illustrative” should not necessarily be construed as superior to or advantageous to other aspects or designs, nor is it intended to exclude equivalent exemplary structures and techniques. Moreover, within the scope of the use of “comprising,” “having,” “containing,” and other similar terms in the detailed description or claims, these terms are intended to be inclusive in a manner similar to the term “comprising” as an open-ended transitional term, without excluding any additional or other elements.

[0022] As used herein, the term "inference" or "reasoning" generally refers to the process of reasoning or inferring the state of a system, environment, user, and / or intention based on a set of observations captured via events and / or data. The captured data and events can include user data, device data, environmental data, data from sensors, application data, implicit data, explicit data, etc. For example, inference can be used to identify specific contexts or actions, or to generate a probability distribution of states of interest based on considerations of data and events.

[0023] The disclosed subject matter can be implemented as methods, apparatus, or articles of art using standard programming and / or engineering techniques to produce software, firmware, hardware, or any combination thereof for controlling a computer to implement the disclosed subject matter. Within the scope of this document, the term "article of art" is intended to cover a computer program accessible from any computer-readable device, machine-readable device, computer-readable carrier, computer-readable medium, or machine-readable medium. For example, computer-readable media may include, but is not limited to: magnetic storage devices, such as hard disks; floppy disks; magnetic stripes; optical disks (e.g., optical discs (CDs), digital video discs (DVDs), Blu-ray discs (BDs)); smart cards; flash memory devices (e.g., cards, memory sticks, key drives); virtual devices simulating storage devices; and / or any combination of the aforementioned computer-readable media.

[0024] Typically, program modules include routines, programs, components, data structures, etc., that perform specific tasks or implement specific abstract data types. The aspects of this disclosure shown can be implemented in a distributed computing environment where certain tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in both local and remote memory storage devices.

[0025] A computing device may include at least a computer-readable storage medium, a machine-readable storage medium, and / or a communication medium. A computer-readable or machine-readable storage medium may be any available storage medium accessible by a computer, and includes volatile and non-volatile media, removable and non-removable media. By way of example and not limitation, a computer-readable or machine-readable storage medium may be implemented in conjunction with any method or technique for storing information such as computer-readable or machine-readable instructions, program modules, structured data, or unstructured data.

[0026] Computer-readable storage media may include, but are not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, read-only optical disc (CD-ROM), digital versatile optical disc (DVD), Blu-ray disc (BD) or other optical disc storage devices, cassette tape, magnetic tape, disk storage devices or other magnetic storage devices, solid-state drives or other solid-state storage devices, or other tangible and / or non-transitory media that can be used to store desired information. In this regard, when the terms “tangible” or “non-transitory” modify “storage device,” “memory,” or “computer-readable medium” herein, they should be understood to exclude only the transient signal itself in transit, and not any standard storage device, memory, or computer-readable medium that is not solely for the transient signal in transit.

[0027] One or more local or remote computing devices can access a computer-readable storage medium, for example, via access requests, queries or other data retrieval protocols, for various operations on the information stored in the medium.

[0028] The system bus used in this paper can be any of several types of bus architectures, and it can also interconnect with memory buses (with or without memory controllers), peripheral buses, and local buses using any of a variety of commercially available bus architectures. The database used in this paper can include a basic input / output system (BIOS) that can be stored in non-volatile memory such as ROM, EPROM, or EEPROM, where the BIOS contains basic routines that facilitate the transfer of information between components within the computer, such as during startup. RAM can also include high-speed RAM such as static RAM for caching data.

[0029] As used herein, a computer can operate in a networked environment using logical connections to one or more remote computers via wired and / or wireless communications. Remote computers can be workstations, servers, routers, personal computers, laptops, microprocessor-based entertainment devices, peer-to-peer devices, or other common network nodes. The logical connections illustrated herein can include wired / wireless connections to local area networks (LANs) and / or larger networks (e.g., wide area networks (WANs)). Such LAN and WAN networking environments are common in offices and companies and facilitate enterprise-wide computer networks such as intranets, where any network can connect to global communications networks, such as the Internet.

[0030] When used in a LAN networking environment, a computer can connect to the LAN via a wired and / or wireless communication network interface or adapter. The adapter facilitates wired or wireless communication with the LAN, which may also include wireless access points (APs) configured therein for wireless communication with the adapter.

[0031] When used in a WAN networking environment, the computer may include a modem or may be connected to a communication server on the WAN via other means of establishing communication over the WAN, such as via the Internet. The modem (which may be internal or external) and wired or wireless devices may be connected to the system bus via an input device interface. In a network environment, program modules or portions thereof shown herein with respect to a computer may be stored in a remote memory / storage device.

[0032] When used in a LAN or WAN networking environment, in addition to or as a substitute for external storage devices, the computer can also access cloud storage systems or other network-based storage systems. Typically, the connection between the computer and the cloud storage system can be established via a LAN or WAN, for example, via an adapter or modem, respectively. When connecting the computer to an associated cloud storage system, the external storage interface can manage the storage provided by the cloud storage system with the help of an adapter and / or modem, just as it would manage other types of external storage. For example, the external storage interface can be configured to provide access to cloud storage sources as if these storage sources were physically connected to the computer.

[0033] As used herein, the term "processor" can refer to virtually any computing processing unit or device, including but not limited to: a single-core processor; a single-core processor with software multithreading capabilities; a multi-core processor; a multi-core processor with software multithreading capabilities; a multi-core processor with hardware multithreading technology; a vector processor; a pipelined processor; a parallel platform; and a parallel platform with distributed shared memory. Furthermore, a processor can refer to an integrated circuit, an application-specific integrated circuit (ASIC), a digital signal processor (DSP), a field-programmable gate array (FPGA), a programmable logic controller (PLC), a complex programmable logic device (CPLD), a state machine, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. Processors can utilize nanoscale architectures, such as, but not limited to, molecular and quantum dot-based transistors, switches, and gates, to optimize space usage or improve the performance of user equipment. Processors can also be implemented as a combination of computing processing units. For example, a processor can be implemented as one or more processors working together, which are tightly coupled, loosely coupled, or remotely located. Multiple processing chips or multiple devices can jointly perform one or more of the functions described herein, and similarly, storage can be implemented across multiple devices. The processor can be implemented to reside in a cloud-based network such as the Internet.

[0034] The actions of the methods or algorithms described in conjunction with the arrangements disclosed herein can be directly embodied in hardware, software modules executed by a processor, or a combination of both. Software modules can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disks, removable disks, CD-ROMs, or any other known form of storage medium. The storage medium can be coupled to the processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be integrated with the processor. The processor and storage medium can reside in an ASIC. The ASIC can reside in functional devices such as, for example, computers, robots, user terminals, mobile phones or tablets, automobiles, or IP cameras. Alternatively, the processor and storage medium can reside as discrete components in such functional devices. Additionally or alternatively, at least one of the processor and / or storage medium can reside in a cloud-based network such as, for example, the Internet.

[0035] The configuration described herein relates to a computer system for carrying out the methods described herein, and a computer-readable medium containing programs for carrying out these methods. Raw data and results may be stored for later retrieval and processing, and may be printed, displayed, transmitted to another computer, and / or transmitted to other locations. Communication links may be wired or wireless, for example, using cellular communication systems, military communication systems, and satellite communication systems. Parts of the system may operate on a computer with a variable number of CPUs. Other alternative computer platforms may also be used.

[0036] This configuration also relates to software / firmware / hardware for carrying out the methods described herein, and a computer-readable medium for storing the software for carrying out these methods. The various modules described herein may be implemented on the same CPU or on different CPUs. For legal compliance, this configuration has been described using language that is more or less specific in terms of structural and methodological features. However, it should be understood that this configuration is not limited to the specific features shown and described, as the means disclosed herein include preferred forms of implementing this configuration.

[0037] The method may be implemented electronically, in whole or in part. Signals indicating actions taken by system components and other publicly disclosed configurations may be transmitted via at least one active communication network. Control and data information may be executed and stored electronically on at least one computer-readable medium. The system may be implemented to execute on at least one computer node in at least one active communication network. Common forms of at least one computer-readable medium may include, for example, but not limited to: floppy disks, flexible disks, hard disks, magnetic tapes, or any other magnetic media; read-only optical disks or any other optical media; punched cards, paper tapes, or any other physical media with a perforated pattern; random access memory, programmable read-only memory, and erasable programmable read-only memory (EPROM); flash memory EPROMs or any other memory chips or cartridges; or any other media from which a computer can read. Furthermore, where appropriate and licensed, at least one computer-readable medium may contain graphics of any form, including but not limited to Graphics Exchange Format (GIF), Joint Image Experts Group (JPEG), Portable Web Graphics (PNG), Scalable Vector Graphics (SVG), and Tagged Image File Format (TIFF).

[0038] This document describes various arrangements. For ease of illustration, methods or algorithms are depicted and described as a series of steps or actions. It should be understood and recognized that the various arrangements are not limited to the actions shown and / or the order of actions. For example, actions may occur in various orders and / or simultaneously, and may occur together with other actions not shown or described herein. Furthermore, implementing the method may not require all the actions shown. Additionally, the method may alternatively be represented as a series of interrelated states via a state diagram or events. Moreover, the methods described below can be stored on an article of art as defined herein for transporting and transmitting these methods to a computer.

[0039] Reference Figure 1 This invention provides a secure system and method for distributing data that minimizes computational resources. Figure 1 An exemplary implementation of system 300 is shown, which is used to treat a patient (not shown) using a medical device 301. The medical device 301 may be selected, for example, from: patient status devices, such as pulse oximeters, cardiac monitors, blood pressure devices, and temperature devices; patient treatment devices, such as drip meters, infusion pumps, pill dispensers, or any Internet-enabled device or device interface connected to a message generation activity.

[0040] Preferably, device 301 is configured to communicate with gateway 305 via internet connection 302, such as a hardwired connection like Ethernet. Preferably, device 301 communicates wirelessly, such as via Wi-Fi, Bluetooth, etc. Cellular communication between device 301 and gateway 305 is also within the scope of this invention.

[0041] During operation, based on signals from components and sensors in device 301 corresponding to normal and abnormal operation, device 301 experiences events, such as, but not limited to, those listed in column 2 of Table 1 below. Each event is associated with a unique ID, such as those listed in column 1 of Table 1 below.

[0042]

[0043] Table 1

[0044] Also refer to Figure 2 The method configured according to the principles of the present invention includes the device 301 performing the step 405 of identifying an event. For example, in response to detecting high pressure in the device 301, a pressure sensor may send an alarm signal to a processor (not shown) in the device 301, the alarm signal being associated with or identifiable as an obstruction, such as that located in a cannula dedicated to supplying infusion fluid to the patient. Consistent with Table 1 above, this obstruction event will be identified by event ID 2.3.

[0045] Once identified, preferably, method 400 includes device 301 performing step 410—encoding the ID associated with the event into a message. Step 410 is included as needed and configured to conform to the format and / or protocol of existing decoding capabilities, as described below in conjunction with step 545. For a decoder contemplated as being configured to receive and process hexadecimal input, one implementation of step 410 includes converting the event ID to a hexadecimal string. For example, for a “issue a blocking alarm” event with ID 2.3, step 410 may include converting the ID from 2.3... 10 Convert to 2.4CCCCCCCCC 16 Alternatively, the present invention can utilize a decoder configured to receive and process decimal input. In this case, step 410 will be unnecessary.

[0046] Although the message itself may be small and / or compressed as part of step 410, method 400 does not exclude the additional step 415 of compressing the message to obtain the smallest possible message.

[0047] Also refer to Figure 3 Once the message has been encoded, compressed, or otherwise prepared for encapsulation, method 400 proceeds to initialization and construction of a packet or envelope 600. Preferably, the packet or envelope 600 conforms to an open standard file format and data exchange format that uses human-readable text to store and transmit data objects consisting of attribute-value pairs and arrays, such as JSON, to deliver events. Preferably, the envelope 600 is configured to be routed over external or uncontrolled communication networks without requiring decapsulation or understanding of the message content.

[0048] Envelope 600 includes payload 605 and header 610. Payload 605 includes multiple predefined fields or keys associated with values. For example, a key could be tenantId 620, used to identify a relevant dedicated instance reserved for a specific customer or an anticipated internal message bus 375, as described below.

[0049] Preferably, payload 605 includes a key such as route 655 to describe or identify the path 600 takes before reaching its final decoding location. For example, route 655 may describe that packet 600 has passed sequentially through a device, router, gateway, event stream, internal message bus, dispatcher, event bus, decoder, and storage device. route 655 may or may not include a unique identifier associated with each station along the route.

[0050] Preferably, payload 605 includes a key such as SourceType 660 for identifying the source of the event, such as medical device 301.

[0051] Preferably, payload 605 includes a key such as signModeKeyId 630 for identifying which asymmetric key is used to confirm or verify the authenticity of the packet.

[0052] Preferably, payload 605 includes a key such as encModeKeyId 635, which identifies the symmetric key used to decrypt payload 605.

[0053] Preferably, the payload 605 includes a timestamp key 640, which corresponds to the date and time of the event.

[0054] Preferably, payload 605 includes a key such as reporterId 665 for identifying the means or function that last transmitted message.

[0055] Preferably, payload 605 includes keys such as eventId key 670 and eventType 675 for defining the state of the device, such as device online (ev_device_online).

[0056] Preferably, payload 605 includes a key such as sourceId 680 for identifying the initiator of the message, such as medical device 301.

[0057] Preferably, payload 605 includes a key such as userId 685 for identifying a patient who is receiving treatment from or associated with medical device 301.

[0058] Preferably, payload 605 includes a key such as eventData 690 for containing the encoded / compressed / encrypted message described above in conjunction with Table 1.

[0059] Payload 605 may include keys such as metadata 695 for containing, in an unstructured manner, any additional data about the message that is not otherwise included in payload 605, such as the client application version.

[0060] Preferably, payload 605 includes keys such as internalEventId 705 and internalEventType 700, which are essentially extended or enhanced versions of eventId key 675 and eventType 680, respectively, for providing additional information or for more reliable internal tracking.

[0061] Preferably, internalEventId 705 and internalEventType 700 are not added to payload 605 by the device, but by dispatcher 315, as described below.

[0062] Preferably, header 610 includes a key such as envelopeVersion 615, which identifies the version of the schema, i.e., the specific keys and their arrangement used by the package or envelope 600.

[0063] Preferably, the header 610 further includes the key 620 as described above.

[0064] Preferably, header 610 includes a key such as signature 625 for containing an asymmetric private key for authenticating packet 600.

[0065] Preferably, header 610 further includes keys 630, 635 and 640 as described above.

[0066] Preferably, header 610 includes a key such as requestId 645 for tracking and associating each action performed in response to the event.

[0067] Continue to refer to Figure 2 and Figure 3 With the architecture of envelope 600 already detailed, method 400 proceeds and includes device 301 performing step 420 to encapsulate the message or associate the message with keys according to envelopeVersion key 615.

[0068] Method 400 then proceeds to step 425, in which device 301 performs the encryption of the payload, preferably using a symmetric key of device 301, such as AES / CBC / PKCS5 padding. According to the principles of the invention, the encryption protocol should convert the message into a minimally sized ciphertext.

[0069] Once payload 605 is encrypted, method 400 includes device 301 performing step 430, digitally signing the payload, preferably using an asymmetric private key, such as RSA 2048 / SHA256 with RSA padded with PKCS1v15. Step 430 facilitates verification of payload 610 before it passes through gateway 305. The value of step 430 defines key 625.

[0070] Once payload 605 is signed, method 400 includes means 301 performing step 435, preferably encoding payload 605 in Base64. Similar to step 410, step 435 is included to comply with formats and / or protocols that may be incompatible with JSON data objects.

[0071] Once payload 605 is encoded, method 400 includes means 301 performing step 440, either encapsulating the payload in an envelope or associating identification information, such as header 610, with payload 605. Step 440 facilitates routing envelope 600 to the appropriate gateway 305.

[0072] Finally, method 400 includes device 301 performing step 445, publishing an event or envelope 600 to a message broker serving gateway 305 to properly receive, route, and queue the message.

[0073] Preferably, step 445 employs a lightweight publish / subscribe machine-to-machine network protocol, such as MQTT, for message queuing / message queuing services. Lightweight protocols save processing resources that would otherwise be consumed by handling a large number of messages from a large number of devices, which may have resource constraints or limited network bandwidth common in IoT applications.

[0074] Preferably, step 445 is not subject to transmission acknowledgments or receipts. This significantly reduces the processing resources consumed and the possibility of operational delays. That is, especially when many devices 301 are operating and generating many messages, eliminating the need for the system to generate and process message acknowledgments significantly reduces the possibility of simultaneously generated messages being lost or corrupted.

[0075] In summary, method 400 is configured to generate a very small packet or envelope 600 that contains or represents a large amount of detailed data. The encoding in step 410 (and, if performed, compression in step 415) makes the payload 605 very small, thereby further minimizing processing requirements through the encryption in step 425 performed on this small payload 605. Since the payload 605 is not unfolded until needed, the packet 600 can be transmitted over long distances in its miniaturized form without any loss of fidelity.

[0076] Refer again Figure 1 and Figure 4 After leaving device 301 at the end of method 400, packet 600 is processed according to method 500, which is preferably executed in cloud 365. Method 500 includes step 505 of gateway 305 receiving envelopes or packets. Subsequently, the MQTT message broker serving gateway 305 performs step 510, placing envelope 600 in event stream 310.

[0077] Method 500 includes event stream 310 performing step 515 to decode payload 605, corresponding to step 435 above.

[0078] Once payload 605 is decoded, method 500 includes event stream 310 performing step 515 to verify its digital signature, corresponding to step 430 above.

[0079] Once the digital signature of payload 605 is verified, method 500 includes event stream 310 executing step 520 to decrypt payload 605, corresponding to step 425 above.

[0080] Once payload 605 is decrypted, preferably, method 500 includes event stream 310 performing step 525 to route payload 605 to internal message bus 375 and queue messages.

[0081] Preferably, step 525 employs a simple publish / subscribe system, preferably but not limited to Amazon® AWS SNS. Through SNS, messages are asynchronously queued to “topics” that subscribers (e.g., dispatcher 315) can subscribe to. A “topic” can be created for each device 301. Queuing ensures that messages are retained until expected or able to be processed by dispatcher 315. Preferably, step 525 also employs a simple queuing service, such as but not limited to Amazon® AWS SQS. SQS is capable of receiving and storing messages on any scale without losing messages or requiring other services to become available. SQS prevents the invention from stalling or stopping due to excessive data and allows data to be routed and processed according to the processing capabilities of system components.

[0082] When feasible or necessary, method 500 includes dispatcher 315 performing step 530 to examine payload 605 in plaintext to determine where to route the message, i.e., which event bus 320 the message belongs to; different device types or groups of devices each have designated event buses 320. For example, devices providing infusion may define one group, while devices providing parameter monitoring such as blood pressure may define another group, each with its own event bus 320. As described above, dispatcher 315 may add keys 700 and 705 to payload 605 based on this information, or supplement payload 605 with keys 700 and 705.

[0083] Based on step 530, method 500 includes dispatcher 315 performing step 535, publishing envelope 600 to the appropriate event bus 320, for example, corresponding to an SNS topic associated with the appropriate tag (internalEventType 700). Device-specific buses facilitate rapid processing of payload 605, which is specific to any of a variety of medical devices performing different functions associated with different sets of parameters.

[0084] When envelope 600 is received, method 500 includes event bus 320 performing step 540 to queue the envelope in decoder 325.

[0085] When decoder 325 is available, method 500 includes decoder 325 performing step 545 to decode the message of envelope 600. Embodiments of the invention include employing a decoder suitable for each message version. However, packet 600 can be configured such that the decoding in step 545 can serve any payload 610, regardless of what device 301 packet 600 relates to.

[0086] Once the message is decoded, method 500 includes decoder 325 performing step 550, storing it in event database 370. Step 550 is facilitated by returning envelope 600 to event bus 320, which performs step 555, routing envelope 600 to storage function 335.

[0087] The foregoing content pertains to basic message generation, transmission, reception, identification, and storage. The following elements and combinations thereof—(1) creating small, data-rich encrypted message packets; and (2) transmitting the message packets via lightweight network protocols—enable: (1) transmitting large amounts of data in a miniaturized form; and (2) maintaining high fidelity. Because the packets are not unfolded or decoded until needed, they can be transmitted over long distances in a miniaturized form without any loss of fidelity.

[0088] Once the payload reaches its destination, the decoder converts it into human-readable text that can be used by any service. A single decoder service eliminates the need for users to know how to decode packets themselves and reduces redundant packet processing; packets are processed once, and the resulting data can be used by multiple users. The minimized packet size achieved by this invention also reduces the amount of resources required by devices such as medical devices to store and transmit events, thereby saving storage space on the device and ensuring that more events can be stored in limited available space before all events are transmitted to the server.

[0089] Minimal encapsulation, lightweight queuing, and the use of micro-functions to manage received messages enable high availability and horizontal scalability, i.e., the ability to handle messages generated by a large number of medical devices used simultaneously worldwide.

[0090] This invention extends from basic information communication and storage to analysis. To this end, preferably, method 500 includes a storage function 335 performing step 560 to store the decoded message in an event database 370, such as Opensearch or a similar NoSQL database.

[0091] The present invention includes an event query API service 385 for querying messages in a database 370 based on various criteria such as time, initiating device, message type, etc.

[0092] The present invention includes a user interface (UI) service 350, which is preferably accessible via a browser and utilizes an API service 385.

[0093] This invention includes a data analysis and research service 340 for service API queries.

[0094] The present invention includes a medical device manager 380 for sending message responses back to device 301 as needed. For example, manager 380 may send events to device 301 that: verify the authenticity of an attached component (such as an insulin pump); notify device 301 that a firmware software update is available; or instruct device 301 to modify its settings.

[0095] This invention is not limited to the specific embodiments described and shown herein, but is limited only by the following claims.

Claims

1. A method for distributing data, comprising: Identify the message corresponding to the event; The message is encoded, and the encoded message is defined; as well as The encoded message is encapsulated in a payload.

2. The method according to claim 1, wherein, The message is based on the status of the medical device.

3. The method according to claim 1, wherein, The encoding includes hexadecimal conversion.

4. The method according to claim 1 further includes encrypting the message, the encoded message, and / or the payload.

5. The method according to claim 1, further comprising compressing the message, the encoded message and / or the payload.

6. The method of claim 1, further comprising signing the payload.

7. The method of claim 1, further comprising encapsulating the payload in an envelope.

8. The method according to claim 7, further comprising: The transmission includes envelopes for Lightweight Publish-Subscribe Machine-to-Machine Network Protocol (PPP) messages.

9. A method for distributing data, comprising: Decapsulate the payload and expose the messages; as well as The message is decoded, and the decoded message is defined.

10. The method of claim 9, further comprising: Place the envelope containing the payload in the event stream.

11. The method according to claim 9, wherein, The payload is sealed in an envelope. The method also includes routing the envelope to an event bus.

12. The method according to claim 11, wherein, The routing is based on the payload.

13. The method of claim 9, further comprising: The payload is supplemented as described above.

14. The method according to claim 9, wherein, The message is based on the status of the medical device.

15. The method according to claim 9, wherein, The decoding includes hexadecimal conversion.

16. The method of claim 9, further comprising: The message, the decoded message, and / or the payload are decompressed.

17. The method of claim 9, further comprising: Decrypt the message, the decoded message, and / or the payload.

18. The method of claim 9, further comprising: Verify the signature of the payload.

19. The method of claim 9, further comprising: Store the decoded message in the database; as well as Provides an application protocol interface that is configured to access the database.

20. The method of claim 9, further comprising: The second message is transmitted based on the first message.

Images