Adjusting transaction distribution based on predicted outstanding transaction execution rate

文档序号：1909608 发布日期：2021-11-30 浏览：18次中文

阅读说明：本技术 基于预测的未结交易执行率来调整交易分布 (Adjusting transaction distribution based on predicted outstanding transaction execution rate ) 是由徐茂栋阿舒·斯瓦米于 2020-02-25 设计创作，主要内容包括：一种交易处理系统(130)被配置成接收交易请求以在多个第三方系统(108)中的一个或多个处执行交易。交易处理系统(130)访问调整后交易记录,该调整后交易记录存储从多个第三方系统(108)接收的多个未结交易。交易处理系统(130)进一步将交易请求划分(530)为一个或多个拆分交易请求。一个或多个拆分交易请求被发送(540)到对应的第三方系统(108)以供执行。对应的第三方系统(108)以每个拆分交易的请求单位计数执行对应于每个拆分交易的未结交易。作为响应,交易处理系统(130)从多个第三方系统(108)中的一个或多个接收(550)执行报告。(A transaction processing system (130) is configured to receive a transaction request to perform a transaction at one or more of a plurality of third party systems (108). The transaction processing system (130) accesses an adjusted transaction record that stores a plurality of outstanding transactions received from a plurality of third party systems (108). The transaction processing system (130) further divides (530) the transaction request into one or more split transaction requests. One or more split transaction requests are sent (540) to corresponding third party systems (108) for execution. The corresponding third party system (108) executes the outstanding transactions corresponding to each split transaction at the request unit count for each split transaction. In response, the transaction processing system (130) receives (550) an execution report from one or more of the plurality of third party systems (108).)

1. A system, comprising:

a transaction processing system configured to:

receiving a transaction request to perform a transaction at one or more of a plurality of third party systems, the transaction request including a requested unit count;

accessing an adjusted transaction record, the adjusted transaction record storing a plurality of outstanding transactions received from the plurality of third-party systems, each of the plurality of outstanding transactions storing an adjusted unit count for the outstanding transaction, an adjusted available transactions list generated by:

calculating the adjusted unit count for each outstanding transaction in the plurality of outstanding transactions for each third-party system by modifying the reported unit count for each outstanding transaction using a prediction score generated according to a prediction model that generates the prediction score based on a difference between the reported unit count for previously executed outstanding transactions and the executed unit count for executed outstanding transactions; and

dividing the transaction request into one or more split transaction requests, each split transaction request associated with an outstanding transaction of the plurality of outstanding transactions in the adjusted transaction record, a request unit count for each split transaction not exceeding the adjusted unit count for the outstanding transaction associated with each split transaction, and wherein each split transaction request corresponds to one of the plurality of third-party systems providing the outstanding transaction associated with each split transaction; and

sending each of the one or more split transaction requests to a corresponding third-party system for execution, wherein the corresponding third-party system executes the open transaction corresponding to each split transaction in the request unit count for each split transaction.

2. The system of claim 1, wherein the transaction processing system is further configured to:

receiving an execution report from one or more of the plurality of third-party systems, the execution report indicating: a count of executed units of execution of the outstanding transaction corresponding to each split transaction of the one or more split transactions.

3. The system of claim 2, wherein the predictive model is further generated by:

determining, for each of a plurality of executed outstanding transactions, whether an executed unit count of the executed outstanding transactions is greater than, less than, or equal to a reporting unit count of the executed outstanding transactions;

generating a positive actual score for the executed unbundled transaction in response to the executed unit count of the executed unbundled transaction being greater than the reported unit count of the executed unbundled transaction;

generating a negative actual score for the executed knotless transaction in response to the executed unit count of the executed knotless transaction being less than the reported unit count of the executed knotless transaction;

generating an actual score of zero for the executed outstanding transaction in response to the executed unit count of the executed outstanding transaction being equal to the reported unit count of the executed outstanding transaction; and

generating the predictive model based on the actual scores generated for the plurality of executed outstanding transactions.

4. The system of claim 3, wherein the actual score for each executed outstanding transaction is generated by:

determining a first result as a minimum of the reported unit count of executed outstanding transactions and the requested unit count of executed outstanding transactions minus 1;

determining a second result as a ratio between the executed unit count and the first result; and

determining the actual score as the minimum between 1 and the second result.

5. The system of claim 3 or 4, wherein non-close transactions requested to be executed but not executed are assigned a zero executed unit count.

6. The system of claim 3, 4, or 5, wherein the executed units count of an unlisted transaction executed at a third party system is added to the executed units count of a unlisted transaction having a value amount closest to the unlisted transaction, the unlisted transaction being an unlisted transaction executed at a third party system and not listed in the adjusted transaction record, the unlisted transaction being an unlisted transaction executed at a third party system and listed in the adjusted transaction record.

7. The system of any of claims 3 to 6, wherein the predictive model is further generated by:

generating a regression model, inputs to the regression model being actual scores sampled from a plurality of buckets, each bucket including an actual score of an executed outstanding transaction from a third-party system, wherein an execution timestamp of the executed outstanding transaction is within a recency range of the bucket, the regression model generating the predicted scores indicating possible values of actual scores of outstanding transactions.

8. The system of claim 7, wherein the actual scores are sampled from one hour intervals within the recency range of each bucket.

9. The system of any of the preceding claims, wherein modifying the report unit count for each outstanding transaction further comprises:

increasing the predictive score generated for the outstanding transaction by one; and

multiplying the reported unit count for the outstanding transaction by an incremented predicted score to generate the adjusted unit count for the outstanding transaction.

10. The system of any preceding claim, wherein the transaction processing system divides the transaction requests into the one or more split transaction requests by selecting one or more outstanding transactions from the highest ranked ones of the plurality of outstanding transactions in the adjusted transaction records, a sum of the report unit counts of the selected one or more outstanding transactions being greater than or equal to the requested unit count of the transaction request, the plurality of outstanding transactions in the adjusted transaction records being ordered according to a value amount of each outstanding transaction in the adjusted transaction records.

11. A method, comprising:

receiving a transaction request to perform a transaction at one or more of a plurality of third party systems, the transaction request including a requested unit count;

dividing the transaction request into one or more split transaction requests, each split transaction request associated with an unspent transaction of the plurality of unspent transactions in the adjusted transaction record, a request unit count of each split transaction not exceeding the adjusted unit count of the unspent transaction associated with each split transaction, and wherein each split transaction request corresponds to one of the plurality of third-party systems that provides the unspent transaction associated with each split transaction; and

sending each of the one or more split transaction requests to a corresponding third-party system for execution, wherein the corresponding third-party system executes the outstanding transactions corresponding to each split transaction in the request unit count for each split transaction.

12. The method of claim 11, further comprising:

13. The method of claim 12, wherein the predictive model is further generated by:

generating the predictive model based on the actual scores generated for the plurality of executed outstanding transactions.

14. The method of claim 13, wherein the actual score for each executed outstanding transaction is generated by:

determining a first result as a minimum of the reported unit count of executed outstanding transactions and the requested unit count of executed outstanding transactions minus 1;

determining a second result as a ratio between the executed unit count and the first result; and

determining the actual score as the minimum between 1 and the second result.

15. The method of claim 13 or 14, wherein non-end transactions requested for execution but not executed are assigned a zero executed unit count.

16. The method of claim 13, 14, or 15, wherein a count of executed units of an unlisted transaction executed at a third party system is added to a count of executed units of an unlisted transaction having a value amount closest to the unlisted transaction, the unlisted transaction being an unlisted transaction executed at a third party system and not listed in the adjusted transaction record, the unlisted transaction being an unlisted transaction executed at a third party system and listed in the adjusted transaction record.

17. The method of any of claims 13 to 16, wherein the predictive model is further generated by:

18. The method of claim 17, wherein the plurality of buckets includes buckets having recency ranges within hours, days, weeks, and months of a current timestamp.

19. The method of any of claims 11 to 18, wherein modifying the report unit count for each outstanding transaction further comprises:

increasing the predictive score generated for the outstanding transaction by one; and

multiplying the reported unit count for the outstanding transaction by an incremented predicted score to generate the adjusted unit count for the outstanding transaction.

20. The method of any of claims 11 to 19, wherein the transaction processing system divides the transaction request into the one or more split transaction requests by selecting one or more outstanding transactions from a highest-ranked of the plurality of outstanding transactions in the adjusted transaction records, a sum of report unit counts for the selected one or more outstanding transactions being greater than or equal to the request unit count for the transaction request, the plurality of outstanding transactions in the adjusted transaction records being ordered according to a value amount for each outstanding transaction in the adjusted transaction records.

21. Software which when executed causes the method of any one of claims 11 to 20 to be performed.

Technical Field

The present invention relates generally to data prediction, and in particular to adjusting transaction distribution based on predicted outstanding transaction execution rate.

Background

In some networked systems, the third party systems may each provide a list of outstanding transactions that the processing system may request to execute. These third party systems may provide a list of such outstanding transactions via one or more data feeds transmitted to the processing system. However, in some cases, some unjoined transactions may not be disclosed via the data feed. If the processing system requests that transactions be performed from these systems, the third party system may accidentally perform one of these undisclosed outstanding transactions. Further, some of the outstanding transactions occurring in the data feed may not be actual outstanding transactions, but may be programmatically generated based on other outstanding transactions in the data feed in order to modify overall statistics of outstanding transactions in the data feed provided by the third-party system. Attempting to request execution of these programmatically generated outstanding transactions may result in a failure because they are not actual outstanding transactions available for execution. Thus, the processing system cannot properly execute transactions based on the transactions reported in the data feed. Thus, there is a lack of a method for requesting execution of a transaction that better matches the actual outstanding transactions available on the third-party system, resulting in predicted execution results that match the actual execution results.

