WO2021046129A1 - Système de base de données de traitement d'événements de chaîne de blocs - Google Patents

Système de base de données de traitement d'événements de chaîne de blocs Download PDF

Info

Publication number
WO2021046129A1
WO2021046129A1 PCT/US2020/049068 US2020049068W WO2021046129A1 WO 2021046129 A1 WO2021046129 A1 WO 2021046129A1 US 2020049068 W US2020049068 W US 2020049068W WO 2021046129 A1 WO2021046129 A1 WO 2021046129A1
Authority
WO
WIPO (PCT)
Prior art keywords
filter
database
blockchain
timestamp
transaction
Prior art date
Application number
PCT/US2020/049068
Other languages
English (en)
Inventor
Changu Kang
Original Assignee
Planaria Corp.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Planaria Corp. filed Critical Planaria Corp.
Publication of WO2021046129A1 publication Critical patent/WO2021046129A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Definitions

  • a blockchain is a distributed system made up of a growing list of records, called blocks, that are linked using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data. In addition to blocks, the transactions are also linked to one another using cryptography, ensuring a transparent immutable audit trail of all types of transactions. In essence a blockchain can be seen as a transparent public data storage. Just like any system that deals with data, it may be useful to monitor a blockchain for new events and programmatically run tasks when certain events happen.
  • an event processing database system that stores the events in an easy-to-query database.
  • the event processing systems herein are easily and securely scalable, employ the use of a flexible query language to filter a variety of event stream structures in various ways, and are capable of detecting combinations of multiple events.
  • the blockchain systems described herein are centralized and indexed, enabling faster and easier access through searching and queries. Further, in some embodiments, contrary to classical blockchains, the queried blocks enable immutability while easing and providing improved and efficient search means.
  • One aspect provided herein is a method for processing a blockchain, comprising: (a) storing a plurality of blockchain transactions from said blockchain in an indexed database, wherein each of said plurality of blockchain transactions is associated with a transaction timestamp; (b) generating a query comprising a filter condition and a corresponding filter timestamp, wherein said filter timestamp indicates a time when said filter condition was last executed; (c) using said query to determine if one or more blockchain transactions in said plurality of blockchain transactions in said indexed database (1) satisfies said filter condition and (2) is associated with a transaction timestamp that is greater than said filter timestamp; and (d) executing a task associated with said filter condition if said one or more blockchain transactions (1) satisfies said filter condition and (2) is associated with said transaction timestamp that is greater than said filter timestamp.
  • the method further comprises updating said filter timestamp.
  • (a) comprises periodically polling said blockchain. In some embodiments, (a) comprises subscribing to push notifications from said blockchain. In some embodiments, (a) comprises implementing said blockchain on a peer-to-peer network and directly monitoring said peer-to-peer network.
  • said indexed database is a document database, a relational database, or a graph database.
  • said filter condition comprises transaction data in said blockchain transaction corresponding to a defined data pattern. In some embodiments, said filter condition comprises said one or more blockchain transactions corresponding to a defined transaction pattern. In some embodiments, said filter condition is associated with a frequency at which said filter condition is to be executed. In some embodiments, said task comprises generating or broadcasting a new blockchain transaction.
  • (d) comprises executing a plurality of tasks associated with said filter condition.
  • the query comprises a streaming query.
  • executing the task is parallelized to multiple machines.
  • executing the task comprises queueing a function execution.
  • the task is attached to a plurality of filters.
  • the indexed database comprise a document database, a relational database, a graph database, a stream processing system, a key -value database or any combination thereof.
  • Another aspect provided herein is a method for processing a transaction, comprising: (a) storing a plurality of transactions from said in an indexed database, wherein each of said plurality of transactions is associated with a transaction timestamp; (b) generating a query comprising a filter condition and a corresponding filter timestamp, wherein said filter timestamp indicates a time when said filter condition was last executed; (c) using said query to determine if one or more transactions in said plurality of transactions in said indexed database (1) satisfies said filter condition and (2) is associated with a transaction timestamp that is greater than said filter timestamp; and (d) executing a task associated with said filter condition if said one or more transactions (1) satisfies said filter condition and (2) is associated with said transaction timestamp that is greater than said filter timestamp.
  • the method further comprises updating said filter timestamp.
  • (a) comprises periodically polling said blockchain. In some embodiments, (a) comprises subscribing to push notifications from said blockchain. In some embodiments, (a) comprises implementing said on a peer-to-peer network and directly monitoring said peer-to-peer network.
  • said indexed database is a document database, a relational database, or a graph database.
  • said filter condition comprises transaction data in said transaction corresponding to a defined data pattern. In some embodiments, said filter condition comprises said one or more transactions corresponding to a defined transaction pattern. In some embodiments, said filter condition is associated with a frequency at which said filter condition is to be executed. In some embodiments, said task comprises generating or broadcasting a new transaction. In some embodiments, (d) comprises executing a plurality of tasks associated with said filter condition.
  • Another aspect provided herein is one or more non-transitory computer storage media storing instructions that are operable, when executed by one or more computers, to cause said one or more computers to perform operations comprising: (a) storing a plurality of blockchain transactions from said blockchain in an indexed database, wherein each of said plurality of blockchain transactions is associated with a transaction timestamp; (b) generating a query comprising a filter condition and a corresponding filter timestamp, wherein said filter timestamp indicates a time when said filter condition was last executed; (c) using said query to determine if one or more blockchain transactions in said plurality of blockchain transactions in said indexed database (1) satisfies said filter condition and (2) is associated with a transaction timestamp that is greater than said filter timestamp; and (d) executing a task associated with said filter condition if said one or more blockchain transactions (1) satisfies said filter condition and (2) is associated with said transaction timestamp that is greater than said filter timestamp.
  • the operations further comprise updating said filter timestamp.
  • (a) comprises periodically polling said blockchain.
  • (a) comprises subscribing to push notifications from said blockchain.
  • (a) comprises implementing said blockchain on a peer-to-peer network and directly monitoring said peer-to-peer network.
  • said indexed database is a document database, a relational database, or a graph database.
  • said filter condition comprises transaction data in said blockchain transaction corresponding to a defined data pattern.
  • said filter condition comprises said one or more blockchain transactions corresponding to a defined transaction pattern.
  • said filter condition is associated with a frequency at which said filter condition is to be executed.
  • said task comprises generating or broadcasting a new blockchain transaction.
  • (d) comprises executing a plurality of tasks associated with said filter condition.
  • the query comprises a streaming query.
  • executing the task is parallelized to multiple machines.
  • executing the task comprises queueing a function execution.
  • the task is attached to a plurality of filters.
  • the indexed database comprise a document database, a relational database, a graph database, a stream processing system, a key -value database or any combination thereof.
  • Figure 1 schematically illustrates a blockchain event processing system that processes every event one by one
  • Figure 2 provides a flowchart of an example process performed by the blockchain event processing system of Figure 1;
  • Figure 3 provides a flowchart for a “process event” subroutine of the example process of Figure 2;
  • FIG. 4 schematically illustrates a database-based blockchain event processing system, in accordance with an embodiment herein;
  • Figure 5 provides a flowchart of an example process performed by the database-based blockchain event processing system of Figure 4, in accordance with an embodiment herein;
  • Figure 6 provides a flowchart for a “process filter” subroutine of the example process of Figure 5, in accordance with an embodiment herein;
  • Figure 7 provides a flowchart of how the database-based blockchain event processing system constructs a timestamped filter in order to retrieve only the new events since its last processing run, in accordance with an embodiment herein;
  • Figure 8 provides an exemplary code for providing a database structure for each database component in the blockchain event processing database system, in accordance with an embodiment herein;
  • Figure 9 provides an exemplary code for providing a database structure for the naive blockchain event processing system
  • Figure 10 provides an exemplary code of an alternative embodiment of the blockchain event processing database system, in accordance with an embodiment herein;
  • Figure 11 is an example list of high level abstraction query languages used by the blockchain event processing database system, in accordance with an embodiment herein;
  • Figure 12 is an example of an event serialization format, in accordance with an embodiment herein;
  • Figure 13 is an example of a combination filter, in accordance with an embodiment herein;
  • Figure 14 shows a non-limiting example of a computing device
  • Figure 15 shows a non-limiting example of a web/mobile application provision system
  • Figure 16 shows a non-limiting example of a cloud-based web/mobile application provision system.
  • a blockchain event processing system may have a filter and a task.
  • a filter may be a programmatic function which is used to test whether an event passes a certain condition or not (900). After inspecting an event, the filter returns either true or false.
  • a task is a program which is programmed to run certain actions when its associated FILTER is triggered by an event. For example, a system may want to monitor all transactions sent to a certain address (FILTER), and send an email notification (TASK) when it happens (EVENT) (the “task” column of the first row of 902). But a task may be any action that can be implemented as a program, for example a “create transaction” task could create another blockchain transaction when there is an incoming event which passes a filter (the “task” column of the second row of 902).
  • FIG. 1 schematically illustrates a blockchain event processing system that processes every event one by one.
  • the tasks and filters are submitted to event processor 102 by Client 100.
  • the event processor 102 then stores the submitted filters into a filter database FILTER DB (106) and the submitted tasks into a task database TASK DB (104).
  • Figure 9 provides an exemplary code for providing a database structure for the naive blockchain event processing system.
  • the FILTER DB 106 simply stores raw FILTER code which programmatically checks an incoming event for certain condition and either returns true or false (900).
  • the FILTER DB 106 may also store other metadata about each filter, such as name, description, and other useful information.
  • the example 900 uses JavaScript but the filter can be written in any programming language such as python, c, java, etc. depending on the implementation.
  • the event processor 102 may store all the registered tasks along with their related filters into TASK DB 104 (902).
  • the event processor 102 may later easily retrieve relevant tasks to run when an incoming event matches a filter. There may be one task per filter but there may also be multiple tasks per filter registered in case the client has registered multiple tasks to be triggered for the same filter.
  • the event processor 102 also keeps listening to event listener 108.
  • the event listener 108 monitors the blockchain 110 either by polling constantly, or by subscribing to the blockchain software's built-in push notification features such as ZeroMQ supported by Bitcoin, or through listening to the peer-to-peer network events by subscribing to the peer to peer protocol directly.
  • FIG. 2 illustrates the high level flowchart for this naive event processing system. Whenever the event listener 108 encounters a new event, it calls the event processor 102 with the EVENT data as argument (200).
  • Figure 12 is an example of an event serialization format. As shown, the events themselves are not constrained to any certain format, but one approach may be to use a serialization format that may be easy to process, such as JSON.
  • the EVENT data may be a structured interpretation of the actual raw data.
  • the event processor 102 then fetches all the filters it has from the FILTER DB 106 (202), sets the iteration INDEX to 0 (204), and then checks if the current index (in the beginning it's 0) may be greater than or equal to the total number of FILTERS it's tracking (206). If this condition is true from the beginning, that means the length of the FILTERS array is 0, which means the FILTER DB 106 does not contain any filters to track.
  • the event processor 102 simply ends the process since there may be no work to do. However if the INDEX is less than the FILTERS array length, it runs a subroutine called ProcessEvent which processes the EVENT with the filter at current INDEX (208). After it's finished processing the filter at the current INDEX, it increments the INDEX (210) and starts another round of loop, and the process repeats until the INDEX is greater than or equal to the FILTERS. length (206), which would mean the event processor 102 has completely iterated through all the filters, therefore jumping to the end state.
  • ProcessEvent which processes the EVENT with the filter at current INDEX (208). After it's finished processing the filter at the current INDEX, it increments the INDEX (210) and starts another round of loop, and the process repeats until the INDEX is greater than or equal to the FILTERS. length (206), which would mean the event processor 102 has completely iterated through all the filters, therefore jumping to the end state.
  • FIG. 3 is a flowchart for the ProcessEvent subroutine.
  • the ProcessEvent step (208) takes two arguments: FILTERS [INDEX] and EVENT, which correspond to the inputs FILTER and EVENT in Figure 3 (300).
  • the goal of this subroutine may be to process a single EVENT with a single FILTER.
  • the event processor 102 first checks whether the EVENT passes the FILTER test (302).
  • the FILTER function may be written in any programming language that takes an event as input and returns true or false depending on whether the event matches the programmed logic or not (900). If the EVENT does not pass the FILTER test, the ProcessEvent subroutine ends and the flowchart jumps right to the end phase.
  • the EVENT passes the FILTER test, it goes on to the next step (304) to first fetch all the TASKS related to the FILTER from the TASK DB 104.
  • TASK processing logic
  • the event processor has access to all the TASKS (304), it needs to iterate through the TASKS array and run each task. To do this, it first sets TASK INDEX to 0 (306), then it checks to see if the TASK INDEX is greater than or equal to the length of the TASKS array (308). If this condition is true from the beginning, this would mean that the length of the TASKS array is 0, which means there is no task to run, so it jumps to the end state. However if the TASK INDEX is smaller than the length of the TASKS array, it goes ahead to process the task at TASK INDEX of the TASKS array, while passing the EVENT as an argument (310).
  • the event processor 102 increments the TASK INDEX (312) and starts the next round of the loop (308). The loop continues until the TASK INDEX finally reaches the length of the length of the TASKS array. When the TASK INDEX finally reaches the length of the TASKS array, the process ends.
  • the filter function may take the form of a full fledged programming language such as JavaScript, C, Python, Java, or others, as seen in box 900 of Figure 9. In this case, there may be security issues because the filter exists as a full fledged program which can execute any arbitrary code.
  • the filter function may take the form of a more restricted DSL (domain specific language) which ensures that arbitrary code cannot be run, and only safe filtering operations can be run.
  • DSL domain specific language
  • One such example may be JQ, a JSON processing language.
  • Another familiar example may be a regular expression engine which may be built into many programming languages. It may be possible to use this DSL based approach to check for certain patterns in any piece of data. The problem with this DSL based approach may be that most of these domain specific data processing languages are intentionally limited in their expressive power and therefore not flexible enough to express various types of complex patterns needed to filter.
  • Another problem with the naive event processing system may be that a system which can only process events one by one can only support “stateless event processing”, which means it can process a single event at a time and cannot process more complex events which are combinations of multiple events. For example, it may be impossible to create a filter which tests multiple different types of events simultaneously. Another example, to watch out for an event which may be defined as: “when a sequence of N chained transactions happen from an address”, this may be impossible to monitor this pattern when the system may be able to process only one event at a time and forget all the past events. It would be useful, therefore, to have an event processing system which may be scalable, and allows for flexible query language to filter various event stream structures in various ways, as well as providing the ability to detect sophisticated events which are combinations of multiple events, while not sacrificing security.
  • the blockchain systems described herein are centralized and indexed, enabling faster and easier access through searching and queries.
  • Figure 4 illustrates one embodiment of the event processing database system.
  • the main architecture difference from the naive event processing system is it utilizes a database approach. Instead of processing every incoming event one by one in real-time, it stores the events in an easy-to-query storage (database) and run the filtering from the storage. After all, this difficulty in querying a structured dataset may be why database systems exist and why database query languages exist. Database systems provides the ability to store as much dataset as you want, index them in whichever structure as you want, and discover patterns from the persisted structured dataset from a holistic view. Also, database query languages make it easy to filter complex data patterns with a simple query.
  • filtering a whole chain of events can be represented as a connected graph format (“monitor when a new transaction event completes a certain chain of transaction sequence pattern”)
  • the events are stored in a graph database, and implement the filters using a graph database query language such as Gremlin graph traversal language.
  • a graph database query language such as Gremlin graph traversal language.
  • an event pattern may be filtered that involves relationships between multiple events.
  • a relational database may be used to store the events, and use a relational database query language (SQL) to filter the compound event. None of this is possible if the events are immediately processed as they come, and immediately forgotten.
  • SQL relational database query language
  • the event processing database system in Figure 4 has two additional modules: EVENT DB (410) and CHECKPOINT DB (414).
  • the EVENT DB 410 may be used for storing events before processing instead of trying to process all events as they come in real-time.
  • the CHECKPOINT DB 414 may be used to keep track of when certain filters were processed last time, or when certain tasks were run last time, so that the event processor can keep filtering only the new events without redundancy. No assumptions are made on how the events themselves will be structured, but one example approach may be to use a data serialization format such as JSON to present the events in a structured way so it may be processed more easily ( Figure 12).
  • a client 400 whose role may be to submit filters and tasks to the event processing database system.
  • the task may be the actual function that will be executed when a relevant event happens, and the filter may be used to filter out only the relevant events for processing.
  • Events are stored in EVENT DB 410 instead of immediately being processed in an ephemeral manner. Because the events are stored and indexed in the database it is much more efficient to filter the events at large scale and even filter events in bulk. Also, since the events are stored in a database, database query languages are used as filter.
  • the event processor 402 stores the task into TASK DB 404 and the filter into FILTER DB 406.
  • the TASK DB 404 may contain all the registered tasks as well as their associated filters (802).
  • the FILTER DB 406 may contain all the registered filters (804).
  • the FILTER DB 406 may also contain other filter related metadata for each entry.
  • the event processor 402 is also connected to event listener 408.
  • the event listener 408 monitors EVENT DB 410 instead of directly monitoring the blockchain 412.
  • the EVENT DB 410 is a database constructed by constantly listening to the blockchain 412's events and indexing them into various structured formats which can be easily queried and filtered by the event listener 408.
  • the EVENT DB may monitor the blockchain through various methods, such as subscribing to the blockchain built-in push notification methods such as Zeromq, or by constantly polling the blockchain with the built-in blockchain fetch APIs such as JSON-RPC. Or it may be listening directly to the peer to peer network by implementing the blockchain peer to peer protocol itself. It may also monitor by directly watching the stored blockchain files or memory. These are just some examples, the monitoring method is not limited to what's mentioned here, there may be other ways of monitoring the blockchain state in real-time.
  • the EVENT DB 410 attaches some form of timestamp data to all of its EVENT entries, which will allow the Event Processor 402 to query for filters based on timestamps (806). This may be crucial for retrieving and processing only the new events which haven't been processed yet. While prior art systems directly processes every single blockchain event one by one in real-time, this embodiment of the blockchain event processing database system can utilize the EVENT DB 410 as an intermediate buffer which allows for more flexible and efficient filtering.
  • the most obvious benefit may be that the events are stored and indexed, so they can be referenced back later, which gives the event processor 402 a long term memory, which not only makes simple event processing more efficient, but also enables the processing of composite type events which are made up of multiple events, or even an event which may be triggered when a certain sequence of individual events happen in a certain order. For example, you may want to monitor an exact transaction sequence pattern of an address A sending coins to address B, followed by B sending coins to address C. This would be impossible to monitor if all event filtering may be done on a single event.
  • the events can be batch processed since they don't have to be filtered one by one.
  • the event listener 408 may query the EVENT DB 410 only once per second with the filter, and process the entire batched events array as a single unit. This may be possible because the filters are written in database query languages (804) and a single query filter returns all the events required in a single go.
  • the power of this architecture may be that it enables the event processor 402 to filter and process events on its own terms, instead of reactively processing each and every event.
  • the event processor may be configured to query against EVENT DB 410 every 10 seconds, or every 1 minute, or every 1 hour.
  • Some use cases may not require hyper-frequent event processing. In some cases the flexibility may be available to slow down the event processing interval, whereas in other cases a high processing speed may be maintained.
  • the important part may be that this customization can be made on a per-filter basis, where certain filters are processed more frequently than other filters.
  • the customization can also be made on a per-task basis, where multiple tasks which share the same filter may have diflerent priorities therefore have diflerent priorities for processing.
  • This type of differentiation allows for custom prioritization of the event processing api.
  • This prioritization information may be stored in TASK DB 404 (in case the task processing needs to have various priority levels), or may be stored in FILTER DB 406 (in case the filter processing needs to have various priority levels).
  • the last component of the system is CHECKPOINT DB 414.
  • the CHECKPOINT DB is a database which keeps track of all the filter checkpoints which indicate when was the last time this filter was processed (800).
  • the timestamps stored in the CHECKPOINT DB, along with the timestamps stored along with every EVENT in the EVENT DB 410 are crucial for filtering only the new events since last processing, in order to make sure that the events are processed exactly once. But it is not limited to executing tasks exactly once. Because the timestamp data may be stored instead of being forgotten, it may be possible to utilize the timestamp in various creative ways to run tasks in more sophisticated ways.
  • FIG. 5 is a high level flowchart of the primary embodiment of the event processing database system as described in Figure 4.
  • each event processing may be automatically triggered on a fixed interval, for example every 1 second. But it is not limited to this option. The whole point may be that the event processing may be done proactively by the event processor 402 instead of being reactively triggered by incoming events. The process may run every 1 second but also every 1 minute, and so on. Because the event queries always include a “greater than last checkpoint” condition, every query has high performance as long as the timestamps are properly indexed in the EVENT DB 410.
  • Figure 6. is a flowchart of the ProcessFilter subroutine (506) which is the actual processing logic and is the core part of this implementation.
  • the ProcessFilter subroutine call from Figure 5 (506) passes FILTERS [FILTER INDEX] as an argument, which is the current filter it's trying to process. Inside the ProcessFilter subroutine in Figure 6, this is relevant to the FILTER input (600), and it looks for the last CHECKPOINT associated with the FILTER (602).
  • a CHECKPOINT is the timestamp at which the ProcessFilter call was executed last time for this specific FILTER.
  • TIMESTAMPED FILTER is constructed by taking the original FILTER and creating a new conjunction “AND” filter which adds an additional condition which ensures that “the timestamp of an EVENT must be greater than the CHECKPOINT for the current filter”.
  • Figure 7 demonstrates of using a MongoDB query language to represent a FILTER (700).
  • the events are stored in a certain format (In this case, the events are stored as a document with “out” attribute which has an “si” child attribute, but the details are not important, as events can be stored in any different format, for example a blockchain indexing system called BitDB stores all transaction objects as a MongoDB document, with various attributes representing input script push data, output script push data, transaction id, and so forth).
  • BitDB stores all transaction objects as a MongoDB document, with various attributes representing input script push data, output script push data, transaction id, and so forth.
  • an “AND” query may be formed of the original query and a timestamp related query which says, “items whose timestamps are greater than 1566616699610” (702).
  • the Event processor 402 queries the EVENT DB 410 with the TIMESTAMPED FILTER to fetch only the new events related to the FILTER since the last ProcessFilter call (606). Then it checks if there are any NEW EVENTS returned from the EVENT DB query (608). If the NEW_EVENTS is empty, then there has not been a new EVENT since last ProcessFilter call which pass the FILTER, so the subroutine needs to end. Before ending, there may be one more step. This may be where the CHECKPOINT is introduced.
  • the procedure call updates the checkpoint for the filter on CHECKPOINT DB (620).
  • the Event Processor 402 looks up whether the CHECKPOINT DB already has an entry associated with the FILTER (CHECKPOINT_DB.where(filter: FILTER)). If so, it updates its timestamp to the current timestamp acquired by calling a GET_TIMESTAMP() function (620).
  • GET_TIMESTAMP() function can be implemented.
  • the simplest approach may be to generate a UNIX timestamp on the fly.
  • Another way may be to utilize unique D fields supported by most database systems. For example, MongoDB automatically attaches an internal attribute named “ id” to all of its items when they are being created, where the id may be a combination of the creation timestamp and various other factors, and may be chronologically ordered. Since id attributes are chronologically ordered it fits our purpose of using the attribute as a timestamp, which can be used directly for checkpointing.
  • CHECKPOINT DB 414 finds that there may be no existing entry for the FILTER, it creates a new entry for the FILTER and sets its timestamp, so that the next time the ProcessFilter is called for the same FILTER it will have a checkpoint timestamp attached, as seen on 800.
  • the Event processor finds that the NEW EVENTS array length is greater than 0 (608), it needs to run the tasks associated with the FILTER, so it goes on to the next step where it looks up the TASK DB 404 for all the TASKS associated with the FILTER (610).
  • TASKS There may be one or more TASKS attached to a FILTER because many different clients may have submitted different tasks for the same FILTER. For example, one client may want the FILTER to trigger a Websocket push TASK, while another client may want the same FILTER to trigger an email or SMS send action, while another client may want the same FILTER to create another blockchain transaction and broadcast. They all share the same FILTER but have different TASKS.
  • the Event processor 402 needs to iterate through them and execute each. This execution can be either serially executed but also may be parallelized. To start the iteration process, the Event processor 402 sets the TASK INDEX to 0 (612). Then it checks whether the TASK INDEX is greater than or equal to the TASKS array length (614).
  • the TASK INDEX is greater than or equal to TASKS array length from the beginning, this would mean that the TASKS array is empty and there is no task to process, therefore it jumps to the next step 620 where it updates the CHECKPOINT DB 414 by updating the timestamp of the current FILTER on the CHECKPOINT DB 414 with the current timestamp via GET TIMESTAMP function call (620).
  • TASK INDEX is less than the TASKS array length, then it means that there are no non-empty TASKS array to process, so a task item at TASK INDEX of the TASKS array (TASKS[TASK_INDEX]) is selected and run the task by executing the task code, passing the entire NEW_EVENTS array as argument (616).
  • TASKS[TASK_INDEX] a task item at TASK INDEX of the TASKS array
  • it passes the entire relevant NEW_EVENTS array exactly once, which leaves room for much more flexible ways of processing events, and makes the whole process much more efficient.
  • the Event Processor updates the checkpoint for the FILTER by looking up the checkpoint entry associated with the FILTER from CHECKPOINT DB 414 and setting its timestamp (620). Then it ends the process.
  • all the iteration and array queries may be implemented in a streaming fashion. Instead of fetching an entire array of database query results into memory and iterating them one by one, the database queries may stream the data to the subsequent steps in real-time. For example, the flowchart in Figure 5 fetches all filters from the FILTER DB (500) and then iterates through them until the terminal condition is met (504).
  • the FILTER_DB.all() query in step 500 may create a real-time stream which feeds the results of the array into the subsequent steps as they are fetched, and the rest of the process including the ProcessFilter subroutine 506 may follow the same streaming paradigm, processing the filter one by one in a streaming format without waiting for the full FILTERS array to become fully available on memory.
  • step 602 fetches all CHECKPOINTS for the FILTER, or the step 606 where it queries all the NEW EVENTS since last checkpoint, or the step 610 where it queries TASK DB to return all TASKS related to the FILTER.
  • Any iteration logic mentioned in the primary embodiment can be turned into a streaming approach where the items of any array can be streamed to the next step without having to wait for the full arrays to become available in memory.
  • each component of the system may be distributed across multiple servers and locations.
  • the EVENT DB 410 may exist on server A
  • TASK DB 404 may exist on server B
  • FILTER DB 406 may exist on server C
  • CHECKPOINT DB 414 may exist on server D
  • Event Processor 402 may exist on server E
  • event listener 408 may exist on server F
  • Each component in Figure 4 may exist as a self-contained microservice which communicates with one another through their own exposed API which can either be publicly accessible or privately accessible.
  • every task execution (616) may be parallelized to multiple machines.
  • each TASK execution (310) may involve queueing a function execution instead of immediately executing.
  • it may utilize job queue systems such as Apache Kafka, Redis, RabbitMQ, etc. to schedule jobs and immediately return, instead of waiting for each task to finish running.
  • the TASK may have its own DSL (Domain Specific Language) to safely execute code.
  • DSL Domain Specific Language
  • the “TASK” column in the TASK DB 802 displays a JavaScript function (802). Often, allowing this type of arbitrary code execution can be dangerous, so the system may adopt a domain specific language or expose a limited API set to allow executing certain subset of tasks instead of allowing full fledged programming language code.
  • the client 400 may exist as multiple modules of their own.
  • Each module may have its own fine grained access control schemes.
  • the client 400 may be broken down so that one of the modules may only submit filters, and another module may only submit tasks. There may exist another module which creates links between the filters and the tasks.
  • the point is that there may be various ways to populate the TASK DB 404 and FILTER DB 406, and there may be various different configurations of providing access control, so that certain modules may have write access to TASK DB 404 but not to FILTER DB 406, and vice versa.
  • the tasks may be hardcoded into TASK DB 404, and the filters may be hardcoded into FILTER DB 406 as well.
  • the checkpoints can be more fine grained.
  • timestamps are attached to filters on the CHECKPOINT DB (800).
  • the checkpoints may be attached to tasks instead of filters. This may be important when there are multiple tasks attached to a single filter. For example if filter X needs to trigger task A, task B, and task C, instead of maintaining a CHECKPOINT DB which attaches timestamps to filters, may maintain a CHECKPOINT DB which attaches timestamps to individual tasks A, B, and C. It may be also possible to attach checkpoints to an entry made up of a combination of a filter and a task (1000).
  • TIMESTAMPED FILTER may be constructed for every task stored on CHECKPOINT DB 414 and TASK DB 404 (604).
  • the step 620 may be modified to “CHECKPOINT_DB.where(filter: FILTER && task: TASK).set(timestamp: GET_TIMESTAMP())””, which means “find the checkpoint on CHECKPOINT DB for the entry for the specific TASK which may be triggered by FILTER, and update its timestamp based on the GET_TIMESTAMP() function result”.
  • the CHECKPOINT DB in this case may look like (1000) in Figure 10. However this method is not limited to the approaches mentioned so far. Depending on the relationships between events, filters, and tasks, the CHECKPOINT DB may be structured differently.
  • a task may be attached to multiple filters, which means one task may be listening to multiple different conditions (filters).
  • filters For example, a task named A may have been scheduled to be triggered for an event pattern that matches filter X, filter Y, or filter Z.
  • the event processor 402 may be programmed in various ways.
  • each database component in Figure 4 may be implemented using any technology that allows for storing and retrieving data efficiently.
  • the term “database” it is not strictly limited to the systems call “databases”. This may include all types of persistent data storage and query systems such as document database (MongoDB), relational database (pgsql, mysql, etc.), graph database (neo4j, janusgraph, etc.), stream processing systems (Apache Kafka, Redis, RabbitMQ, etc.), key-value database (LevelDB, RocksDB, etc.) and more. Even a file system may be considered a “database” in this context, as long as the files are structured in certain ways to make retrieval more efficient.
  • Figure 10 provides an exemplary code of an alternative embodiment of the blockchain event processing database system.
  • all filters may be stored in FILTER DB (1004), each with its own unique FILTER ID.
  • this unique FILTER ID can be referenced in other tables such as TASK DB (1002) as a column, as well as CHECKPOINT DB as its own association column (1000).
  • the database may also exist as a completely in-memory data structure.
  • Figure 8 provides an exemplary code for providing a database structure for each database component in the blockchain event processing database system.
  • everything in Figure 8 can be stored completely in memory as a JavaScript object or array and accessed programmatically while the program may be running. This applies to all database modules in Figure 4, including EVENT DB 410, CHECKPOINT DB 414, FILTER DB 406, and TASK DB 404.
  • EVENT DB 410 This ability to utilize various database systems may be especially important for EVENT DB 410 because this means the system may be able to store and filter very sophisticated patterns of events, for example a graph database may be able to store events in a graph structure, which makes it efficient to filter a graph event pattern among multiple transactions. Same goes for relational database for events that are combinations of multiple other relationally associated events. And so on. It's important to note that when the EVENT DB 410 stores transactions in a certain database system, the filters stored in the FILTER DB 406 will naturally take the form of the query language for the underlying database system used in EVENT DB 410.
  • the timestamps stored for each filter or each task inside the CHECKPOINT DB 414 may be used along with the event itself, in the task processing carried out by the event processor 402.
  • an SSE (Server Sent Events) task may be triggered when certain event happens.
  • Server-Sent Events (SSE) may be a server push technology enabling a browser to receive automatic updates from a server via HTTP connection.
  • the Server-Sent Events EventSource API is standardized as part of HTML5 by the W3C.
  • One feature of server sent events is its ability to associate an event with a unique id.
  • an ID lets the browser keep track of the last event fired so that if, the connection to the server is dropped, a special HTTP header (Last-Event-ID) is set with the new request. This lets the browser determine which event is appropriate to fire.
  • the message event contains a e.lastEventld property.
  • the timestamp from the CHECKPOINT DB 414 may be utilized as the ID field, so that when a user's client briefly goes offline and comes back online later, it may request a synchronization using the Last-Event-ID header set as the last checkpoint timestamp, and the server may implement an additional module which sends all the events which happened since last checkpoint. This may work the same way as the approach explained in 702.
  • the backend system may check the Last-Event-ID HTTP header, and attach the “timestamp” query in conjunction to the original filter, and run it against the EVENT DB 410, which would return only the events which happened since the Last-Event- ID header value.
  • This is just one example to demonstrate how the timestamps from the CHECKPOINT DB 414 may be used in addition to the event itself when triggering tasks.
  • Figure 13 is an example of a combination filter.
  • the filters may be a combination of multiple other event filters. As shown, for example, 3 separate filters; FILTERl, FILTER2, and FILTER3, may be considered.
  • each filter works individually on its own, but a combination of these filters can be used to create a COMBINATION FILTER, which ensures that the three conditions FILTERl, FILTER2, and FILTER3 are satisfied simultaneously. This may be different from simply creating an AND conjunction query from the three filters, because the COMBINATION FILTER may be not targeted at a single event. For example, transaction A may pass the FILTERl condition, transaction B may pass the FILTER2 condition, and transaction C may pass the FILTER3 condition.
  • the EVENT DB 410 may be simply queried with a conjunction query constructed from the three filters FILTERl && FILTER2 && FILTER3, there would be no result because there is not a single transaction which matches all three filters simultaneously.
  • this will pass the COMBINATION FILTER because all it's looking for may be “some” transaction to match FILTER1, and “some” transaction to match FILTER2, and “some” transaction to match FILTER3, simultaneously. It doesn't require the matched transactions to be the same for each filter.
  • This feature may be only possible because of the database driven approach the current embodiments employ, because the system remembers the events even after processing them. It may be impossible to detect a pattern which exists over multiple event types like this, unless the events are stored in a database.
  • This feature may be used to detect various patterns in the network, such as detecting when a certain chain of transactions has completed over a long period of time.
  • customization may be required to deal with checkpoints.
  • the checkpoints may be updated every time an event processing may be run (620), which ensures that the event processing only monitors the least amount of dataset and process without redundancy.
  • the CHECKPOINT DB 414 should not update the checkpoint for the COMBINATION FILTER until a complete match is made.
  • the COMBINATION FILTER is looking for FILTERl, FILTER2, and FILTER3 to simultaneously pass, it should not update the checkpoint when only FILTERl passes, because that would make the TIMESTAMPED FILTER (702) only monitor events from the point at which FILTERl passed.
  • the filters may be used for not just testing the conditions, but also be used to return processed data from the database. This may be possible because of the use of database systems for the event processing instead of programmatically processing each and every event manually.
  • a filter may be used which finds all the events from EVENT DB 410 which match a certain pattern.
  • MongoDB may be used to store the events in EVENT DB 410, in which case a query may be made of “find” all events whose “out.sl” attributes match “19HxigV4QyBv3tHpQVclJEQyqlpzZVdoAut” (1100). This will return an array of full event objects.
  • the filters may not be just raw database query languages, but a higher level abstraction language which may be either a superset or a subset of each database query language.
  • Figure 11 illustrates various ways of representing filters with a JSON object. Expressing the queries in JSON makes it easy to serialize and deserialize filters and even send them over the network in order to make remote queries.
  • a domain specific language may be used whose syntax convention may be to wrap the filters in a “q” attribute where the child attributes of “q” are MongoDB's commands such as “find” or “project” and the children of these command attributes are the actual MongoDB query language.
  • the high level query language may also incorporate multiple query and filter languages into one.
  • a MongoDB query may be combined with JQ query, where the “q” attribute represents the MongoDB query and the “r.f ’ attribute represents a JQ expression which processes the results returned from the MongoDB query represented by “q” ( JQ may be a light-weight JSON processor engine).
  • the event listener 408 may implement a query engine which queries EVENT DB 410 with the contents of the “q” attribute, and then runs an additional post-processing step by passing the result to a separate JQ process defined by the expression under “r.f’ attribute.
  • the high level query language may be designed in a way that supports any type of database systems, such as key/value databases such as LevelDB or RocksDB (1106).
  • the query language may encapsulate a relational database query into the “q” attribute in case the EVENT DB 410 may be a relational database.
  • the EVENT DB can be implemented with any database system, so this high level abstraction query language may adopt a syntax which can encapsulate all database operations natively supported by any database systems.
  • the event processor 402 may run the processing routine of Figure 5 every 1 second.
  • the event listener 408 may implement a sophisticated job scheduler which determines when to run event processing for certain combinations of filters and tasks.
  • the algorithm may be determined by previous event processing history for example. Also it may be determined by manual or programmatic customization. For example the filter process may be triggered more frequently for certain task, or a certain filter, but less frequently for others. This way, higher priority filters and higher priority tasks can process events more frequently while low priority filters and low priority tasks don't need to be processed as frequently.
  • the term “about” refers to an amount that is near the stated amount by 10%, 5%, or 1%, including increments therein.
  • the term “about” in reference to a percentage refers to an amount that is greater or less the stated percentage by 10%, 5%, or 1%, including increments therein.
  • the phrases “at least one”, “one or more”, and “and/or” are open- ended expressions that are both conjunctive and disjunctive in operation.
  • each of the expressions “at least one of A, B and C”, “at least one of A, B, or C”, “one or more of A, B, and C”, “one or more of A, B, or C” and “A, B, and/or C” means A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B and C together.
  • FIG. 14 a block diagram is shown depicting an exemplary machine that includes a computer system 1400 (e.g., a processing or computing system) within which a set of instructions can execute for causing a device to perform or execute any one or more of the aspects and/or methodologies for static code scheduling of the present disclosure.
  • a computer system 1400 e.g., a processing or computing system
  • the components in Figure. 14 are examples only and do not limit the scope of use or functionality of any hardware, software, embedded logic component, or a combination of two or more such components implementing particular embodiments.
  • Computer system 1400 may include one or more processors 1401, a memory 1403, and a storage 1408 that communicate with each other, and with other components, via a bus
  • the bus 1440 may also link a display 1432, one or more input devices 1433 (which may, for example, include a keypad, a keyboard, a mouse, a stylus, etc.), one or more output devices 1434, one or more storage devices 1435, and various tangible storage media 1436. All of these elements may interface directly or via one or more interfaces or adaptors to the bus 1440. For instance, the various tangible storage media 1436 can interface with the bus 1440 via storage medium interface 1426.
  • Computer system 1400 may have any suitable physical form, including but not limited to one or more integrated circuits (ICs), printed circuit boards (PCBs), mobile handheld devices (such as mobile telephones or PDAs), laptop or notebook computers, distributed computer systems, computing grids, or servers.
  • ICs integrated circuits
  • PCBs printed circuit boards
  • mobile handheld devices such as mobile telephones or PDAs
  • laptop or notebook computers distributed computer systems, computing grids, or servers.
  • Computer system 1400 includes one or more processor(s) 1401 (e.g., central processing units (CPUs) or general purpose graphics processing units (GPGPUs)) that carry out functions.
  • processor(s) 1401 optionally contains a cache memory unit 1402 for temporary local storage of instructions, data, or computer addresses.
  • Processor(s) 1401 are configured to assist in execution of computer readable instructions.
  • Computer system 1400 may provide functionality for the components depicted in Figure 14 as a result of the processor(s) 1401 executing non-transitory, processor-executable instructions embodied in one or more tangible computer-readable storage media, such as memory 1403, storage 1408, storage devices 1435, and/or storage medium 1436.
  • the computer-readable media may store software that implements particular embodiments, and processor(s) 1401 may execute the software.
  • Memory 1403 may read the software from one or more other computer-readable media (such as mass storage device(s) 1435, 1436) or from one or more other sources through a suitable interface, such as network interface 1420.
  • the software may cause processor(s) 1401 to carry out one or more processes or one or more steps of one or more processes described or illustrated herein. Carrying out such processes or steps may include defining data structures stored in memory 1403 and modifying the data structures as directed by the software.
  • the memory 1403 may include various components (e.g., machine readable media) including, but not limited to, a random access memory component (e.g., RAM 1404) (e.g., static RAM (SRAM), dynamic RAM (DRAM), ferroelectric random access memory (FRAM), phase-change random access memory (PRAM), etc.), a read-only memory component (e.g., ROM 1405), and any combinations thereof.
  • ROM 1405 may act to communicate data and instructions uni directionally to processor(s) 1401
  • RAM 1404 may act to communicate data and instructions bidirectionally with processor(s) 1401.
  • ROM 1405 and RAM 1404 may include any suitable tangible computer-readable media described below.
  • a basic input/output system 1406 (BIOS), including basic routines that help to transfer information between elements within computer system 1400, such as during start up, may be stored in the memory 1403.
  • Fixed storage 1408 is connected bidirectionally to processor(s) 1401, optionally through storage control unit 1407.
  • Fixed storage 1408 provides additional data storage capacity and may also include any suitable tangible computer-readable media described herein.
  • Storage 1408 may be used to store operating system 1409, executable(s) 1410, data 1411, applications 1412 (application programs), and the like.
  • Storage 1408 can also include an optical disk drive, a solid-state memory device (e.g., flash-based systems), or a combination of any of the above.
  • Information in storage 1408 may, in appropriate cases, be incorporated as virtual memory in memory 1403.
  • storage device(s) 1435 may be removably interfaced with computer system 1400 (e.g., via an external port connector (not shown)) via a storage device interface 1425.
  • storage device(s) 1435 and an associated machine-readable medium may provide non-volatile and/or volatile storage of machine-readable instructions, data structures, program modules, and/or other data for the computer system 1400.
  • software may reside, completely or partially, within a machine-readable medium on storage device(s) 1435.
  • software may reside, completely or partially, within processor(s) 1401.
  • Bus 1440 connects a wide variety of subsystems.
  • reference to a bus may encompass one or more digital signal lines serving a common function, where appropriate.
  • Bus 1440 may be any of several types of bus structures including, but not limited to, a memory bus, a memory controller, a peripheral bus, a local bus, and any combinations thereof, using any of a variety of bus architectures.
  • Computer system 1400 may also include an input device 1433.
  • a user of computer system 1400 may enter commands and/or other information into computer system 1400 via input device(s) 1433.
  • Examples of an input device(s) 1433 include, but are not limited to, an alpha-numeric input device (e.g., a keyboard), a pointing device (e.g., a mouse or touchpad), a touchpad, a touch screen, a multi -touch screen, a joystick, a stylus, a gamepad, an audio input device (e.g., a microphone, a voice response system, etc.), an optical scanner, a video or still image capture device (e.g., a camera), and any combinations thereof.
  • the input device is a Kinect, Leap Motion, or the like.
  • Input device(s) 1433 may be interfaced to bus 1440 via any of a variety of input interfaces 1423 (e.g., input interface 1423) including, but not limited to, serial, parallel, game port, USB, FIREWIRE, THUNDERBOLT, or any combination of the above.
  • input interfaces 1423 e.g., input interface 1423
  • serial, parallel, game port USB, FIREWIRE, THUNDERBOLT, or any combination of the above.
  • computer system 1400 when computer system 1400 is connected to network 1430, computer system 1400 may communicate with other devices, specifically mobile devices and enterprise systems, distributed computing systems, cloud storage systems, cloud computing systems, and the like, connected to network 1430. Communications to and from computer system 1400 may be sent through network interface 1420.
  • network interface 1420 may receive incoming communications (such as requests or responses from other devices) in the form of one or more packets (such as Internet Protocol (IP) packets) from network 1430, and computer system 1400 may store the incoming communications in memory 1403 for processing.
  • Computer system 1400 may similarly store outgoing communications (such as requests or responses to other devices) in the form of one or more packets in memory 1403 and communicated to network 1430 from network interface 1420.
  • Processor(s) 1401 may access these communication packets stored in memory 1403 for processing.
  • Examples of the network interface 1420 include, but are not limited to, a network interface card, a modem, and any combination thereof.
  • Examples of a network 1430 or network segment 1430 include, but are not limited to, a distributed computing system, a cloud computing system, a wide area network (WAN) (e.g., the Internet, an enterprise network), a local area network (LAN) (e.g., a network associated with an office, a building, a campus or other relatively small geographic space), a telephone network, a direct connection between two computing devices, a peer-to-peer network, and any combinations thereof.
  • a network, such as network 1430 may employ a wired and/or a wireless mode of communication. In general, any network topology may be used.
  • Information and data can be displayed through a display 1432.
  • a display 1432 include, but are not limited to, a cathode ray tube (CRT), a liquid crystal display (LCD), a thin film transistor liquid crystal display (TFT-LCD), an organic liquid crystal display (OLED) such as a passive-matrix OLED (PMOLED) or active-matrix OLED (AMOLED) display, a plasma display, and any combinations thereof.
  • the display 1432 can interface to the processor(s) 1401, memory 1403, and fixed storage 1408, as well as other devices, such as input device(s) 1433, via the bus 1440.
  • the display 1432 is linked to the bus 1440 via a video interface 1422, and transport of data between the display 1432 and the bus 1440 can be controlled via the graphics control 1421.
  • the display is a video projector.
  • the display is a head-mounted display (HMD) such as a VR headset.
  • suitable VR headsets include, by way of non-limiting examples, HTC Vive, Oculus Rift, Samsung Gear VR, Microsoft HoloLens, Razer OSVR, FOVE VR, Zeiss VR One, Avegant Glyph, Freefly VR headset, and the like.
  • the display is a combination of devices such as those disclosed herein.
  • computer system 1400 may include one or more other peripheral output devices 1434 including, but not limited to, an audio speaker, a printer, a storage device, and any combinations thereof.
  • peripheral output devices may be connected to the bus 1440 via an output interface 1424.
  • Examples of an output interface 1424 include, but are not limited to, a serial port, a parallel connection, a USB port, a FIREWIRE port, a THUNDERBOLT port, and any combinations thereof.
  • computer system 1400 may provide functionality as a result of logic hardwired or otherwise embodied in a circuit, which may operate in place of or together with software to execute one or more processes or one or more steps of one or more processes described or illustrated herein.
  • Reference to software in this disclosure may encompass logic, and reference to logic may encompass software.
  • reference to a computer-readable medium may encompass a circuit (such as an IC) storing software for execution, a circuit embodying logic for execution, or both, where appropriate.
  • the present disclosure encompasses any suitable combination of hardware, software, or both.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • a general purpose processor may be a microprocessor, but in the alternative, the processor may be any processor, controller, microcontroller, or state machine.
  • a processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
  • a software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
  • An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium.
  • the storage medium may be integral to the processor.
  • the processor and the storage medium may reside in an ASIC.
  • the ASIC may reside in a user terminal.
  • the processor and the storage medium may reside as discrete components in a user terminal.
  • suitable computing devices include, by way of non-limiting examples, server computers, desktop computers, laptop computers, notebook computers, sub-notebook computers, netbook computers, netpad computers, set-top computers, media streaming devices, handheld computers, Internet appliances, mobile smartphones, tablet computers, personal digital assistants, video game consoles, and vehicles.
  • server computers desktop computers, laptop computers, notebook computers, sub-notebook computers, netbook computers, netpad computers, set-top computers, media streaming devices, handheld computers, Internet appliances, mobile smartphones, tablet computers, personal digital assistants, video game consoles, and vehicles.
  • Suitable tablet computers include those with booklet, slate, and convertible configurations, known to those of skill in the art.
  • the computing device includes an operating system configured to perform executable instructions.
  • the operating system is, for example, software, including programs and data, which manages the device’s hardware and provides services for execution of applications.
  • suitable server operating systems include, by way of non-limiting examples, FreeBSD, OpenBSD, NetBSD®, Linux, Apple® Mac OS X Server®, Oracle® Solaris®, Windows Server®, and Novell® NetWare®.
  • suitable personal computer operating systems include, by way of non-limiting examples, Microsoft® Windows®, Apple® Mac OS X®, UNIX®, and UNIX-like operating systems such as GNU/Linux®.
  • the operating system is provided by cloud computing.
  • suitable mobile smartphone operating systems include, by way of non-limiting examples, Nokia® Symbian® OS, Apple® iOS®, Research In Motion® BlackBerry OS®, Google® Android®, Microsoft® Windows Phone® OS, Microsoft® Windows Mobile® OS, Linux®, and Palm® WebOS®.
  • suitable media streaming device operating systems include, by way of non-limiting examples, Apple TV®, Roku®, Boxee®, Google TV®, Google Chromecast®, Amazon Fire®, and Samsung® HomeSync®.
  • video game console operating systems include, by way of non-limiting examples, Sony® PS3®, Sony® PS4®, Microsoft® Xbox 360®, Microsoft Xbox One, Nintendo® Wii®, Nintendo® Wii U®, and Ouya®.
  • Non-transitory computer readable storage medium
  • the platforms, systems, media, and methods disclosed herein include one or more non-transitory computer readable storage media encoded with a program including instructions executable by the operating system of an optionally networked computing device.
  • a computer readable storage medium is a tangible component of a computing device.
  • a computer readable storage medium is optionally removable from a computing device.
  • a computer readable storage medium includes, by way of non-limiting examples, CD-ROMs, DVDs, flash memory devices, solid state memory, magnetic disk drives, magnetic tape drives, optical disk drives, distributed computing systems including cloud computing systems and services, and the like.
  • the program and instructions are permanently, substantially permanently, semi-permanently, or non-transitorily encoded on the media.
  • the platforms, systems, media, and methods disclosed herein include at least one computer program, or use of the same.
  • a computer program includes a sequence of instructions, executable by one or more processor(s) of the computing device’s CPU, written to perform a specified task.
  • Computer readable instructions may be implemented as program modules, such as functions, objects, Application Programming Interfaces (APIs), computing data structures, and the like, that perform particular tasks or implement particular abstract data types.
  • APIs Application Programming Interfaces
  • a computer program comprises one sequence of instructions. In some embodiments, a computer program comprises a plurality of sequences of instructions. In some embodiments, a computer program is provided from one location. In other embodiments, a computer program is provided from a plurality of locations. In various embodiments, a computer program includes one or more software modules. In various embodiments, a computer program includes, in part or in whole, one or more web applications, one or more mobile applications, one or more standalone applications, one or more web browser plug-ins, extensions, add-ins, or add-ons, or combinations thereof.
  • a computer program includes a web application.
  • a web application in various embodiments, utilizes one or more software frameworks and one or more database systems.
  • a web application is created upon a software framework such as Microsoft® .NET or Ruby on Rails (RoR).
  • a web application utilizes one or more database systems including, by way of non-limiting examples, relational, non-relational, object oriented, associative, and XML database systems.
  • suitable relational database systems include, by way of non-limiting examples, Microsoft® SQL Server, mySQLTM, and Oracle®.
  • a web application in various embodiments, is written in one or more versions of one or more languages.
  • a web application may be written in one or more markup languages, presentation definition languages, client-side scripting languages, server-side coding languages, database query languages, or combinations thereof.
  • a web application is written to some extent in a markup language such as Hypertext Markup Language (HTML), Extensible Hypertext Markup Language (XHTML), or extensible Markup Language (XML).
  • a web application is written to some extent in a presentation definition language such as Cascading Style Sheets (CSS).
  • CSS Cascading Style Sheets
  • a web application is written to some extent in a client-side scripting language such as Asynchronous Javascript and XML (AJAX), Flash® Actionscript, Javascript, or Silverlight®.
  • AJAX Asynchronous Javascript and XML
  • a web application is written to some extent in a server- side coding language such as Active Server Pages (ASP), ColdFusion®, Perl, JavaTM, JavaServer Pages (JSP), Hypertext Preprocessor (PHP), PythonTM, Ruby, Tel, Smalltalk, WebDNA®, or Groovy.
  • a web application is written to some extent in a database query language such as Structured Query Language (SQL).
  • SQL Structured Query Language
  • a web application integrates enterprise server products such as IBM® Lotus Domino®.
  • a web application includes a media player element.
  • a media player element utilizes one or more of many suitable multimedia technologies including, by way of non-limiting examples, Adobe® Flash®, HTML 5,
  • an application provision system comprises one or more databases 1500 accessed by a relational database management system (RDBMS) 1510. Suitable RDBMSs include Firebird, MySQL, PostgreSQL, SQLite, Oracle Database, Microsoft SQL Server, IBM DB2, IBM Informix, SAP Sybase, SAP Sybase, Teradata, and the like.
  • the application provision system further comprises one or more application severs 1520 (such as Java servers, .NET servers, PHP servers, and the like) and one or more web servers 1530 (such as Apache, IIS, GWS and the like).
  • the web server(s) optionally expose one or more web services via app application programming interfaces (APIs) 1540.
  • APIs app application programming interfaces
  • an application provision system alternatively has a distributed, cloud-based architecture 1600 and comprises elastically load balanced, auto-scaling web server resources 1610 and application server resources 1620 as well synchronously replicated databases 1630.
  • a computer program includes a mobile application provided to a mobile computing device.
  • the mobile application is provided to a mobile computing device at the time it is manufactured.
  • the mobile application is provided to a mobile computing device via the computer network described herein.
  • a mobile application is created by techniques known to those of skill in the art using hardware, languages, and development environments known to the art. Those of skill in the art will recognize that mobile applications are written in several languages. Suitable programming languages include, by way of non-limiting examples, C, C++, C#, Objective-C, JavaTM, Javascript, Pascal, Object Pascal, PythonTM, Ruby, VB.NET, WML, and XHTML/HTML with or without CSS, or combinations thereof.
  • Suitable mobile application development environments are available from several sources. Commercially available development environments include, by way of non-limiting examples, AirplaySDK, alcheMo, Appcelerator®, Celsius, Bedrock, Flash Lite, .NET Compact Framework, Rhomobile, and WorkLight Mobile Platform. Other development environments are available without cost including, by way of non-limiting examples,
  • Lazarus, MobiFlex, MoSync, and Phonegap mobile device manufacturers distribute software developer kits including, by way of non-limiting examples, iPhone and iPad (iOS) SDK, AndroidTM SDK, BlackBerry® SDK, BREW SDK, Palm® OS SDK, Symbian SDK, webOS SDK, and Windows® Mobile SDK.
  • iOS iPhone and iPad
  • AndroidTM SDK AndroidTM SDK
  • BlackBerry® SDK BlackBerry® SDK
  • BREW SDK Palm® OS SDK
  • Symbian SDK Symbian SDK
  • webOS SDK webOS SDK
  • Windows® Mobile SDK Windows® Mobile SDK
  • a computer program includes a standalone application, which is a program that is run as an independent computer process, not an add-on to an existing process, e.g., not a plug-in.
  • standalone applications are often compiled.
  • a compiler is a computer program(s) that transforms source code written in a programming language into binary object code such as assembly language or machine code. Suitable compiled programming languages include, by way of non-limiting examples, C, C++, Objective-C, COBOL, Delphi, Eiffel, JavaTM, Lisp, PythonTM, Visual Basic, and VB.NET, or combinations thereof. Compilation is often performed, at least in part, to create an executable program.
  • a computer program includes one or more executable complied applications.
  • the computer program includes a web browser plug-in (e.g., extension, etc.).
  • a plug-in is one or more software components that add specific functionality to a larger software application. Makers of software applications support plug ins to enable third-party developers to create abilities which extend an application, to support easily adding new features, and to reduce the size of an application. When supported, plug ins enable customizing the functionality of a software application. For example, plug-ins are commonly used in web browsers to play video, generate interactivity, scan for viruses, and display particular file types. Those of skill in the art will be familiar with several web browser plug-ins including, Adobe ® Flash ® Player, Microsoft ® Silverlight ® , and Apple ® QuickTime ® .
  • the toolbar comprises one or more web browser extensions, add-ins, or add-ons. In some embodiments, the toolbar comprises one or more explorer bars, tool bands, or desk bands.
  • plug-in frameworks are available that enable development of plug-ins in various programming languages, including, by way of non-limiting examples, C++, Delphi, JavaTM, PHP, PythonTM, and VB.NET, or combinations thereof.
  • Web browsers are software applications, designed for use with network-connected computing devices, for retrieving, presenting, and traversing information resources on the World Wide Web. Suitable web browsers include, by way of non-limiting examples, Microsoft ® Internet Explorer ® , Mozilla ® Firefox ® , Google ® Chrome, Apple ® Safari ® , Opera Software ® Opera ® , and KDE Konqueror. In some embodiments, the web browser is a mobile web browser.
  • Mobile web browsers are designed for use on mobile computing devices including, by way of non-limiting examples, handheld computers, tablet computers, netbook computers, subnotebook computers, smartphones, music players, personal digital assistants (PDAs), and handheld video game systems.
  • Suitable mobile web browsers include, by way of non-limiting examples, Google ® Android ® browser, RIM BlackBerry ® Browser, Apple ® Safari ® , Palm ® Blazer, Palm ® WebOS ® Browser, Mozilla ® Firefox ® for mobile, Microsoft ® Internet Explorer ® Mobile, Amazon ® Kindle ® Basic Web, Nokia ® Browser, Opera Software ® Opera ® Mobile, and Sony ® PSPTM browser.
  • the platforms, systems, media, and methods disclosed herein include software, server, and/or database modules, or use of the same.
  • software modules are created by techniques known to those of skill in the art using machines, software, and languages known to the art.
  • the software modules disclosed herein are implemented in a multitude of ways.
  • a software module comprises a file, a section of code, a programming object, a programming structure, or combinations thereof.
  • a software module comprises a plurality of files, a plurality of sections of code, a plurality of programming objects, a plurality of programming structures, or combinations thereof.
  • the one or more software modules comprise, by way of non-limiting examples, a web application, a mobile application, and a standalone application.
  • software modules are in one computer program or application. In other embodiments, software modules are in more than one computer program or application. In some embodiments, software modules are hosted on one machine. In other embodiments, software modules are hosted on more than one machine. In further embodiments, software modules are hosted on a distributed computing platform such as a cloud computing platform. In some embodiments, software modules are hosted on one or more machines in one location. In other embodiments, software modules are hosted on one or more machines in more than one location.
  • the platforms, systems, media, and methods disclosed herein include one or more databases, or use of the same.
  • suitable databases include, by way of non-limiting examples, relational databases, non-relational databases, object oriented databases, object databases, entity-relationship model databases, associative databases, and XML databases. Further non-limiting examples include SQL, PostgreSQL, MySQL, Oracle, DB2, and Sybase.
  • a database is internet-based.
  • a database is web-based.
  • a database is cloud computing-based.
  • a database is a distributed database.
  • a database is implemented on one or more local computer storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un système de base de données de traitement d'événements qui stocke les événements dans une base de données facile à interroger. Les systèmes de traitement d'événements selon l'invention sont susceptibles d'être élargis facilement et en toute sécurité, utilisent un langage d'interrogation adaptable pour filtrer diverses structures de flux d'événements de diverses manières, et peuvent détecter des combinaisons d'événements multiples.
PCT/US2020/049068 2019-09-03 2020-09-02 Système de base de données de traitement d'événements de chaîne de blocs WO2021046129A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201962895024P 2019-09-03 2019-09-03
US62/895,024 2019-09-03

Publications (1)

Publication Number Publication Date
WO2021046129A1 true WO2021046129A1 (fr) 2021-03-11

Family

ID=74853302

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2020/049068 WO2021046129A1 (fr) 2019-09-03 2020-09-02 Système de base de données de traitement d'événements de chaîne de blocs

Country Status (1)

Country Link
WO (1) WO2021046129A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150082392A1 (en) * 1997-06-11 2015-03-19 Prism Technologies Llc Method for managing access to protected computer resources
US20160292672A1 (en) * 2015-03-31 2016-10-06 Nasdaq, Inc. Systems and methods of blockchain transaction recordation
US20170109735A1 (en) * 2015-07-14 2017-04-20 Fmr Llc Computationally Efficient Transfer Processing and Auditing Apparatuses, Methods and Systems
US20170232300A1 (en) * 2016-02-02 2017-08-17 Bao Tran Smart device
US20170287090A1 (en) * 2016-03-31 2017-10-05 Clause, Inc. System and method for creating and executing data-driven legal contracts

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150082392A1 (en) * 1997-06-11 2015-03-19 Prism Technologies Llc Method for managing access to protected computer resources
US20160292672A1 (en) * 2015-03-31 2016-10-06 Nasdaq, Inc. Systems and methods of blockchain transaction recordation
US20170109735A1 (en) * 2015-07-14 2017-04-20 Fmr Llc Computationally Efficient Transfer Processing and Auditing Apparatuses, Methods and Systems
US20170232300A1 (en) * 2016-02-02 2017-08-17 Bao Tran Smart device
US20170287090A1 (en) * 2016-03-31 2017-10-05 Clause, Inc. System and method for creating and executing data-driven legal contracts

Similar Documents

Publication Publication Date Title
US11243981B2 (en) Database replication based on data access scores
JP7333424B2 (ja) 分散イベント処理システムのためのグラフ生成
US10503493B2 (en) Distributed versioning of applications using cloud-based systems
US11663205B2 (en) Technologies for asynchronous querying
US10827036B2 (en) Version control machine
US9660859B1 (en) Methods and systems for quantum ready computations on the cloud
WO2018119522A1 (fr) Procédés et systèmes pour des réseaux informatiques quantiques unifiés
US9600342B2 (en) Managing parallel processes for application-level partitions
US10977011B2 (en) Structured development for web application frameworks
US11144438B1 (en) Incremental build system using an inferred dependency graph collected with a system monitor
KR102614428B1 (ko) 다-계층 클라우드-기반 애플리케이션 스택들을 업데이트하기 위한 시스템들 및 방법들
US20200125566A1 (en) Efficient extraction of large data sets from a database
US12019534B2 (en) Out-of-the-box telemetry for rich-client application runtime frameworks
US10430926B1 (en) Systems, media, and methods for improving responsiveness of spotlight tours in a dynamic viewport environment
US20190129624A1 (en) Cloud-based development environment with deduplication engine improving storage efficiency
US11106670B2 (en) Local identifiers for database objects
WO2021046129A1 (fr) Système de base de données de traitement d'événements de chaîne de blocs
US20230306039A1 (en) Updating one or more databases based on dataflow events
US20210297497A1 (en) System for correlating separate events
US11150789B2 (en) Method, systems, and media to arrange a plurality of digital images within an image display section of a graphical user inteface (GUI)
US11681772B2 (en) Systems, methods, and media enabling streamlined user experiences across progressive web applications
US20240028590A1 (en) Systems and methods for querying data
WO2023034597A1 (fr) Procédés et systèmes pour améliorer la technologie de chaîne de blocs

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20860385

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 23.06.2022)

122 Ep: pct application non-entry in european phase

Ref document number: 20860385

Country of ref document: EP

Kind code of ref document: A1