Throughout this specification the word "comprise", or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.

Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present invention as it existed before the priority date of each appended claim.

Disclosure of Invention

Embodiments relate to a system including a transaction processing system configured to receive a transaction request to perform a transaction at one or more of a plurality of third party systems, the transaction request including a requested unit count.

The transaction processing system accesses an adjusted transaction record that stores a plurality of outstanding transactions received from a plurality of third-party systems, wherein each of the plurality of outstanding transactions stores an adjusted unit count for the outstanding transaction.

The adjusted available transaction list is generated by: an adjusted unit count for each outstanding transaction in the plurality of outstanding transactions of each third-party system is calculated by modifying the reported unit count for each outstanding transaction using the prediction score generated according to the prediction model. The prediction model generates a prediction score based on a difference between a reported unit count of previously executed outstanding transactions and an executed unit count of executed outstanding transactions.

The transaction processing system further divides the transaction request into one or more split transaction requests. Each split transaction request is associated with an outstanding transaction of the plurality of outstanding transactions in the adjusted transaction record, and the request unit count for each split transaction does not exceed the adjusted unit count for the outstanding transaction associated with each split transaction. Each split transaction request corresponds to one of a plurality of third-party systems that provides an outstanding transaction associated with each split transaction.

One or more split transaction requests are sent to a corresponding third party system for execution. The corresponding third party system performs the outstanding transactions corresponding to each split transaction in the request unit count for each split transaction.

In response, the transaction processing system may receive an execution report from one or more of the plurality of third-party systems, the execution report indicating: a count of executed units of execution of an outstanding transaction corresponding to each split transaction of the one or more split transactions.

The predictive model may also be generated by: determining, for each of a plurality of executed outstanding transactions, whether the executed unit count of executed outstanding transactions is greater than, less than, or equal to a reported unit count of executed outstanding transactions; generating a positive actual score for the executed unbundled transaction in response to the executed units count of the executed unbundled transaction being greater than the reported units count of the executed unbundled transaction; generating a negative actual score for the executed unbundled transaction in response to the executed unit count of the executed unbundled transaction being less than the reported unit count of the executed unbundled transaction; generating an actual score of zero for the executed unbundled transaction in response to the executed units count of the executed unbundled transaction being equal to the reported units count of the executed unbundled transaction; and generating a predictive model based on the actual scores generated for the plurality of executed outstanding transactions.

The actual score for each executed outstanding transaction may be generated by: determining the first result as a minimum of a report unit count that the outstanding transaction has been performed and a request unit count that the outstanding transaction has been performed minus 1; determining the second result as a ratio between the executed unit count and the first result; and determining the actual score as the minimum between 1 and the second result.

The outstanding transactions that are requested to execute but not execute may be given an executed unit count of zero.

The executed units count of the outstanding transactions executed at the third-party system may be added to the executed units count of the outstanding transactions having the closest value amount to the outstanding transactions, which may be outstanding transactions executed at the third-party system and not listed in the adjusted transaction record, which may be outstanding transactions executed at the third-party system and listed in the adjusted transaction record.

The predictive model may also be generated by: a regression model is generated, inputs to which are actual scores sampled from a plurality of buckets (buckets), each bucket including an actual score of an executed outstanding transaction from a third-party system, the execution timestamp being within a recency range of the bucket, the regression model generating a predicted score indicating a possible value of the actual score of the outstanding transaction.

The actual scores may be sampled from one hour intervals within the recency range of each bucket.

Modifying the report unit count for each outstanding transaction may further include: adding one to the predictive score generated for the outstanding transaction; and multiplying the reported unit count for the outstanding transactions by the incremented predicted score to generate an adjusted unit count for the outstanding transactions.

The transaction processing system may divide the transaction request into one or more split transaction requests by selecting one or more outstanding transactions from the adjusted transaction records having the highest ranking among the plurality of outstanding transactions in the adjusted transaction records, a sum of the report unit counts of the selected one or more outstanding transactions may be greater than or equal to the request unit count of the transaction request, and the plurality of outstanding transactions in the adjusted transaction records may be ordered according to a value amount of each outstanding transaction in the adjusted transaction records.

Embodiments are also directed to a method comprising: receiving a transaction request to perform a transaction at one or more of the plurality of third party systems, the transaction request including a requested unit count; accessing an adjusted transaction record, the adjusted transaction record storing a plurality of outstanding transactions received from a plurality of third party systems, each of the plurality of outstanding transactions storing an adjusted unit count of outstanding transactions, the adjusted available transaction list generated by: calculating an adjusted unit count for each outstanding transaction of the plurality of outstanding transactions for each third-party system by modifying the reported unit count for each outstanding transaction using a prediction score generated according to a prediction model that generates a prediction score based on a difference between the reported unit count for a previously executed outstanding transaction and the executed unit count for an executed outstanding transaction; and dividing the transaction request into one or more split transaction requests, each split transaction request associated with an unspent transaction of the plurality of unspent transactions in the adjusted transaction record, a request unit count of each split transaction not exceeding the adjusted unit count of the unspent transaction associated with each split transaction, and wherein each split transaction request corresponds to one of the plurality of third-party systems providing the unspent transaction associated with each split transaction; each of the one or more split transaction requests is sent to a corresponding third party system for execution, wherein the corresponding third party system executes the open transaction corresponding to each split transaction in the request unit count for each split transaction.

The method may further comprise: an execution report is received from one or more of the plurality of third party systems, the execution report indicating a count of executed units of execution of the outstanding transactions corresponding to each of the one or more split transactions.

The actual score for each executed outstanding transaction may be generated by: determining the first result as the minimum of the report unit count that the open transaction has been performed and the request unit count that the open transaction has been performed minus 1; determining the second result as a ratio between the executed unit count and the first result; and determining the actual score as the minimum between 1 and the second result.

The outstanding transactions that are requested to execute but not execute may be given an executed unit count of zero.

The predictive model may also be generated by: generating a regression model whose inputs are actual scores sampled from a plurality of buckets, each bucket including an actual score of executed outstanding transactions from a third party system, the execution timestamp being within a recency range of the bucket, the regression model generating a predicted score indicating a likely value of the actual score of the outstanding transactions.

The plurality of buckets may include buckets having a recency range within the hour, day, week, and month of the current timestamp.

Another embodiment relates to software that is computer readable instructions (transitory or non-transitory) that, when executed, cause the above-described method to be performed.

Drawings

Figure (fig. 1) illustrates an example system with a transaction analyzer that generates adjusted transaction records for adjusting transaction distributions based on predicted outstanding transaction execution rates, according to embodiments.

Fig. 2 is a block diagram that illustrates components of the transaction analyzer of fig. 1, according to an embodiment.

Fig. 3A is a block diagram and flow diagram illustrating an example of generating an adjusted transaction record, according to an embodiment.

Fig. 3B is a block diagram and flowchart that continues the example shown in fig. 3A according to an embodiment.

FIG. 5 is a flow diagram illustrating an example process for adjusting a transaction distribution based on a predicted outstanding transaction execution rate, according to an embodiment.

Fig. 6A is a block diagram illustrating a transaction chain recorded on a blockchain that may be used in the system described in fig. 1, according to an embodiment.

Fig. 6B is a block diagram illustrating the connection of multiple blocks in a blockchain that may be used in the system described in fig. 1, according to an embodiment.

Fig. 7 is a block diagram illustrating an example computing device, according to an embodiment.

For the purpose of illustration only, the drawings depict and detailed description describes various non-limiting embodiments

Detailed Description

The drawings (figures) and the following description relate to preferred embodiments by way of illustration only. One skilled in the art may recognize alternative embodiments of the structures and methods disclosed herein as viable alternatives that may be employed without departing from the principles disclosed.

Reference will now be made in detail to several embodiments, examples of which are illustrated in the accompanying drawings. It should be noted that wherever practicable similar or like reference numbers may be used in the figures and may indicate similar or like functionality. The figures depict embodiments of the disclosed system (or method) for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.

Overview of the System

Fig. 1 illustrates an example system having a transaction analyzer 124 that generates an adjusted transaction record for adjusting a transaction profile based on a predicted outstanding transaction execution rate, according to an embodiment. The system 100 includes a network 102, one or more client devices 106 (often referred to as a client device/plurality of client devices 106), one or more third party systems 108A-N (often referred to as a third party system/plurality of third party systems 108), each having a third party interface 112 (also referred to as a third party interface 112A-N). The system 100 also includes a transaction processing system 130 having a unspent transaction record store 114, a unspent transaction record history store 116 storing historical unspent transaction records 118, an executed transaction record history store 120 storing executed transactions 122 generated by the smart transaction router system 128, and a transaction analyzer 124 for receiving data from various data stores to generate an adjusted transaction record store 126 for the smart transaction router system 128. In various embodiments, system 100 may include different, fewer, or additional components. The components in the system 100 may each correspond to a separate and independent entity or may be controlled by the same entity.

Communications between elements in system 100 may be transmitted via network 102, network 102 may be, for example, the internet, a local area network, and so forth. Some elements may communicate over one network while other elements may communicate using a separate network. Each of these separate networks may be similar to network 102. In one embodiment, network 102 uses standard communication technologies and/or protocols. Thus, the network 102 may include networks using, for example, Ethernet, 702.11, direct microwave point-to-point connectivity, Worldwide Interoperability for Microwave Access (WiMAX), 3G, Digital Subscriber Line (DSL), Asynchronous Transfer Mode (ATM), InfiniBand, PCI express advanced switching, and the like. Similarly, the network protocols used on network 102 may include multiprotocol label switching (MPLS), transmission control protocol/internet protocol (TCP/IP), User Datagram Protocol (UDP), hypertext transfer protocol (HTTP), Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), and the like. Data exchanged over network 102 may be represented using techniques and/or formats including hypertext markup language (HTML), extensible markup language (XML), and the like. In addition, all or some of the links may be encrypted using conventional encryption techniques, such as Secure Sockets Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), internet protocol security (IPsec), and so forth. In another embodiment, elements in system 110 may use custom data communication techniques and/or dedicated data communication techniques instead of or in addition to the above-described techniques. For example, network 102 may use lean TCP/IP protocols that avoid TCP/IP handshake penalties between elements to reduce communication delays.

The one or more client devices 106 are computing devices that may be operated by a user and used by the user as front-end devices with which the user may access data generated by the transaction processing system 130 and submit requests to the transaction processing system 130. For example, the client device 106 can present a list of outstanding transactions to the user and allow the user to submit a request to execute the transaction. The client device 106 may be any computing device. Examples of client devices 106 include a Personal Computer (PC), a desktop computer, a laptop computer, a tablet computer, a smartphone, a wearable electronic device such as a smart watch, or any other suitable electronic device.

The client devices 106 may each include an interface 104, which may be provided by computer readable instructions provided by a transaction processing system 130 (e.g., the smart transaction router system 128) or executed by the client devices 106. The user can access the data via the interface 104 or be available at the transaction processing system 130. In addition, the user can also submit transaction requests via the interface 104. The interface 104 may take different forms. In one embodiment, the interface 104 is a component of a software application that may be provided by the transaction processing system 130. For example, the software application may provide a front-end user interface that may be provided at the client device 106. The software application may be a package of computer executable code that may be acquired (e.g., downloaded) and installed or executed at the client device 106. In another embodiment, the interface 104 may be an interface provided directly via the transaction processing system 130 or other server. For example, the interface 104 may be one or more web pages. The interface 104 may include a Graphical User Interface (GUI) that displays various information and graphical elements. In another embodiment, the interface 104 may not include graphical elements but may communicate with the transaction processing system 130 via other suitable means, such as an Application Program Interface (API).

The third-party systems 108A-N each include one or more computing systems that each provide one or more data feeds (referred to as data feed/data feeds 113) to the transaction processing system 130, and in particular to the open transaction record store 114. The data feed 110 includes continuously updated information about one or more particular data sources. The data sources may contain information about some elements described in the data feed 110, such as transactions (e.g., orders made in financial markets, purchase orders for retail organizations, logistics updates, shipping information), news (e.g., breaking news), forecasts (e.g., weather reports), current status (e.g., equipment status, public transportation, satellite location), and so forth. The data feed 110 may be provided using various data formats such as CSV (comma separated values), XML (extensible markup language), and the like. The data feed may be provided using a custom format, such as using an extended character set or using binary characters, and the data therein may be encrypted prior to transmission.

The data feed 110, when provided, may be transmitted in one or more updates. Each update may occur as data is generated or may be generated periodically. For example, in the case of a transaction, the updates in the data feed 110 include data entries describing new outstanding transactions, modifications to existing outstanding transactions, executed transactions, and the like. Each update may have information about the data feed 110 itself (e.g., an identifier or symbol indicating the type of data the data feed 110 is presenting), as well as information about the elements being described. For example, in the case of a transaction, the corresponding data feed entry may include information regarding the transaction type, the amount of value, the transaction timestamp, and the like. By receiving the data feed update, the recipient computing device can determine the current state of the elements described in the data feed 110. For example, where the data feed 110 includes information about transactions, the recipient of the data feed 110 allows the system to determine the complete status of the transactions described by the data feed, i.e., determine the current status of the market/exchange that includes those transactions.

Each third-party system 108 may also optionally include a third-party system interface 112 that allows computing systems external to the third-party system 108 to access data generated or stored at the third-party system 108, such as the data feed 110. The third party system interface 112 may present standardized data access methods to external systems, such as via the use of an Application Programming Interface (API) or other known or well-defined processes. These standardized data access methods may also allow external systems, such as the transaction processing system 130, to authenticate to the third party system 108. The standardized data access method may obey REST (representational state transfer) constraints.

The transaction processing system 130 includes one or more computing systems configured to process data received from the third-party system 108, provide this information to a user (e.g., a user of the client device 106), and execute transactions requested by the user via the client device 106. The transaction processing system 130 may include an outstanding transaction record store 114, an outstanding transaction record history store 116, an executed transaction record history store 120, a smart transaction router system 128, a transaction analyzer 124, and an adjusted transaction record store 126. However, in other embodiments, these components may be separate from the transaction processing system 130 and may execute within separate computing systems that are connected via the network 102 or via some other connection (e.g., a high-speed interconnect).

The outstanding transaction records store 114 processes updates from the data feeds 110 of the third party systems 108 and stores these updates locally as an aggregated record that includes information from multiple data feeds 110 of all of the third party systems 108 from which the outstanding transaction records store 114 receives information. In particular, the outstanding transaction record store 114 maintains a local version of the data feed 110 based on data entries received in updates from the data feed 110. These data entries may indicate new outstanding transactions that have been created, modified transactions that are open to the existing, or outstanding transactions that have been executed. Such an open transaction is a transaction that may be performed at the request of a user or other entity. Upon receiving the update from the data feed 110, the unspent record store 114 updates a list of unspent transactions stored in the locally stored version of the data feed 110 at the unspent record store 114. The locally stored version of the data feed 110 may be a summary of all data received from all data feeds 110, rather than data from only a single data feed 110. In one embodiment, the aggregated record stores all information from all data feeds 110 for a single target. The target is an indicator related to all data in the consolidated record and may be indicated in the updates received from the data feed 110. For example, the target may be an identifier of a cryptocurrency.

Each entry in the aggregated record indicating an outstanding transaction also includes a value amount, a reported unit count, a timestamp, and a transaction flow direction. The value amount indicates a value amount of the target of the outstanding transaction data entry. The reported unit count indicates a target unit count for the value amount. The timestamp indicates the time at which the open transaction was received by the third party system 108, which provided the data feed 110 from which the information for the open transaction was received. The transaction flow direction indicates the flow direction of the transaction, whether incoming or outgoing. This may correspond to buy or sell, respectively. Thus, one entry in the aggregated record for target "B" may indicate a value amount of "1000", a reported unit count of "5", and a transaction flow of inflows. This may correspond to a goal B of 5 units being available for execution of an outstanding transaction in an amount of value of 1000. In this case, the user may request that the outstanding transaction be performed. Upon execution, the user may transfer the 5 units of the item indicated by the target to the user who assigned the particular outstanding transaction to one of the third-party systems 108. In exchange, the user receives the value amount 5000 for the transaction. If the transaction flow is outbound, then performing an outstanding transaction will result in the user receiving a target "B" of 5 units, each of which has a value amount of 1000. The user must transfer the value amount 5000 to an external user who submits an outstanding transaction.

The outstanding transaction entries in outstanding transaction record store 114 may also be sorted based on one or more parameters. In one embodiment, the outstanding transactions are ordered according to the amount of value indicated in the outstanding transactions. For outstanding transactions that flow out of the transaction stream, the outstanding transaction with the lowest amount may be ranked first. For outstanding transactions with an incoming transaction flow, the outstanding transaction with the highest dollar value may be ranked first. If the value amount of the two outstanding transactions is the same, the transactions can be further sorted according to the time stamp, and the outstanding transaction with the longest time stamp is the highest in sorting.

In some cases, the outstanding transaction record store 114 may receive a data entry from the data feed 110 indicating a modification to an existing outstanding transaction. In this case, the outstanding transaction record store 114 may modify existing outstanding transactions according to instructions in the data feed entry. The modification may include a modification to any value in the outstanding transactions stored in outstanding transactions log storage 114, such as the amount of value, the unit count reported, and the like. The data entries received from the data feed 110 may also indicate that the transaction is executed (i.e., filled). In this case, the outstanding transaction record store 114 may remove outstanding transaction entries from the aggregated record.

Thus, the outstanding transactions record store 114 stores one or more aggregated records, each record storing outstanding transactions with respect to a particular target, and each aggregated record storing outstanding transactions received from multiple data feeds 110 from multiple third party systems 108. The aggregated records of the missed transaction record store 114 may be stored in a shared memory space accessible by other components of the transaction processing system 130.

The missed transaction record history store 116 stores a historical version of the missed transaction record store 114. The outstanding transaction record history store 116 may store a new copy of the outstanding transaction record store 114, i.e., a new historical outstanding transaction record 118, for each change made to the outstanding transaction record store 114. Alternatively, the outstanding transaction record history store 116 may store new historical outstanding transaction records 118 of the outstanding transaction record store 114 periodically (e.g., once per second) according to a schedule. In one embodiment, at least one historical outstanding transaction record 118 is created every hour. The historical open transaction records 118 may be stored as differential copies, i.e., each new copy stores only changes from the previous copy. The missed transaction record history store 116 may be stored in a disk-based database. Each historical open transaction record 118 may have a unique identifier, a timestamp, and other metadata, such as the transaction target of the copy, the number of changes to the copy compared to previous copies, and so forth.

Executed transaction record history store 120 stores executed transaction records 122, which are transactions that have been requested to be executed by a user, such as a user of client device 106. These executed transactions are outstanding transaction stores 114 listed in outstanding transaction records that have been requested to be executed. The transaction may be requested directly by the user, or via a routing system, such as the intelligent transaction router system 128, which routes the transaction request from the user to a plurality of outstanding transactions for execution. Once executed, the transaction indicated in the outstanding transaction occurs according to the parameters indicated in the outstanding transaction described above (e.g., amount of value, unit count reported, transaction flow direction, target). A transaction may involve two entities, one of which may be a user of a client device 106 connected to the transaction processing system 130.

Each executed transaction record 122 includes information about outstanding transactions executed by storing a copy of outstanding transactions or references to outstanding transactions, e.g., references to outstanding transactions stored in outstanding transaction record history store 116. Further, executed transaction record history store 120 stores a count of executed units for each executed transaction record 122. The executed unit count is the actual unit count executed in the transaction and may be different from the reported unit count indicated in the outstanding transaction. Each executed transaction record 122 also stores a requested unit count, which corresponds to the requested unit count when executing the open transaction. The requested unit count for an open transaction may be less than or equal to the reported unit count for the open transaction and indicate that the user or other entity wishes to transact from the unit count available in the open transaction (as indicated by the reported unit count).

In one embodiment, the request to perform the outstanding transactions may be transmitted to the third-party system 108 as a single aggregated request, rather than for individual outstanding transactions reported by the third-party system 108 via its data feed 110. In this case, a single aggregated request may have various parameters, including an aggregated request unit count (i.e., the total unit count requested to be performed in the aggregated request), and a value amount (and transaction flow direction). The third party system may then execute the request by executing the outstanding transactions that match the request until the executed unit counts of all executed transactions match the request unit counts in the request. Further, depending on whether the transaction is flowing in or out (e.g., buy or sell), the amount of value of the executed outstanding transaction should be greater or less than the amount of value specified in the request. In this case, executed transaction record 122 may store information about executed outstanding transactions and also indicate parameters of a single aggregated request resulting in an executed transaction.

While it is generally successful to execute the request for outstanding transactions listed in outstanding transactions log store 114, in some cases the results of the execution may be unexpected. For example, in some cases, the executed transaction may be a transaction that is not listed in outstanding transaction record store 114. A request for an outstanding transaction may be made to the third party system 108. However, the third-party system 108 may actually execute a hidden outstanding transaction that has a good value amount or an early timestamp or other high ranking than the outstanding transaction that was originally requested to be executed. However, since the outstanding transaction is hidden, it is not provided to the outstanding transaction record store 114 in the data feed 110 update. Thus, knowledge of the outstanding transaction may not be known until the outstanding transaction is actually executed. In this case, the executed transaction record 122 for the transaction will not have a reference to the corresponding outstanding transaction in outstanding transaction record history store 116. This type of hidden unknowns may also be referred to as hidden orders.

Further, in some cases, the outstanding transaction selected for execution may not actually be executed by the corresponding third-party system 108 providing the data feed information for the outstanding transaction, as it is not a true outstanding transaction for which one party is willing to provide a transaction. This type of open transaction may be reported in the data feed 110 and have data, such as value amounts, generated programmatically or manually. For example, data within such outstanding transactions may be based on other outstanding transactions listed in the data feed 110 and available at the third-party system 108. A programmatically generated outstanding transaction may have its data changed once other outstanding transactions at the third-party system 108 are executed, and thus it may be an outstanding transaction that may never actually be executed because its data may be set to never be the highest ranked, i.e., most desirable, outstanding transaction available to the third-party system 108. However, it does alter outstanding or perceived outstanding transactions at the third party system 108. This type of open transaction may also be referred to as a hook order.

Requesting execution of any open transactions may result in a different actual result than the initial request due to inaccuracies in some of the listed open transactions received from the data feed 110, or due to the data feed 110 not always showing a complete picture of all available open transactions at the third-party system 108. This is an unexpected result and is undesirable. These unexpected results may be more common in some third party systems 108, such as those systems that conduct transactions in encrypted currency (i.e., currency with ledgers recorded on blockchains). Each third party system 108 may have a different number of hidden or programmatically generated outstanding transactions, and thus, as shown below and described in further detail in fig. 2, the transaction analyzer may analyze the history of executed transaction records 122 and the historical outstanding transaction records 118 to determine the likelihood that data feed 110 information from the third party systems 108 has inaccurate information, and adjust the outstanding transaction record store 114 to generate an adjusted transaction record store 126 that may more accurately reflect the actual outstanding transactions available for execution at each third party system 108. The intelligent transaction router system 128 may use the adjusted transaction record store 126 to request execution of the adjusted outstanding transactions indicated in the adjusted transaction record store 126. This results in a higher likelihood that the executed transaction will match the outstanding transaction listed in the adjusted transaction records store 126, thereby reducing the chance of accidental or unwanted transactions being executed when the transaction is executed.

Accordingly, the transaction analyzer 124 generates an adjusted transaction record store 126 based on the executed transaction record history store 120 and the outstanding transaction record history store 116. To this end, the transaction analyzer 124 analyzes one or more (recent) outstanding transactions, such as by retrieving those transactions (i.e., executed transaction records 122) from the executed transaction records history store 120. The transaction analyzer 124 may include multiple process threads, each of which is tasked with analyzing executed transactions for a single transaction target. From these executed transactions, the transaction analyzer 124 determines how many of them were executed such that the unit count of execution matches the unit count of the request for the corresponding outstanding transaction. As described above, the requested unit count is the unit count requested for the outstanding transaction and is less than or equal to the reported unit count for the outstanding transaction, and the executed unit count is the actual unit count of transactions made when the outstanding transaction is requested to be executed at the requested unit count. An actual score is generated for each of these executed transactions indicating whether the executed unit count matches the executed unit count. In one embodiment, the actual score is 0 if the executed unit count matches the request unit count, greater than or equal to-1 and less than 0 if the executed unit count is less than the request unit count, and less than or equal to 1 and greater than 0 if the executed unit count is greater than the request unit count. These actual scores may be stored in the open transaction record history store 116 or in a separate database.

After analyzing one or more recently executed transactions and generating an actual score for each executed transaction, the transaction analyzer 124 samples the actual scores from the executed transactions of each individual third-party system 108 within the plurality of buckets. Each bucket groups transactions having a time stamp within a particular recency (e.g., previous hour, previous day, etc.). This data is used as a feature input to a predictive model (such as a regression model) to generate one or more predictive scores that predict a likely value for an actual score for future transactions performed at the same third-party system 108 (and in some cases, for the same target). In other words, the prediction score predicts the likelihood that an outstanding transaction, if executed, will cause the unit count of execution to exceed, equal to, or be less than the reported unit count (or requested unit count). Using these prediction scores, the transaction analyzer 124 modifies the outstanding transaction record score 114, e.g., using a product, to generate an adjusted transaction record store 126. In particular, the transaction analyzer 124 modifies/adjusts the report unit count of outstanding transactions indicated in the outstanding transaction records store 114 according to the generated prediction score. These adjusted unit counts for outstanding transactions may more accurately reflect what the maximum execution unit count may be if a request is made for the outstanding transaction. The adjusted unit count may be less than or greater than the reported unit count for the open transaction. However, by being closer to the actual executed unit count, the adjusted unit count may more accurately predict the outcome of any request to execute any outstanding transactions at the third party system, and help avoid problems with outstanding transactions and hidden outstanding transactions that are programmatically generated as described above.

As described above, the adjusted transaction record store 126 stores adjusted outstanding transactions having an adjusted unit count that the transaction analyzer 124 modifies according to the original reported unit count of the corresponding outstanding transaction. The adjusted transaction record store 126 may be stored in a shared memory with the transaction analyzer 124 to allow low latency access by the transaction analyzer 124. Each update of a new set of adjusted unit counts from the transaction analyzer 124 for a new open transaction received by the open transaction record store 114 may be assigned a unique identifier, which may be stored with the update and may also be referenced using a hash table or other index. These updates may be updated via a single process/thread to avoid problems that may be caused by race conditions due to multiple threads. Thus, any updates from the parser 124 may be placed in a single queue for serial processing. The format, ranking, and other features of the adjusted transaction record store 126 may be similar to the unspent transaction record store 114.

The intelligent transaction router system 128 routes any requests to execute outstanding transactions listed at the outstanding transaction record store 114 or the adjusted transaction record store 126 to the third party systems 108 so that outstanding transactions selected for execution are optimally selected and distributed among the various third party systems 108.

As described above, the transaction analyzer 124 modifies the outstanding transaction record store 114 to generate an adjusted transaction record store. A requesting entity, such as a user (via client device 106), a separate computing device, or executable program may be able to directly select the adjustment missed transactions listed in adjustment transaction record store 128 and request that these transactions be performed. In this case, the smart transaction router system 128 may communicate the request indicated by the requesting entity to the third-party system 108 corresponding to the selected adjusted outstanding transaction and cause the third-party system 108 to execute the selected transaction. The requesting entity may indicate a requested unit count that is different from the adjusted unit count for the selected adjusted outstanding transaction.

Alternatively, the requesting entity may instead send the aggregated request to the intelligent transaction router system 128. Similar to the aggregated requests made to the third party systems, the aggregated requests may include an aggregated unit count, a transaction flow and optionally a value amount, and a transaction goal. However, the aggregated requests to the smart transaction router system 128 may be directed to more than one third party system 108. Upon receiving the aggregated request, the intelligent transaction router system 128 accesses the adjusted transaction record store 126 and identifies an adjusted outstanding transaction entry corresponding to the transaction target and the indicated transaction flow direction. These adjusted outstanding transaction entries, which are similar to the outstanding transaction entries in outstanding transaction record store 114, are ordered according to their indicated value amounts and their time stamps, as described above with reference to outstanding transaction record store 114. The intelligent transaction router system 128 selects those adjusted outstanding transaction entries that are highest in rank such that the sum of the adjusted unit counts indicated in the selected adjusted outstanding transaction entries meets or exceeds the requested aggregate unit count of the aggregate request. The intelligent transaction router system 128 may also determine that the value amounts indicated in these adjusted outstanding transaction entries do not exceed the threshold set by the value amount (i.e., greater than or equal to the value amount of the incoming transaction flow direction, and less than or equal to the outgoing transaction flow direction). The outstanding transactions selected by the intelligent transaction router system 128 may also be referred to as split transactions because they are split from the aggregated request.

The smart transaction router system 128 transmits a request corresponding to the selected adjusted unspent transaction entry (i.e., split transaction) to the third party system 108. These are third party systems 108 that provide information about outstanding transactions in a data feed 110 that are adjusted to generate selected adjusted outstanding transaction entries. The intelligent transaction router system 128 submits a request to execute the outstanding transaction corresponding to the selected adjusted outstanding transaction entry. The request associated with each outstanding transaction includes a request unit count that matches the adjusted unit count generated by the transaction analyzer 124 for that outstanding transaction. If the summarized unit count is less than the sum of the adjusted unit counts of the selected adjusted outstanding transaction entries, then the intelligent transaction router system 128 may decrement the request unit count of the lowest ranked of the selected adjusted outstanding transaction entries such that the request unit count of the lowest ranked entry is equal to the remaining unit counts of all other selected adjusted outstanding transaction entries subtracted from the summarized unit count. Such an approach allows the smart transaction router system 128 to select those outstanding transactions having the highest ranking, and therefore the best value amount (as noted, different depending on the flow of transactions). Thus, when multiple third party systems 108 provide information about outstanding transactions, the intelligent transaction router system 128 selects the best distribution of requests to be made to achieve the best selection based on the amount of value of the user.

After submitting a request to execute the open transaction, the smart transaction router system 128 receives a response, such as an execution report or log, from the third party system 108 with the results of the request. For each outstanding transaction requested to be executed, the response from the third party system 108 indicates the executed units count of the executed transaction, i.e., how many transaction target units were actually processed in the transaction. For each executed transaction, the smart transaction router system 128 may also receive an identifier of the transaction, an amount of value, a transaction flow, and other information. The intelligent transaction router system 128 stores these results and other metadata for each executed transaction in the executed transaction record history store 120 as the executed transaction record 122. As described above, these may be used by the transaction analyzer 124 to generate updates to the adjusted transaction record store 126. The transaction analyzer 124 may generate an update to the adjusted transaction record store 126 each time the smart transaction router system 128 stores a newly executed transaction in the executed transaction record history store 120.

In one embodiment, the smart transaction router system 128 may further limit the third party systems 108 selected for performing transactions based on the geographic distance to the smart transaction router system 128, as the additional delay to third party systems 108 that are geographically further away may result in a race condition with other entities that wish to perform outstanding transactions available at the third party systems 108.

The intelligent transaction router system 128 may be a single threaded process, which allows it to avoid race conditions when requesting execution of an outstanding transaction, in order to ensure that different requests are processed in order.

The system 100 may also optionally include one or more blockchains (not shown) that may be accessed by elements on the network 102 to record executed transactions on the blockchains. For example, the data feed 110 may include data regarding exchange rates between various cryptocurrencies with transaction books recorded on various blockchains. A client device 106 that requests to perform an outstanding transaction by accessing the transaction processing system 130 may be able to see information about all of the data feeds 110, and thus the exchange rates of these cryptocurrencies. The user can then use the client device 106 to request performance of these outstanding transactions to redeem these various cryptocurrencies. Upon completion of the transaction, the third party system 108, the transaction processing system 130, or some other entity may submit the transaction to the corresponding blockchain to effect completion of the transaction by logging them to the respective blockchain ledger. The blockchain may be a common blockchain. The common blockchain network may include a plurality of nodes that cooperate to verify transactions and generate new blocks (which may record transaction information about cryptocurrency). In some implementations of a blockchain, the generation of new blocks may also be referred to as a mining process. A blockchain may support an intelligent contract, which is a set of code instructions that are executable when one or more conditions are satisfied. When triggered, the set of code instructions may be executed by a computer, such as a virtual machine of a blockchain. In this context, a computer may be a single unit of operation in the conventional sense (e.g., a single personal computer), or may be a set of distributed computing devices (e.g., virtual machines or distributed computing systems) that cooperate in executing code instructions. Examples of such common blockchain platforms include bitcoin, etherhouse, EOS, NEO, CARDANO, STELLER, and the like. Additional details regarding the properties of the blockchain are described below with reference to fig. 6A-6B.

Example transaction Analyzer

Fig. 2 is a block diagram that illustrates components of the transaction analyzer 124 of fig. 1, according to an embodiment. In the embodiment shown in FIG. 2, transaction analyzer 124 includes (optionally) a score database 210, an actual score generator 215, a predictive score regression model 220, a predictive score generator 225, a regression model generator 230, an adjusted records generator 240, and a User Interface (UI) generator 245. The functionality of the transaction analyzer 124 may be distributed among the different components in a manner different than that described. Additionally, in various embodiments, the transaction analyzer 124 may include different, fewer, and/or additional components. Additional details, including example implementations of the process of generating the adjusted record transaction store, are described further below with reference to fig. 3A-3B.

In one embodiment, the score database 210 stores scores generated by the actual score generator 215 during the adjusted unspent process of generating the adjusted transaction record store 126. The score database 210 also stores the prediction scores generated by the prediction score generator 225 for modifying the report unit counts of outstanding transactions in the outstanding transaction record store 114. The score database 210 may also store other metadata and information needed to generate the adjusted outstanding transactions, such as timestamps, transaction target information, levels (i.e., rankings) of outstanding transactions by third-party systems, and so forth. Each entry in the score database 210 may be indexed by a unique identifier to allow quick retrieval. Further, entries may be indexed according to the recency of their timestamps, indexing the entries into various recency ranges, e.g., past hour, past day, past week, and past month, so that actual scores and other data may be easily sampled from a particular recency range. For example, the actual scores calculated for transactions performed within the past hour may be assigned a particular index value, while those within the past day may be assigned another index value. The actual score may be sampled from one of the recency ranges simply by referencing a particular index value for that recency range. In one embodiment, the score database 210 may be stored in the unspent transaction history store 116, where the calculated actual scores are stored with reference to the unspent transactions from which they were calculated.

The actual score generator 215 generates actual scores from executed transactions accessed from the executed transaction record history store 120. After the intelligent transaction router systems 128 transmit a set of outstanding transactions to be performed to their respective third party systems 108, the third party systems then respond with reports or other responses indicating the unit count performed after performing the outstanding transactions. As described above, in some cases, the executed unit count may be different than the requested unit count because the outstanding transactions reported by the third-party system 108 do not match the actual available outstanding transactions of the third-party system 108. The actual score generator 215 generates an actual score for each of these executed transactions to quantify the difference between the executed unit counts and the requested unit counts for the transactions so that future transactions with the third party system 108 may more accurately predict actual executed unit counts.

In one embodiment, for each executed transaction, the actual score generator 215 calculates an actual score as:

[ actual fraction ] ═ min (1, [ execution count ]/min ([ report count ], [ request count ] -1) (1)

Herein, [ execution count ] is an actual execution unit count (unit of target) of executed transactions. The report count is the report unit count in the corresponding outstanding transaction data received from the data feed 110 and stored in the outstanding transaction records store 114. Request count is the request unit count requested by the intelligent transaction router system 128 when requesting execution of an outstanding transaction. The function min ([ ], [ ]) outputs the minimum of the two values input into the function. The result of equation (1) is to generate the following score, then: 1) the score is greater than or equal to-1 and less than 0 if the executed unit count is less than the requested unit count, 2) the score is equal to 0 if the executed unit count is equal to the requested unit count, and 3) the score is greater than 0 and less than or equal to 1 if the executed unit count exceeds the requested unit count.

As described above, while in some cases the smart transaction router system 128 may select individual outstanding transactions to execute at the third party system 108, in some cases an aggregation request may be made to the third party system. In this case, the [ request count ] is not a summary unit count, but rather a request count calculated based on dividing the summary unit count among the highest ranked outstanding transactions listed in the adjusted transaction records store 126 (or outstanding transaction records store 114) of the third-party system. To divide the aggregate unit count, the actual score generator 215 sums the adjusted report unit counts for the outstanding transactions, starting with the selection of the highest ranked outstanding transaction and then sequentially selecting the lower ranked outstanding transactions until the sum of the adjusted report unit counts for the selected outstanding transactions matches or exceeds the aggregate unit count. The actual score generator 215 sets the request count for each of these outstanding transactions to the adjusted report units count for the outstanding transactions. For the last lowest ranked outstanding transaction of the selected outstanding transactions, the actual score generator 215 sets the request count to the value of the aggregate unit count minus the adjusted reporting unit count for the selected outstanding transaction, excluding the last outstanding transaction. It is expected that the third party system 108 will execute the aggregated request by executing the outstanding transactions corresponding to those in the selected list.

In some cases, the third-party system 108 may not actually perform the outstanding transaction submitted by the smart transaction router system 128 because the outstanding transaction does not actually exist (e.g., it was programmatically created or requested to be performed by others). In this case, the executed units count for the outstanding transaction is set to zero.

In some other cases, the third-party system 108 may execute the request for the open transaction by executing a hidden open transaction that is not displayed to the transaction processing system 130. If the hidden outstanding transaction has the same value number as one of the outstanding transactions requesting execution, then it is merged with the outstanding transaction when calculating the execution unit count. Although the reported unit count and the requested unit count do not change, the executed unit count adds the executed unit count including the non-hidden outstanding transactions to the executed unit count of the hidden outstanding transactions. If the value amount of the hidden outstanding transaction is different from the value amount of any outstanding transactions indicated in adjusted transaction record store 126, then actual score generator 215 may merge the executed units count of the hidden outstanding transactions that were executed with the executed units count of the outstanding transactions having a value amount that immediately follows the value amount ranking of the hidden outstanding transactions that were executed. Thus, for example, if the value amount of the hidden outstanding transaction performed is 3400.5, and the executed units count for the hidden outstanding transaction is 1.2, it will be merged with the executed units count for the next lower ranked value amount outstanding transaction, which in this example may be 3401 (for the outgoing transaction flow direction).

After calculating the actual score for the executed transaction, the actual score generator 215 stores the calculated actual score in the score database 210. Additional information such as transaction goals, value amounts, transaction flow directions, identifiers, timestamps, and other details may be stored by the actual score generator 215 along with the calculated actual score. The actual score generator 215 also stores a level of executed transactions (i.e., "rung") that indicates the ranking of executed transactions of the third-party system by value amount (e.g., level 0 would be the highest ranking, level 1 the next highest ranking, and so on). Executed or outstanding transactions having the same amount of value but different timestamps are assigned the same level. The actual score generator 215 may also calculate an index for the calculated actual score based on its recency or timestamp so that future retrieval based on the timestamp may occur quickly. While the actual score generator 215 may generate actual scores for executed unjoins as they are executed, in other embodiments, the actual score generator 215 may generate actual scores offline, periodically, in batches, or according to another time horizon for executed unjoins. In this case, the actual score generator 215 may retrieve the report unit counts and other relevant data for earlier outstanding transactions from the outstanding transactions record history store 116 to generate actual scores for those transactions.

The prediction score regression model 220 is a model for generating one or more prediction scores based on actual scores calculated by the actual score generator 215. Although described herein as a regression model, the predictive score regression model 220 may be any type of predictive model or algorithm. The prediction score generated by the prediction score regression model 220 is based on an analysis of the actual scores previously collected, the actual score of the outstanding transaction would be a prediction of how much if the outstanding transaction was executed. Thus, the input to the predictive score regression model 220 includes the actual scores previously collected, and the output is a predictive score that indicates a possible value for the actual score of the open transaction. In one embodiment, instead of generating a prediction score for each unspent transaction, the prediction score regression model 220 generates a prediction score for each unspent transaction level for each third-party system's unspent transactions, as indicated by the data feeds 110 of that third-party system 108.

In one embodiment, the inputs to the predictive score regression model 220 include actual scores sampled from a certain level of executed transactions, which are from a single third-party system 108. The actual scores of these samples are sampled from buckets having actual scores generated from outstanding transactions of various recency ranges, such as the past hour, the past day, the past week, and the past month.

Prediction score generator 225 samples the actual scores from different actual score buckets of different recency ranges and generates a prediction score for each level for each third-party system using prediction score regression model 220. One or more actual scores may be sampled from each of these buckets, and the actual scores of the samples from each bucket may be combined using some function of prediction score generator 225. For example, one actual score may be sampled from each of the buckets per hour, and the actual scores sampled for each bucket may be combined using an averaging function. After generating a single combined actual score for each bucket, prediction score generator 225 feeds these inputs into prediction score regression model 220 to generate a prediction score for the corresponding level of unknowns of third-party system 108. Predictive score generator 225 repeats this operation for different levels of each third-party system and for different third-party systems for each trading objective. Different forecasts may also be generated for each type of transaction flow. Prediction score generator 225 may also periodically update the prediction score over time (e.g., once time equals the time range of the bucket with the smallest time range). After generating the prediction scores, prediction score generator 225 sends these prediction scores to adjusted records generator 240 to generate adjusted transaction records store 126. Initially, prediction score generator 225 may generate a prediction score of zero if no actual score or insufficient actual score is available for input into the model.

The regression model generator 230 generates a predictive fractional regression model. In one embodiment, the predictive score regression model 220 is generated by regressing actual scores to historical actual scores. For example, the regression equation may be:

S_P＝c+b₁[Prev_hour S_A]+b₂[Prev_day S_A]+b3[Prev_week S_A]+b₄[Prev_month S_A] (2)

herein, S_PIs a prediction score, and S_AIs the actual fraction sampled from the specified bucket. For example, Prev _ hour indicates the previous hourA bucket of actual scores and Prev _ day indicates a bucket of actual scores for the previous day. As described above, the actual fraction of samples in each bucket may be an average of a plurality of sample actual fractions sampled at a particular interval. The regression model generator 230 uses the actual scores of executed transactions and then selects a recency bucket based on the timestamps of the executed transactions. The regression model generator 230 samples the actual scores using the corresponding timestamps within the ranges specified in the buckets. Using the plurality of samples, the regression model generator 230 then trains the regression model to generate the regression model coefficients b₁、b₂、b₃、b₄And the like.

In one embodiment, additional arguments may be used to train the model, such as the average transaction amount and average fluctuation rate of the transaction target over all executed transactions. These may also be computed for each bucket (e.g., by prediction score generator 225) and used as inputs in the model. These additional arguments may also be stored in the score database 210.

In another embodiment, other modeling techniques may be used with these input and output variables, such as principal component analysis, neural networks, and the like.

The adjusted record generator 240 modifies the outstanding transactions record store 114 using the predicted scores for each level of outstanding transactions for each third party system 108. In one embodiment, the adjusted record generator 240 employs the predicted score, trading objective, trading flow direction, and third party system generated for a particular level and modifies the corresponding reported unit count of outstanding trades having the same level, trading objective, trading flow direction, and from the same third party system by the predicted score to generate an adjusted unit count. In one embodiment, the modification is: [ report unit count ] (1+ [ prediction score ]). Thus, if the prediction score is 0 and the reported unit count is 5, the adjusted unit count is 5. When the prediction score is less than zero, the adjusted unit count will be lower than the reported unit count. Alternatively, if the prediction score is greater than zero, the adjusted unit count is greater than the reported unit count. Accordingly, the adjusted unit count is scaled based on the likelihood that the executed unit count will be greater than, less than, or equal to the requested unit count. An example of this process is described below with reference to fig. 3A through 3B.

The UI generator 245 generates a graphical user interface, such as the interface 104, that presents information to a user, such as a user of the client device 106, regarding data received from the third-party system 108 (e.g., the outstanding transaction record store 114, and the modified adjusted transaction record store 126 generated by the transaction analyzer 124). The UI generator 245 may present the highest ranked values from the adjusted transaction record store 126 (or outstanding transaction record store 114) for each transaction goal and transaction flow direction, aggregating each transaction goal and flow direction outstanding transactions from all third party systems 108 into a single list. The UI generator 245 may update the user interface in real-time as new data is updated from the third-party system 108 and a new adjusted unit count is generated. In one embodiment, the UI generator 245 executes on the client device 106 rather than on the transaction processing system 130.

Example Process for local version updates from remote data feeds

Fig. 3A is a block diagram and flow diagram illustrating an example of generating an adjusted transaction record, according to an embodiment. The operations in the illustrated example may be performed by the transaction processing system 130. However, in other embodiments, these operations may be performed by other components, such as client device 106.

At (1), the transaction processing system 130 receives 310 feed data from the data feed 110 of the third-party system 108. In the illustrated example, three third-party systems 312A-C are shown. The data feed from each third-party system 312 includes information about the transaction objectives, including reported unit counts 314 (particularly unit counts 314A-C) and value amounts 316 (particularly value amounts 316A-C). As described above, these indicate the reported unit count and the accompanying value amount for the outstanding transaction. Thus, each row in the illustrated feed is an outstanding transaction available for execution.

At (2), a request to execute an aggregated transaction with an aggregated unit count of 10 is issued to transaction processing system 130. The transaction processing system 130 executes 320 the requested transaction at the plurality of third party systems 312, for example, via the smart transaction router system 128. As described above, the intelligent transaction router system 128 performs the aggregated request by dividing the request among the various third party systems 312, which are ordered by value amounts. This results in various requests to perform transactions being transmitted to the third party systems 312A-C. Here, these may include, 1) for the third-party system 312A: a value of 1 unit for 3400, 0.5 unit for 3401, and 2 units for 3402; 2) for the third-party system 312B: a value of 3401 is 0.5 units, a value of 3402 is 1 unit, a value of 3403 is 1.5 units, and a value of 3404 is 1 unit; 3) for the third-party system 312C: the value 3400 is 0.5 units, the value 3402 is 1 unit, and the value 3404 is 1.5 units.

After submitting a request to execute the outstanding transaction as indicated, the transaction processing system 130 receives 330 one or more responses from the third-party systems 312A-C, such as indicating the results of the execution in an execution report. The execution report may be presented in the third party system response 332A-C. Herein, because some of the outstanding transactions listed in the third-party systems 312A-C are hidden or programmatically generated, some of the requested outstanding transactions are not executed, or are not executed at the same requested unit count as the transaction. For example, the third-party system 312B only reports the execution of three outstanding transactions, while four requests are issued to the third-party system 312B to execute four outstanding transactions. This may be due to one of the requests to execute outstanding transactions being a request for a programmatically generated outstanding transaction that has its value changed after one of the other outstanding transactions is executed. The change in value causes it to no longer match the unjoined transaction of the original request and therefore not be performed.

The transaction processing system 130 obtains the execution response from the third party system and calculates 340 the actual scores 342A-C based on the difference between the executed unit count, the reported unit count, and the requested unit count at (4). In the illustrated example, the transaction processing system 130 uses equation (1) above. This results in various actual scores being generated. Note that some requests for outstanding transactions are not executed. In these cases, to calculate the actual scores for these transactions, the executed units count is zero. The calculations of these unexecuted outstanding transactions are indicated in italics. The actual score 342B of the third-party system 312A has one of these, while the actual score 342C of the third-party system 312C has two of these.

Fig. 3B is a block diagram and flowchart that continues with the example shown in fig. 3A, according to an embodiment.

Referring now to fig. 3B, at (5), the transaction processing system 130 may store 350 the actual scores generated, for example, in the score database 210 or the outstanding transaction record history store 116. As shown, for each third party system, these may include an entry indicating the actual score 356 generated for the target 351 at a particular timestamp 352 for the amount of value at a particular level 353. Also stored in the entry are the reported unit count 354 of the original outstanding transaction, and any previously predicted scores 355 (which may be set to zero if no score has been predicted). The generation of the prediction score is described in further detail below.

After generating the plurality of actual scores, at (6), the transaction processing system 130 calculates 360 a historical score from the generated actual scores. These may be divided into scores collected over various time periods (time buckets) 361, which indicate recent time periods, such as the previous hour, day, week, or month. The actual scores 364 for each level 362 and trading objective of the third party system may be sampled and averaged from the time period indicated for each bucket and stored as the actual score 364 in the illustrated table along with the unit count 363 of the average report, which is the average of the unit counts (which may also be sampled) reported over the corresponding time period.

As shown, the historical scores herein are for a single level (e.g., level 0), a single transaction target, and a single third-party system. However, in practice, multiple history scores may be stored for different levels, targets, and third party systems. A new set of historical scores may be generated each time a set of actual scores is generated, or the historical scores may be generated periodically. The historical scores may be stored in the score database 210 or the open transaction record history store 116.

At (7), the historical scores are used to model 370 the prediction scores. This may occur according to the process described above with reference to regression model generator 230. Herein, for each level 371 of outstanding transactions for the third party system, a prediction score 372 is generated. As described above, the score indicates the likelihood of a deviation of the unit count performed from the reported or requested unit count. For example, in the illustrated example, the prediction score for level 0 is 0. This indicates that the executed unit count for the outstanding transactions at level 0 for the target and third party systems may not differ from the reported unit count. However, at level 1, the prediction score is 1, indicating that the executed unit count may exceed the reported unit count.

After modeling the prediction score, at (8), the transaction processing system 130 may use the prediction score to modify 380 the reported unit count of outstanding transactions reported by the third-party system. In the example shown, the report unit count of the third-party system 312A is modified by the prediction score (e.g., by multiplying the report unit count by a 1+ prediction score) to generate an adjusted unit count 381 for each level (where each level indicates a different ranked value amount 382), as indicated in the adjusted record 381. This is then used to request the execution of outstanding transactions from various third party systems, for example, through the smart transaction router system 128.

Example interaction diagrams

FIG. 4 is an interaction diagram that describes an example process of the component of FIG. 1 for adjusting a transaction distribution based on a predicted outstanding transaction execution rate, according to an embodiment. Although certain operations are associated with certain elements shown, in other embodiments, different elements may perform different operations.

Initially, the transaction analyzer 124 may update 410 the adjusted transaction record store 126. As described above, this allows the reported unit count for the outstanding transactions to be modified to an adjusted unit count, which may more accurately represent the actual unit count for the outstanding transactions in the third party system 108.

The smart transaction router system 128 also receives 412 a transaction request from the third party system 108 to perform one or more outstanding transactions. This may be a request received from an authorized client device. To perform these transactions, the smart transaction router system 128 may retrieve 414 the adjusted transaction record from the adjusted transaction record store 126. The intelligent transaction router system 128 may then execute 416 the requested transaction based on the adjusted transaction record in the manner detailed above. After executing the transaction, the smart transaction router system 128 updates 418 the executed transaction record history store 120 with the results of the executed transaction.

At the same time, the third party system 108 sends 420 a data feed update to the outstanding transaction record store 114. These are updates to outstanding transactions and other data from third party systems 108 that are stored locally at outstanding transactions log store 114, as described above. The transaction analyzer 124 retrieves 422 the unspent transaction from the unspent transaction record store 114 and further retrieves 424 a history including executed unspent transactions from the executed transaction record history store 120 and actual scores and other data calculated for previously received unspent transactions, which may be stored in the unspent transaction record history store 116, or in the score database 210, or both. The transaction analyzer 124 calculates new or updated prediction scores based on a model of prediction scores (e.g., the prediction score regression model 220) and uses these prediction scores to modify the unit counts of reports from the outstanding transaction records store 114 to generate the adjusted transaction records store 126, as detailed above.

Meanwhile, the smart transaction router system 128 receives 430 a second request to execute transactions and executes 432 these transactions based on the updated adjusted transaction records.

Example flow

FIG. 5 is a flow diagram illustrating an example process for adjusting a transaction distribution based on a predicted outstanding transaction execution rate, according to an embodiment. In one embodiment, the illustrated operations are performed by the transaction processing system 130.

The transaction processing system 130 receives 510 a transaction request to execute a transaction that includes a request count. This may be a request from a client device and may be an aggregated request. The request causes the transaction processing system 130 to begin executing one or more open transactions with the various third party systems as described above.

The transaction processing system 130 accesses 520 an adjusted transaction list that includes a combined list of a plurality of outstanding transactions and an adjusted count for each of a plurality of available transactions received from the third party system. The adjusted transaction list may be an adjusted transaction record store 126 that the transaction processing system 130 accesses to determine an adjusted unit count before submitting the corresponding open transaction for execution. As previously described, these adjusted unit counts are determined using a predictive model to generate a prediction score based on the difference between the executed unit counts and the reported unit counts for the open transaction and the executed transaction.

The transaction processing system 130 divides 530 the transaction request into one or more split transaction requests based on the adjusted transaction list. The one or more split transactions are transactions routed by the transaction processing system 130 for the respective third party systems. Each request unit count for each split transaction will have a request unit count for the outstanding transaction at the third party system that is less than or equal to the adjusted unit count for the outstanding transaction.

The transaction processing system 130 sends 540 each of the one or more split transaction requests to a corresponding third party system for execution. After execution, each third party system responds with the execution results.

The transaction processing system 130 receives 550 an execution report from the third party system indicating an executed count of executions of split transactions.

Example Block chain architecture

Fig. 6A is a block diagram illustrating a transaction chain broadcasting and recording over a blockchain according to an embodiment. As described above, the outstanding transactions performed may involve different cryptocurrencies. A cryptocurrency is a currency with ledgers stored in a chain of decentralized blocks. Blockchains record transactions that occur using cryptocurrency in one or more blockchain units stored in the blockchain, but do not require a central authority to verify that the transaction is legitimate. Rather, blockchains are generated via cooperation of multiple nodes or computing systems.

A distributed blockchain network may include a plurality of nodes. Each node is a user or server participating in the blockchain network. In a fully common blockchain, any participant can become a node of the blockchain. These nodes may collectively function as a distributed computing system, functioning as a virtual machine for the blockchain. In some embodiments, a virtual machine or distributed computing system may be referred to simply as a computer. Any user of the public blockchain can broadcast transactions for blockchain nodes to record. Each user's digital wallet is associated with an encryption private key that is used to sign transactions and to prove ownership of the blockchain unit.

Ownership of blockchain units may be tracked through a chain of transactions. In fig. 6A, the transaction chain may include a first transaction 610, a second transaction 620, and a third transaction 630, among others. Each transaction in the chain may have a very similar structure. Although each transaction is linked to the previous transaction in fig. 6A, the transactions need not be recorded on consecutive blocks on the blockchain. For example, the block in which transaction 610 is recorded and the block in which transaction 620 is recorded may be separated by hundreds or even thousands of blocks. The trace back of previous blocks is tracked by the hash value of the previous block recorded by the current block.

Referring to one of the transactions in FIG. 6A, for purposes of illustration, transaction 620 may be referred to as a current transaction. Transaction 610 may be a prior transaction and transaction 630 may be referred to as a subsequent transaction. Each transaction includes transaction data 622, recipient address 624, hash of previous transaction 626, and digital signature 628 of the owner of the current transaction. Transaction data 622 records the substance of current transaction 620. For example, the transaction data 622 may specify the transfer of a certain number of blockchain units (e.g., electronic coins, blockchain vouchers, BCDRs, etc.). In some embodiments, the transaction data 622 may include code instructions for the smart contract.

The recipient address 624 is a public key version of the private key corresponding to the recipient's digital wallet. In one embodiment, recipient address 624 is the public key itself. In another embodiment, recipient address 624 encodes the version's public key by one or more functions, such as some deterministic function. For example, generating the recipient address from the public key 624 may include hashing the public key, adding a check, adding one or more prefixes or suffixes, and encoding the resulting bits. Recipient address 624 may be a unique identifier of the recipient's digital wallet on the blockchain.

The hash of previous transaction 626 is a hash of the entire transaction data of previous transaction 610. Likewise, the hash of the previous transaction 636 is a hash of the entire transaction data of transaction 620. The previous transaction 610 may be performed using a hashing algorithm such as a Secure Hash Algorithm (SHA) or a message digest algorithm (MD). In some embodiments, the owner corresponding to the current transaction 620 may also generate a hash using the owner's public key. The hash of previous transaction 626 provides a traceback of previous transaction 610 and also maintains the data integrity of previous transaction 610.

In generating the current transaction 620, the blockchain unit current owner's digital wallet encrypts the combination of the transaction data 622, the recipient address 624, and the hash of the previous transaction 626 using its private key to generate the owner's digital signature 628. To generate current transaction 620, the current owner specifies the recipient by including recipient address 624 in digital signature 628 of current transaction 620. The subsequent owner of the blockchain unit is determined by the receiver address 624. In other words, the subsequent owner who generated digital signature 638 in subsequent block 630 is fixed by recipient address 624 specified by current transaction 620. To verify the validity of the current transaction 620, any node in the blockchain network may track back to the previous transaction 610 (by tracking a hash of the previous transaction 626) and locate the recipient address 614. The recipient address 614 corresponds to the public key of the digital signature 628. Thus, nodes in the blockchain network may use the public key to verify the digital signature 628.

The transfer of ownership of the blockchain unit may be continued by the owner of the blockchain unit. To transfer ownership, the owner may broadcast a transaction that includes the owner's digital signature and a hash of previous transactions. The correct hash values for valid transactions and previous transactions with verifiable digital signatures will be recorded in the new block of the blockchain through the mine mining process.

Fig. 6B is a block diagram illustrating the connection of multiple tiles in a tile chain according to an embodiment. Each block of the block chain may have a similar structure, except for the first block, which may be referred to as a founder block. Blocks 650, 660, and 660 may each include a hash of previous block chain 652, a random number 654, and a plurality of transactions (e.g., first transaction 656, second transaction 658, etc.). Each transaction may have the structure shown in fig. 6A.

A new block may be generated by the excavation process. For a common blockchain, any node in the blockchain system may participate in the mining process. The generation of the hash of the previous tile may be performed by a trial and error process. The entire data of the previous tile (or a version of the previous tile, such as a reduced version) may be hashed using a random number as part of the input. A blockchain may require some format in the hash of the previous block in order for the node to identify the new block as valid. For example, in one embodiment, the hash of the previous chunk needs to start with a certain number of zeros in the hash. Other hash criteria for previous blocks may also be used, depending on the implementation of the blockchain.

As an example, in generating the hash of the previous block 662, the nodes participating in the mining process may randomly combine the version of the previous block 650 with a random number (i.e., a random value) to generate the hash. Due to the random number, the generated hash is somewhat a random number value. The node compares the generated hash to the criteria of the blockchain system to check if the criteria are met (e.g., if the generated hash begins with a certain number of zeros in the hash). If the generated hash does not meet the criteria, the node may attempt to generate another hash in combination with a different random number. This process is repeated by different nodes in the blockchain network until one of the nodes finds a hash that meets the criteria. The random number used to generate a satisfactory hash is the random number 664. The node that first generates a satisfactory hash 662 may also select which transactions to broadcast to the blockchain network to include in block 660. The node may check the transaction validity (e.g., whether the transaction can be traced back to a previously recorded transaction and whether the transaction generator's digital signature is valid). The selection may also depend on the number of broadcast transactions to be recorded and the fees that may be specified in the transactions. For example, in some embodiments, each transaction may be associated with a fee (e.g., a mine fee (gas)) for recording the transaction. After selecting the transaction and fixing the data of block 660, the nodes in the blockchain network repeat the trial-and-error process to generate a hash of the previous block 672 by trying different random numbers.

In some cases, different nodes may select different transactions for inclusion in subsequent tiles, and may compete with each other to find the correct random number for the set of transactions that have the generated hash that meets the criteria. Thus, there may be situations where multiple satisfactory hashes are generated for blocks containing different transactions. This creates a bifurcation in the blockchain. Future blocks may be hashed based on data in any of the bifurcated blocks. However, in practice, to avoid adding chunks to multiple branches, the node may agree by selecting the branch of the chunk with the earlier timestamp, or use some other criterion to select the further chunk from which to hash the principal branch. In other embodiments, instead of computing random numbers, which may be computationally expensive, the nodes may use other consensus methods, such as the equity proof method, to determine which fork to follow.

The new block may continue to be generated by the excavation process. When a broadcast transaction is recorded in a tile, the transaction of a blockchain unit (e.g., electronic coin, blockchain voucher, BCDR, etc.) is completed. In some embodiments, a transaction is considered settled when the transaction is multiple validated. When multiple subsequent blocks are generated and linked to the block recording the transaction, the transaction is multiple verified.

In some embodiments, some transactions 656, 658, 666, 668, 676, 778, etc. may include one or more smart contracts. The code instructions of the recorded smart contracts may be recorded in blocks and are generally immutable. When the condition is satisfied, a code instruction of the intelligent contract is triggered. The code instructions may cause a computer (e.g., a virtual machine of a blockchain) to perform some action, such as generating a blockchain unit and broadcasting a record generated transaction to a blockchain network for recording.

Computing machine architecture

FIG. 7 is a block diagram illustrating components of an example computing machine capable of reading instructions from a computer-readable medium and executing them in a processor (or controller). The computers described herein may include a single computing machine as shown in fig. 8, a virtual machine, a distributed computing system including multiple computing machine nodes as shown in fig. 7, or any other suitable arrangement of computing devices. The computers described herein may be used by any of the elements described in previous figures to perform the described functions.

By way of example, fig. 7 shows a diagrammatic representation of a computing machine in the example form of a computer system 700 within which instructions 724 (e.g., software, program code, or machine code) may be executed, which instructions may be stored in a computer-readable medium for use by the machine to perform any one or more of the processes discussed herein. In some embodiments, the computing machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server machine or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.

The architecture of the computing machine depicted in fig. 7 may correspond to any of the software, hardware, or combination of components shown in the above-described figures. While fig. 7 shows various hardware and software elements, each of the components described in the above figures may include additional or fewer elements.

For example, the computing machine may be a Personal Computer (PC), a tablet computer, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a smartphone, a web appliance, a network router, an internet of things (IoT) device, a switch or bridge, or any machine capable of executing instructions 724 that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute the instructions 724 to perform any one or more of the methodologies discussed herein.

The example computer system 700 includes one or more processors, generally processor 702 (e.g., a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), one or more Application Specific Integrated Circuits (ASICs), one or more Radio Frequency Integrated Circuits (RFICs), or any combinations of these), a main memory 704 and a static memory 706, which are configured to communicate with each other via a bus 708. The computer system 700 may also include a graphics display unit 710 (e.g., a Plasma Display Panel (PDP), a Liquid Crystal Display (LCD), a projector, or a Cathode Ray Tube (CRT)). The computer system 700 may also include an alphanumeric input device 712 (e.g., a keyboard), a cursor control device 714 (e.g., a mouse, a trackball, a joystick, a motion sensor, or other pointing instrument), a storage unit 716, a signal generation device 718 (e.g., a speaker), and a network interface device 720, which are also configured to communicate via the bus 708.

The storage unit 716 includes a computer-readable medium 722 on which are stored instructions 724 embodying any one or more of the methodologies or functions described herein. The instructions 724 may also reside, completely or at least partially, within the main memory 704 or within the processor 702 (e.g., within a processor's cache memory) during execution thereof by the computer system 700, the main memory 704 and the processor 702 also constituting computer-readable media. The instructions 724 may be transmitted or received over a network 726 via the network interface device 720.

While the computer-readable medium 722 is shown in an example embodiment to be a single medium, the term "computer-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) that are capable of storing the instructions (e.g., the instructions 724). A computer-readable medium may include any medium that can store instructions (e.g., instructions 724) for execution by a machine and that cause the machine to perform any one or more of the methodologies disclosed herein. The computer readable medium may include, but is not limited to, a data repository in the form of solid state memory, optical media, and magnetic media. Computer-readable media does not include transitory media such as signals or carrier waves.

Other configuration considerations

Certain embodiments are described herein as comprising logic or a plurality of components, engines, modules, or mechanisms. The engine may constitute a software module (e.g., code embodied on a computer-readable medium) or a hardware module. A hardware engine is a tangible unit that is capable of performing certain operations and may be configured or arranged in a certain manner. In an example embodiment, one or more computer systems (e.g., a stand-alone client or server computer system) or one or more hardware engines (e.g., a processor or a set of processors) of a computer system may be configured by software (e.g., an application or application portion) as a hardware engine for performing certain operations described herein.

In various embodiments, the hardware engine may be implemented mechanically or electronically. For example, a hardware engine may comprise permanently configured special-purpose circuitry or logic (e.g., as a special-purpose processor, such as a Field Programmable Gate Array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. The hardware engine may also include programmable logic or circuitry (e.g., included within a general-purpose processor or another programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware engine mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

Various operations of the example methods described herein may be performed, at least in part, by one or more processors (e.g., processor 702) that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily configured or permanently configured, such processors may constitute processor-implemented engines that operate to perform one or more operations or functions. In some example embodiments, the engine referred to herein may comprise a processor-implemented engine.

The execution of certain operations may be distributed among one or more processors, and not only reside within a single machine, but are also deployed across multiple machines. In some example embodiments, one or more processors or processor-implemented modules may be located in a single geographic location (e.g., within a home environment, office environment, or server farm). In other example embodiments, one or more processors or processor-implemented modules may be distributed across multiple geographic locations.

Upon reading this disclosure, those skilled in the art will appreciate further alternative structural and functional designs for similar systems or processes through the principles disclosed herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes, and variations apparent to those skilled in the art may be made in the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the above-described embodiments without departing from the broad general scope of the invention. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

34页详细技术资料下载

上一篇：一种医用注射器针头装配设备

下一篇：用于为分布式账本实现基于别名的寻址的计算机实现的系统和方法

Adjusting transaction distribution based on predicted outstanding transaction execution rate

相关技术

网友询问留言