Systems And Methods For Monitoring, Analyzing and Regulating Blockchain Transactions
20230118380 · 2023-04-20
Inventors
Cpc classification
G06Q20/389
PHYSICS
G06Q20/4016
PHYSICS
International classification
Abstract
Systems and methods for generating a metric based on blockchain data for use in controlling, evaluating, or otherwise regulating a transaction. The metric may be used to control the release of assets, to trigger an event, or as a measure of the satisfaction of contractual conditions based on whether the characteristics of a transaction or of a party engaging in a transaction are associated with a score that satisfies a threshold value. In some embodiments, a state-change derived score or metric allows the creation of a layer of trust or reliability that a blockchain network can reference in situations where a greater degree of trust is desired.
Claims
1. A method, comprising: obtaining a blockchain address; determining a set of transactions associated with the address that are recorded on the blockchain; processing data obtained from the blockchain to generate a representative value for each of the set of transactions; mapping or converting the representative value for each of the set of transactions to a standardized representation; combining one or more of the standard representations into a group score, sub-group score, or an overall score associated with the address; based on the group score, sub-group score, or overall score, determining if a condition related to a stage of a process or transaction is satisfied; if the condition is satisfied, then performing the stage of the process or transaction; and if the condition is not satisfied, then not performing the stage of the process or transaction.
2. The method of claim 1, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises: accessing a rule-set, control logic, or model that uses the group score, sub-group score, or overall score as an input; and based on the rule-set, control logic, or model and the group score, sub-group score, or overall score, determining if the condition related to the stage of the process or transaction is satisfied.
3. The method of claim 1, wherein the process or transaction is one of a token purchase, an agreement to purchase a product or service, a selection of content to present to an entity in control of the address, an event in a gaming environment, an assessment of a performance, or the approval or disapproval of an output of the process.
4. The method of claim 3, wherein the condition related to the stage of the process or transaction is determined by a smart contract.
5. The method of claim 1, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises: combining the group, sub-group, or overall score and one or more factors associated with the address into a total score; and using the total score to determine if the condition is satisfied.
6. The method of claim 5, wherein the one or more factors associated with the address comprise home ownership status, citizenship status, net worth, employee count, internee browsing history, or a result of an off-chain identity verification.
7. The method of claim 1, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises determining if the group score, sub-group score, or overall score exceeds a predetermined value.
8. A system, comprising: one or more electronic processors configured to execute a set of computer-executable instructions; and the set of computer-executable instructions, wherein when executed, the instructions cause the one or more electronic processors to obtain a blockchain address; determine a set of transactions associated with the address that are recorded on the blockchain; process data obtained from the blockchain to generate a representative value for each of the set of transactions; map or convert the representative value for each of the set of transactions to a standardized representation; combine one or more of the standard representations into a group score, sub-group score, or an overall score associated with the address; based on the group score, sub-group score, or overall score, determine if a condition related to a stage of a process or transaction is satisfied; if the condition is satisfied, then perform the stage of the process or transaction; and if the condition is not satisfied, then not perform the stage of the process or transaction.
9. The system of claim 8, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises: accessing a rule-set, control logic, or model that uses the group score, sub-group score, or overall score as an input; and based on the rule-set, control logic, or model and the group score, sub-group score, or overall score, determining if the condition related to the stage of the process or transaction is satisfied.
10. The system of claim 8, wherein the process or transaction is one of a token purchase, an agreement to purchase a product or service, a selection of content to present to an entity in control of the address, an event in a gaming environment, an assessment of a performance, or the approval or disapproval of an output of the process.
11. The system of claim 8, wherein the condition related to the stage of the process or transaction is determined by a smart contract.
12. The system of claim 8, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises: combining the group, sub-group, or overall score and one or more factors associated with the address into a total score; and using the total score to determine if the condition is satisfied.
13. The system of claim 12, wherein the one or more factors associated with the address comprise home ownership status, citizenship status, net worth, employee count, internet browsing history, or a result of an off-chain identity verification.
14. The system of claim 8, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises determining if the group score, sub-group score, or overall score exceeds a predetermined value.
15. A set of computer-executable instructions that when executed by one or more programmed electronic processors, cause the processors to: obtain a blockchain address; determine a set of transactions associated with the address that are recorded on the blockchain; process data obtained from the blockchain to generate a representative value for each of the set of transactions; map or convert the representative value for each of the set of transactions to a standardized representation; combine one or more of the standard representations into a group score, sub-group score, or an overall score associated with the address; based on the group score, sub-group score, or overall score, determine if a condition related to a stage of a process or transaction is satisfied; if the condition is satisfied, then perform the stage of the process or transaction; and if the condition is not satisfied, then not perform the stage of the process or transaction.
16. The set of computer-executable instructions of claim 15, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises: accessing a rule-set, control logic, or model that uses the group score, sub-group score, or overall score as an input; and based on the rule-set, control logic, or model and the group score, sub-group score, or overall score, determining if the condition related to the stage of the process or transaction is satisfied.
17. The set of computer-executable instructions of claim 15, wherein the process or transaction is one of a token purchase, an agreement to purchase a product or service, a selection of content to present to an entity in control of the address, an event in a gaming environment, an assessment of a performance, or the approval or disapproval of an output of the process.
18. The set of computer-executable instructions of claim 15, wherein the condition related to the stage of the process or transaction is determined by a smart contract.
19. The set of computer-executable instructions of claim 15, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises: combining the group, sub-group, or overall score and one or more factors associated with the address into a total score; and using the total score to determine if the condition is satisfied.
20. The set of computer-executable instructions of claim 19, wherein the one or more factors associated with the address comprise home ownership status, citizenship status, net worth, employee count, internet browsing history, or a result of an off-chain identity verification.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
[0075] Embodiments of the invention in accordance with the present disclosure will be described with reference to the drawings, in which:
[0076]
[0077]
[0078]
[0079]
[0080]
[0081]
[0082]
[0083]
[0084]
[0085]
[0086]
[0087]
[0088] Note that the same numbers are used throughout the disclosure and figures to reference like components and features.
DETAILED DESCRIPTION
[0089] The subject matter of embodiments of the present disclosure is described herein with specificity to meet statutory requirements, but this description is not intended to limit the scope of the claims. The claimed subject matter may be embodied in other ways, may include different elements or steps, and may be used in conjunction with other existing or later developed technologies. This description should not be interpreted as implying any required order or arrangement among or between various steps or elements except when the order of individual steps or arrangement of elements is explicitly noted as being required.
[0090] Embodiments of the disclosure will be described more fully herein with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, exemplary embodiments by which the disclosure may be practiced. The disclosure may, however, be embodied in different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy the statutory requirements and convey the scope of the disclosure to those skilled in the art.
[0091] Among other things, the present disclosure may be embodied in whole or in part as a system, as one or more methods, or as one or more devices. Embodiments of the disclosure may take the form of a hardware implemented embodiment, a software implemented embodiment, or an embodiment combining software and hardware aspects. For example, in some embodiments, one or more of the operations, functions, processes, or methods described herein may be implemented by one or more suitable processing elements (such as a processor, microprocessor, CPU, GPU, TPU, controller, etc.) that is part of a client device, server, network element, remote platform (such as a SaaS platform), an “in the cloud” service, or other form of computing or data processing system, device, or platform.
[0092] The processing element or elements may be programmed with a set of executable instructions (e.g., software instructions), where the instructions may be stored on (or in) one or more suitable non-transitory data storage elements. In some embodiments, the set of instructions may be conveyed to a user through a transfer of instructions or an application that executes a set of instructions (such as over a network, e.g., the Internet). In some embodiments, a set of instructions or an application may be utilized by an end-user through access to a SaaS platform or a service provided through such a platform.
[0093] In some embodiments, one or more of the operations, functions, processes, or methods described herein may be implemented by a specialized form of hardware, such as a programmable gate array, application specific integrated circuit (ASIC), or the like. Note that an embodiment of the inventive methods may be implemented in the form of an application, a sub-routine that is part of a larger application, a “plug-in”, an extension to the functionality of a data processing system or platform, or other suitable form. The following detailed description is, therefore, not to be taken in a limiting sense.
[0094] Embodiments of the systems, apparatuses, and methods described herein are directed to evaluating, controlling, or otherwise regulating transactions that are executed using a blockchain by using data contained within a blockchain to generate a metric that represents the behavior of a party. Based on the generated metric or score the party may be presented content, have their participation in a transaction permitted or disallowed, condition their participation in a transaction, select the terms of a contract, or execute a specific process, as examples.
[0095]
[0106]
[0107] One such example of a blockchain explorer application uses declared important state changes as inputs. These important state changes are transactions that are the constituent parts of a desired type of scoring methodology. In one example implementation of a blockchain explorer, a selection of transaction types is combined to create a query package (termed an Important State Change Declaration) that is passed to the blockchain explorer. The blockchain explorer parses this Important State Change Declaration and via queries to a blockchain extracts transactions that meet the declared query specifications.
[0108] The transaction data obtained for the address is processed by a specific set of data manipulations (which may include equations, formulas, transformations, mappings, use as inputs to a trained model, as examples) to generate a specific representative result for those transactions (as suggested by step or stage 128). These data manipulation equations may distill raw data input into representative and/or functional results. In one sense, the data manipulations tally state changes, transactions, and time intervals. For example, a sum operation may be used to tally the number of distinct tokens associated with an address (Token A+Token B+ . . . =Total Tokens). Another example is use of averaging formulas: where the average number of transactions per a specific time interval is determined (i.e., the number of transactions/number of Weeks=number of transactions per week). Another example is a profit and loss calculation (Proceeds of asset sale−cost of acquisition of asset=Profit or Loss on Asset).
[0109] The obtained result(s) are then mapped or converted to a common scale or standardized representation (as suggested by step or stage 130). In one embodiment, the generated results are mapped onto a scoring table/grid and assigned a value. The mapping or conversion is part of a process flow that operates to transpose raw inbound data into algorithmically usable (standardized) values. For example, raw input data that has been passed through the initial data manipulation equations where a sum or average has been obtained may be mapped on individual 100-point scales associated with components of a score. Machine learning can be used in this transposition process where new raw data fitting a certain pattern is transposed to usable values based on previous (learned) transpositions. In one embodiment, the transposition data processing flow is used to derive a consistent initial component value.
[0110] The transposed or converted values may then be assigned individually to a score component, combined to create scoring subcategories (groups), or combined to create a master score (as suggested by step or stage 132). Categories are collections of score components that represent a common theme. For example, the category or group identified as “Velocity”, would be a group of components that represent the number of actions associated to an address within a specified period: the number of new tokens added per week, the number of buy and sell transactions, or the amount of time a token is held before the first sell transactions is made, as non-limiting examples. Another example of a category or group could be “Risk”. This grouping would have constituents that represent the subjective probability of Profit & Loss: the number of low cap tokens held, the P&L on tokens held in the last 6 months, or KYC status, for example.
[0111] The category, subcategory, or group scores may then be combined to generate an overall or master score (as suggested by step or stage 134). Categories, subcategories, groups, or whatever term is chosen to refer to these constituents of a score are building blocks that may be used to generate a master score. The number of these building blocks, their relationships to each other (such as relative weights), or their positions within hierarchies is typically governed by the complexity that is required to generate a desired master score.
[0112] Next, a set of rules, control logic, models, if-then statements, or similar type of decision tool are accessed and used to determine the impact of the category, subcategory, or master score(s) (as suggested by step or stage 136). The rules, control logic, models, or similar type of decision tool may be associated with a specific party to an economic transaction, an entity in a smart contract, an entity in another type of transaction or exchange that is conditioned on specific events or values, etc.
[0113] The accessed rules, control logic, models, if-then statements, or similar type of decision tool are applied using the generated score or scores as inputs to determine a relevant condition, event, or quantity for a clause in a smart contract, an aspect of a transaction, or whether to trigger a condition or event, as examples (as suggested by step or stage 138). The logic may prevent execution of a clause or occurrence of an event in a smart contract unless the generated score satisfies a condition, such as being greater than a specified value, the logic may cause specific content to be presented to an address if the generated score falls within a certain range, or the logic may determine which clause of several in a smart contract is to be executed based on the score associated with the address, as non-limiting examples.
[0114] In describing one or more example embodiments of the disclosed system, apparatuses, and methods, the following terms and abbreviations are used: [0115] Important State Change—ISC [0116] Important State Change Declaration—ISCd [0117] Important State Change Modifier—ISCm [0118] Important State Change Result—ISCr [0119] Important State Change Points—ISCp [0120] Important State Change Points Representative Percentile—ISCpRP [0121] Important State Change Results Return Package—ISCrRP [0122] Declared Family Weight—DFW [0123] Declared Group Weight —GDW [0124] Declared Component Weight—DCW [0125] Raw Data Manipulation Equations—RDME [0126] Group Score Representative Percentile—GSRP [0127] Weighed Score of Group—WSG [0128] Scoring Algorithm—SA [0129] Maximum Important State Change Points—mISCp [0130] Actual Component Score=aCS [0131] Actual Group Score=aGS [0132] Family Point—Fp [0133] Raw Family Score—RFS [0134] Usable Family Score—UFS [0135] Oracle—O [0136] DSFM—Desired Scoring Format Modifier
Note that for most purposes the technical term “State Change” is interchangeable with the term(s) “blockchain carried data”.
[0137] A preparatory step in generating a score is to access or determine and declare the pre-requisites and constants. A scoring algorithm or methodology may reference constants as part of the process of deriving a score. The constants can be housed as flat lists, tables, data repository entries, in code and/or referenced arrays, or in payload format files such as the json format.sup.1, as examples. As examples, the following pre-requisites and constants are representative but not required or exhaustive. .sup.1 JSON is an open standard file format and data interchange format that uses human-readable text to store and transmit data objects consisting of attribute-value pairs and arrays (or other serializable values).
Hierarchies
[0138] Hierarchies are used to organize data based on the amount of processing done on that data. For example, data that has gone through an initial data manipulation equation such as a sum of transactions, would be on the First Level of a hierarchy. Derivative data resulting from the manipulation of first level data, such as the averaging of first level data results, would be considered Second Level data in the hierarchy, and so on through multiple hierarchies. One can distill this concept as follows: [0139] a. First level is a component. A component is an individual Important Data type; [0140] b. Second level is a group. A group is a collection of Important Data types; [0141] c. Third level is a family. A family is a collection of groups; and [0142] d. Subsequent levels can be created using this type of hierarchical approach.
[0143] The Table below is representative of an example of such hierarchies:
TABLE-US-00001 Subsequent Levels Group of Families . . . i.e., Community Third Level Family Second Level Group First Level Component
Data Weight
[0144] The weight of an item of data is the importance of the data within a set of data at a given hierarchy level. If there is a single data point, it by default holds the maximum weight of its singular set. Below is an example of declared data weights, for purposes of illustration only. Weight values are set to reflect end use of the score and determine the relative importance of each data point to the overall end score. Weight(s) can be declared in the ISCd or be contained in an external reference repository. The weights can be set by users manually or programmatically using values provided by a trained Machine Learning model.
TABLE-US-00002 Family Declared 35 Family Weight (DFW) Group Alpha Group Beta Declared 10 25 Group Weight (GDW) Component Component Component Component X Y Z AA Declared 2 3 5 25 Component Weight (DCW)
Machine Learning Models
[0145] Using machine learning, one can facilitate faster and dynamically accurate creation of relevant constants. For example, these constants may comprise one or more of component, group, and family weights. If the requestor of a score is an address associated with a crypto trading platform, then frequency of trades is desirable and should carry higher weight in the score. Therefore, one would implement a DCW (declared component weight) of the number of trades component to equal 70% of the GDW (declared group weight). The system would train the scoring algorithm using a data set comprised of verified official crypto trading platform addresses. The system/algorithm would look at the characteristic state changes that are common to addresses of crypto trading platforms. This could start with broad characteristics such as a high number of send state changes, and gradually be narrowed down to more subtle aspects, such as sends going to external actor addresses as opposed to smart contract addresses.
[0146] When the Oracle (as described herein, the controller or mediator of requests for a score or metric) receives a scoring request, it runs the requesting address against the machine learning derived category of addresses. If the address is one in the crypto trading platform group, then the DCW given to the number of trades would be increased to reflect that within the overall score.
Scoring Tables
[0147] Scoring tables are a mechanism or process for transposing results. They take a result and assign it a representative value. For example, an ISCp Table is used for the transposition of ISC data results to one or more predetermined representative points or values. An Fp Table is used for the transposition of a master score point result into a string.
[0148] It is not necessary for Scoring Tables to maintain consistency within their hierarchies, however for ease of use it may be advisable to implement this feature for ISCp Tables. This means that, for ease of use, there should be a consistent point scale used by components, groups, and families within hierarchies. For example: 0-100 for components, 0-10 for groups, 0-1000 for families. The maximum value of a point scale is termed Maximum Important State Change Points (mISCp) herein. For example, if the scale for ISCp is 0-100, then the mISCp is 100, if it is 0-10, then the mISCp is 10. Below are examples of such Tables:
TABLE-US-00003 Important State Change Point (ISCp) Table ISCp ISCr mISCp 100 0 90 1 80 2 . . . . . . 0 10
TABLE-US-00004 Family Point (Fp) Table Mp Rating 750-1000 Excellent 500-749 Good 250-499 Fair 0-249 Poor
Data Sources
[0149] To facilitate the delivery of ISCr to the Scoring Algorithm (SA), the disclosed method sources required ISC instances. In one embodiment, these sources are: [0150] Blockchains; and/or [0151] Indexes of Blockchain state changes (e.g., Data Repositories).
[0152] ISC data is derived by querying a blockchain directly via blockchain clients and their data query protocols such as JSON-RPC API, JavaScript, python etc., or by querying a data repository such as an index of blockchain data using a dedicated query protocol; [0153] This is similar to the functionality of a blockchain explorer which scans transactions on a chain, although as described herein, the implementation and features may differ.
[0154] A data source can also be an intermediate temporary storage state such as cache, RAM, or temp files, for example. In one embodiment, temporary storage can be used to determine/modify scores in real-time. Similarly, processed and generated scores can be stored both off and on-chain depending on resource availability, use case, and security considerations.
Oracle (O)
[0155] In the context of the disclosure, the Oracle (O) functions or operates as a controller or central processing unit that decides what is to be done with requests for data, or what is to be done with the results of the requests, for example. Instructions for O can be hard coded or be called from external references. Example logic implemented or executed by Oracle is presented below.
Raw Data Manipulating Equations (RIME)
[0156] Equations or formulas may be used to distill raw data input into representative and functional values that are useable by a scoring algorithm. Raw data manipulating equations (or functions or operations) are algorithmic processes such as sum, difference, product, and quotient, as well as averaging forms such as mean, median, mode, midrange, and range. This list of processing functions or operations is not exclusive but illustrates several common examples. For example, one could use summation of each ISC to create an ISCr: ISCr=ISC.sub.1+ISC.sub.2+ISC.sub.3 . . . ISC.sub.n or the process can be more elaborate and use the mean result of ISC's to generate in ISCr: ISCr=(a.sub.1+a.sub.2+a.sub.3 . . . a.sub.n)/n.
Scoring Algorithm (SA)
[0157] The scoring algorithm (or formula, equation, or model, as examples) is a set of mathematical and/or logical equations that generates a score representative of an input. Results obtained from data sources are passed through the Scoring Algorithm to obtain a scoring value or result.
ISCr Requesting Entity
[0158] There are two types of requesting entities that may initiate contact with the Oracle for the purpose of obtaining a score. These entities are smart contracts and non-smart contract requesters. An example of a non-smart contract requester is an externally owned address or an-off chain entity, such as a financial institution initiating a score request via an API.
Target
[0159] Every request for a score that is processed by the Oracle needs to be in relation to a declared blockchain address, that is a target.
[0160] In some embodiments, the general form of a score or metric is a numerical representation of selected data obtained from blockchain state changes. The state changes are evaluated using an algorithm (or formula, model, or equation, for example) and the result of the evaluation is displayed as a numerical value on a pre-determined scale. The numerical value is then interpreted by logic (such as a rule set or model) to make a decision regarding a transaction. The scoring algorithm can be built into blockchains via a Virtual Machine type of integration (e.g., the Ethereum Virtual Machine), as functional reference calls to a centralized or distributed scoring algorithm, or built into smart contract code itself, as examples.
[0161] The scoring method, algorithm, or ruleset may be determined or selected by the party requesting the score, a scoring provider, or a scoring algorithm repository, as examples. The scoring method is flexible in this respect and is typically an iteration of calculating user defined/specified state changes, reporting/tallying/averaging results, and measuring intervals between state changes.
[0162] In one embodiment, the disclosed score or metric may be generated by the following set of steps or stages:
Step 1: Create, Declare or Retrieve ISCd (As Suggested by Step, Stage, Process or Component 150 of FIG. 1(c))
[0163] Blockchain transaction data is a record of distinct, time stamped state changes associated with a blockchain address. This transaction data is stored as constituents of data blocks linked together to form a blockchain. Because of the immutability of the blockchain, state changes recorded on the blockchain are distinct and individually identifiable. State changes are grouped together with like state changes, creating distinct types of state changes: [0164] These distinct types of state changes have a universally adopted nomenclature. For example, the address initiating a value state change is called a SENDER, and the address having its value state changed is termed the RECIPIENT. A state change that is the result of the association of an asset to an address that is paired with a dissociation of an asset can be termed a BUY and conversely, the state change that is the result of the dissociation of an asset (or portion thereof) from an address that is paired with the association of an asset can be termed a SELL.
[0165] To generate an address score, an embodiment performs specific mathematical calculations using a selection of the applicable state changes. Depending on the end use of the score, certain state changes may be more or less important in the generation of the score. Based on this relevancy, state changes are selected to be used (or not) as initial inputs for the scoring method.
[0166] Important State Changes (ISCs) that are included in the score generating method can be assigned individual importance (weight) within that scoring instance.
[0167] Important State Changes (ISCs) can be put together to create a data package called an Important State Change Declaration (ISCd). These declarations (ISCd) are an efficient method of delivering ISCs to the disclosed scoring system. Below are non-limiting examples of data and instruction payloads that an ISCd may carry/transport: [0168] Instructions on how to process the raw data results of queries about an address' ISC results; [0169] Interval or time instances to be used in the processing of raw data results; [0170] Identifying the blockchain(s) from which data is to be used or not used; [0171] Scoring thresholds to be used; [0172] Important State Changes to be used; [0173] Identifying the blocks or block ranges that are to be used or not used; or [0174] Identifying the desired variant of a scoring algorithm to use in the generation of a score.
It should be noted that a distinct ISCd can be synonymous with a score variant as it may embody the distinguishing characteristics that make up a particular variation of a score. The ISCd can be a master data payload, delivered (for example) via a json file; such a file may contain the necessary constants involved in the generation of a score (variant).
[0175] A list of pre-compiled ISCd can be made available to requesters and smart contracts. It is beneficial to have a set of pre-compiled ISCd as they reflect the type of state changes and instructions that are passed to the scoring system based on common use cases of the score or scoring approach. The constitution of such pre-compiled ISCds would typically be determined by the end use case of the score, and one can use industry specific generalizations to create these pre-compilations. The pre-compiled declarations (ISCd) can be refined and augmented based on identified or recognized patterns of use based on manual analysis, statistical analysis, or with machine learning models, as examples.
[0176] For example, machine learning can be used to study frequencies of ISCd's used per industry, thus enabling machine generated ISCd's. For example, one could use a training data set for the Finance industry comprised of ISCd's where the ISCs—Age of Address, Type of Asset, and Profit & Loss (P&L) are relevant. If a requester is a smart contract and is looking to assign a lending rate to an address based on a score, then the system detects the logic within the requesting smart contract, for example: “If returned score=“a”, then give rate x; if returned score=“b” then give rate y”. In such an example, an ISCd comprised of Age of Address, Type of Asset, and P&L is used or generated.
[0177] Non-limiting examples of industry-specific applications and uses of the disclosed system and methods are provided in the following.
An ISCd Example for a Token Sale
[0178] As an example use case and implementation, assume a smart contract which a party would like to limit access to, such as for participation in a sale of a token. The party can accomplish this access control by implementing a score-based access gating process. A score-based process may check if an address requesting access meets or does not meet a specified score or range of scores. If the score or range is satisfied, then access would be permitted; if the score or range is not satisfied, then access would be denied. In one example of this type of decision process, the following steps or stages may be performed: [0179] a) The party decides that it will use a score providing service to obtain a score for its score-based access gating. The score provider has various scoring algorithms or methods available for users, with each using varying inputs and algorithms to determine a score; [0180] b) The party decides to use a specific scoring variant, as it fits the motivation and use case of the party; [0181] c) The scoring variant selected is generated by using a specific Important State Change Declaration (ISCd) and running the data generated by the ISCd through a specific version or iteration of a Scoring Algorithm; [0182] d) The party declares the use of score-based access gating in a smart contract and declares the score result that an address must receive to be permitted access to the smart contract (and/or to cause the execution of a specific term, condition, or clause in the contract). For example, the party declares that the score of 500 is the minimum needed to be permitted access to the smart contract; [0183] e) Each access request from an address received by the smart contract is then checked against the declared scoring criteria by sending an address score request to the score provider; [0184] f) The score provider provides the address to the scoring system and either retrieves an already generated score and returns it to the smart contract, or if a score is not available, then the scoring system generates a score and sends the result to the requesting smart contract; [0185] g) In one embodiment, the score variant used is generated by a scoring method that uses the number of weekly buy transactions of an address and the total value of those transactions. These buy transactions and their values are state change types that are recorded on the blockchain. These state change types (alone or in combination with one another) are used to generate a score reflecting the traits of the entity associated with the address; [0186] h) In this example, the following Important State Change (ISC) types may be part of the associated ISCd. The scoring method can append this declaration of the state changes that are important in the context of a specific use case, with modifications based on what is included as part of a state change record: [0187] The address(s) to be looked up; [0188] The number of times an address was a buyer of coins/tokens; [0189] The sum of coins/tokens associated with each instance in which an address was a buyer; [0190] A time interval to use in the counting of buy instances and their associated values; [0191] The group each ISC is assigned to; [0192] The weight of each ISC within the group it's assigned to; [0193] A specific version of the scoring algorithm to use; and [0194] The score threshold to be met in the decision logic.
[0195] In this example, the Important State Changes Declaration (ISCd) may be expressed in pseudo code as follows:
TABLE-US-00005 1. ISCd Gamma = { 2. Address = XYZ.sub.1, XYZ.sub.2, ... XYZ.sub.n 3. For each Address: a. ISC1 = Buy Instances b. Count ISC1 c. Average ISC1 count using a 7-day interval d. ISC1 in Group 1 e. ISC2 = Value of ISC1 Buy Instances f. Average ISC2 value using a 7-day interval g. ISC2 in Group 2 h. Group 1 weight = 20 i. Group 2 weight = 10 j. ISC1, ISC2 modifier = use blocks ≥1000 & ≤2000 k. Use scoring algorithm Gama l. Score threshold =>500 4. }
An ISCd Example for the Finance Industry
[0196] In this example use case, the following information may be used in determining a score and then making a decision based on the generated score: [0197] Age of the Address—the older the address the larger the data sample size available to derive an inference about the address; [0198] Type of Assets—this information assists in determining risk. Holdings skewed towards low cap, meme/no use case tokens, may indicate a higher risk of a party defaulting on a loan; [0199] Profit and Loss (P&L)—Profit and loss on holdings. Can be used as a moderating indicator to the type of asset ISC; [0200] If the address is turning out consistent profit on higher risk assets, then Type of Asset ISC may not be as important and may be given less weight; [0201] If the case is the opposite and the address is carrying a net loss on its transactions, then it may increase the importance or weighting of Type of Assets; [0202] This is a generalization, as additional factors would typically play into a lender's decision to interact with a party seeking a loan, but it is indicative of the types of ISCs that could be part of a decision-making process and be constituents of an ISCd.
[0203] Given the above as an example, the corresponding ISCd may take the following form:
TABLE-US-00006 1. ISCd = { 2. Address = XYZ.sub.1, XYZ.sub.2, ...XYZ.sub.n 3. ISC1 = Age of Address a. Address creation date vs current date = Age 4. ISC2 = Token Holdings a. Token/Coin i. Balance 5. ISC3 = P&L a. Get token price of each ISC2 (converted to USD) of initial buy transaction. i. Historical price data DEX/CEX; b. If there are more buy transactions before a sell, average the price between those buys. i. Historical price data DEX/CEX c. Get token price of subsequent sell transaction. i. Historical price data DEX/CEX d. Calculate price change between buy price (or aggregate buy price) and sell price then convert it into %. e. Do this for every buy/sell “event” and then average the % between all events. 6. ISCm1 = ≥Genesis & ≤ Latest }
An ISCd Example for a Supply Chain Scenario
[0204] In this example use case, the following information may be used in determining a score and in decisions based on the generated score: [0205] Age of NFT—Age of NFT indicates the time an asset (asset=NFT) entered the supply chain; [0206] Velocity—Time intervals between recorded state changes allows determining the speed at which an asset is moving through a supply chain. This may be useful if an interval outside of an optimal or expected amount indicates an inefficiency; [0207] Transaction count—This provides a measure of the number of steps an asset goes through from origin to destination. For example, an unexpected number of steps may indicate an inefficiency.
[0208] Given the above as an example, the corresponding ISCd may take the following form:
TABLE-US-00007 1. ISCd = { 2. Address = XYZ.sub.1, XYZ.sub.2, ...XYZ.sub.n 3. ISC1 = Age of NFT a. Date NFT added to address assigned to represent first step in supply chain vs. current date = Age 4. ISC2 = Velocity a. Time between state change.sub.1, state change.sub.2, ...state change.sub.n 5. ISC3 = Transaction Count 6. ISCm1 = ≥Genesis & ≤ Latest }
[0209] An example of a .json format based ISCd
TABLE-US-00008 { “nft_group”: { “weight”: 4, “components”: { “owns_nfts”: { “mappings”: { “type”: “boolean”, “mappings”: { “True”: 100, “False”: 0 } }, “max_component_score”: 3, “value”: True }, “owned_nfts”: { “mappings”: { “mappings”: { “0”: 0, “1”: 10, “2”: 20, “3”: 30, “4”: 40, “5”: 50, “6”: 60, “7”: 70, “8”: 80, “9”: 90, “10”: 100 }, “type”: “range”, “min_value”: 0, “max_value”: 10, “direction”: “<=” }, “max_component_score”: 2, “value”: 3 }, “sold_nfts”: { “mappings”: { “mappings”: { “True”: 0, “False”: 100 }, “type”: “boolean” }, “max_component_score”: 1, “value”: True }, “bought_nfts”: { “mappings”: { “mappings”: { “True”: 100, “False”: 0 }, “type”: “boolean” }, “max_component_score”: 2, “value”: True } } }
[0210] In one embodiment, the disclosed scoring system and methods may be extended to provide a more flexible form of constructing an ISCd, such as one in which an end user creates a customized ISCd for use with the scoring system based on ISCs made available to them. To enable the creation of a customized ISCd, the system may create and provide a list of available ISCs that can be selected via a software interface or selected via API calls.
[0211] In one example, an API call can be analogous to currently available direct-to-chain calls, for example, eth_getBalance. In another example, the ISC information may be obtained by a process that retrieves total token holdings per address from pre-compiled data sets found in an index or data repository. In another example, the ISC information may be obtained from a library of processed data points.
[0212] In another example, the disclosed system and methods can be extended to create a customized scoring methodology where ISCs, ISCds, Data Sources, Scoring Algorithms, or other terms or factors can be selected by a user facing application, an API, or other user interface.
Step 2: Communicate ISCd to the Oracle (As Suggested by Step, Stage, Process, or Component 152 of FIG. 1(c))
[0213] In one embodiment, an ISCd is sent as a set of instructions to the Oracle or controller (as suggested by element or component 154 in
Step 3: Oracle Receives Query and Decides What to do with It (As Suggested by Step, Stage, Process, or Component 154 of FIG. 1(c))
[0215] The Oracle functions as a controller that decides what is to be done with requests for data as well as what is to be done with the results of a request. It has its own internal instructions as well as an instruction to read requests in the form of an ISCd.
[0216] As an example, the Pseudo Code for executing one or more Raw Data Manipulation Equations (RDME) may take the form: [0217] 1. Read ISCd [0218] 2. Run ISCd against Data Repository 160 (as suggested by step, stage, process, or function 156 of
[0231] The Pseudo Code for a non-RDME example may take the form: [0232] 1. Read ISCd [0233] 2. Run ISCd against Data Repository 160 (as suggested by step, stage, process, or function 156) [0234] 3. If data found in Data Repository 160 (as suggested by step, stage, process, or function 157) [0235] i. For each ISC1+1 to ISCr1 [0236] ii. For each ISC2+1 to ISCr2 [0237] iii. ISC1 Group=ISCr1Group [0238] iv. ISC2 Group=ISCr2 Group [0239] v. Write ISCr1 to Return Package (ISCrRP) [0240] vi. Write ISCr2 to ISCrRP [0241] vii. Send Return Package to Oracle 154 [0242] 4. If data not found in Data Repository (as suggested by step, stage, process, or function 158) [0243] i. Initiate external data acquisition, for example scrape of blockchain or source data from some other record of blockchain state changes, such as indicated by Blockchain Data Source 162 (as suggested by step, stage, process, or function 159) [0244] ii. Receive data acquisition results (as suggested by step, stage, process, or function 163) [0245] iii. Write data acquisition results in Data Repository 160 (as suggested by step, stage, process, or function 165) [0246] 1. Function 165 is a write data to Blockchain Data Repository, it is not specific to RDME or Non-RDME; [0247] iv. Execute line 3 to write scoring result and send to Oracle 154 (as suggested by step, stage, process, or function 157)
[0248] A non-RDME example is presented to indicate that there are instances where raw data that is returned from a data acquisition process will not need to pass through further processing by an equation or formula (as examples). Such instances can occur when raw data is Boolean in nature and this result is itself a value that can be readily transposed onto a ISCp Table and used by the scoring algorithm, be used without such transposition, or be returned as a final score directly, bypassing the use of data manipulation equations or scoring algorithms.
Step 4: The Returned ISCrRP is Passed to the Scoring Algorithm (SA) (As Suggested by Step, Stage, or Component 166);
[0249] In one embodiment, the described score or index is generated by the following data processing flow, as illustrated in
SA Step 1: Pass ISCrRP to Scoring Algorithm (SA) (As Suggested by Step or Stage 166);
[0250] ISCrRP is returned to Oracle from a Data Repository. Oracle identifies incoming data as ISCrRP and passes constituent ISCr to scoring algorithm for processing;
SA Step 2: Plot ISCr on ISCp Table (step or stage 167);
[0251] The first function the scoring algorithm executes, is a plot of ISCr onto corresponding pre-assigned and pre-declared ISCp Tables.
[0252] Pseudo Code:
[0253] If ISCr=x then ISCp=y
SA Step 3: Get Actual Component Score (aCS) (Step or Stage 168);
[0254] Calculate the aCS result that a component received within its Group.
(ISCp*DCW)/mISCp=aCS Example formula
SA Step 4: Get Actual Group Score (aGS) (Part of Step or Stage 169);
[0255] Add all aCS within group to get the aGS,
aCS.sub.1+aCS.sub.2+ . . . aCS.sub.n=aGS Formula
SA Step 5: Get Group Score Representative Percentile (GSRP) (Step or Stage 170);
[0256] aGS is converted into a percentile of the DGW.
aGS/DGW=GSRP Example formula
SA Step 6: Get Weighed Score of Group (WSG) (Step or Stage 171);
[0257] Each group has an assigned weight in relation to other groups within a family. Similarly, as is the case with components and groups. This weight is declared in the ISCd, a reference file table, or similar data source.
GSRP*DFW=WSG Example formula
SA Step 7: Combine WSG's to Create a Raw Family Score (RFS) (Step or Stage 172);
[0258] Add all WSG within group to get the RFS.
WSG.sub.1+WSG.sub.2+WSG.sub.3+ . . . +WSG.sub.n=RFS Example formula
SA Step 8: Convert to Usable Family Score (UFS) (Step or Stage 173);
[0259] Depending on end use, the process may convert the RFS into a more user-friendly representation of the derived score.
RFS*Desired Scoring Format Modifier (DSFM) Example formula
[0260] Example: [0261] 1. DSFM=1000 [0262] 2. RFS*DSFM=UFS
Step 5: Record Score in Data Repository (Step or Stage 174);
[0263] Generated score is sent to O (Oracle). Oracle forwards score to Data Repository.
[0264] An entry in a Data Repository is created for the derived address score. A record is kept as it facilitates faster retrieval in the future and periodic updates based on new ISC or external data. It also facilitates metrics based on historical score values.
Step 6: Return Score to the Requesting Entity 176 (Step or Stage 175);
[0265] Generated score is sent to O 154 (Oracle). O identifies data as Score and routs score to requesting entity 176.
[0266] As a summary, in one embodiment, an example scoring algorithm described may be expressed as (using the described definitions): [0267] 1. (ISCp*DCW)/mISCp=aCS [0268] 2. aCS.sub.1+aCS.sub.2+aCS.sub.3 . . . +aCS.sub.n=aGS [0269] 3. aGS/DGW=GSRP [0270] 4. GSRP*DFW=WSG [0271] 5. WSG.sub.1+WSG.sub.2+WSG.sub.3 . . . +WSG.sub.n=RFS [0272] 6. Optional: RFS*DSFM=UFS
[0273] Expressed in terms of variables, the scoring algorithm takes the form: [0274] 1. (A*B)/C=D [0275] 2. D.sub.1+D.sub.2+D.sub.3 . . . +D.sub.n=E [0276] 3. E/F=G [0277] 4. G*H=l [0278] 5. I.sub.1+I.sub.2+I.sub.3 . . . +I.sub.N=J [0279] 6. Optional: J*K=L
[0280] The scoring algorithm (SA) can be considered a method of evaluating on-chain data patterns. The algorithm and its constituent components are intended to provide accurate inferences about the characteristics, behavior, and motivations of the actor associated with an address. The scoring approach uses blockchain stored transactions, which are generalized into transaction types. These represent inferences themselves and can be used to make conclusions about the characteristics, behavior, motivation of the address associated with these transactions.
[0281] These inferences can be combined with one another, creating variations or more complete representations of the actor controlling an address. For example, an address that has an on-chain pattern of frequent transactions with the meme token subset of smart contracts may mean that the actor controlling the address has an affinity for volatile tokens. This is valuable information but may be too limited to make it actionable.
[0282] To provide a more complete and reliable evaluation, one may decide to look at other on-chain transaction types and their patterns and use those to make additional inferences and combine those inferences into a more complete picture of the behavior of the address. For example, take the meme token affinity and pair it with an average value of transactions “sub-score”, then pair it further with an average Profit or Loss percentage value that triggers the address to make a buy or sell transaction. One can combine these sub-scores to create a representative score that could suggest that the actor behind the address has an affinity for meme tokens, not as a store of value, but instead as a source of quick income.
[0283] In one embodiment, a score will be presented as a numerical representation of ISC's that were compiled and run through a scoring algorithm. The score is an efficient reference or representation of a party's query result in relation to an address of interest. That query is driven by the querying party's end use of the score which itself may have complex motivations.
[0284] Consider the previously mentioned token sale where a score acts as a control mechanism to permit or deny an address's interaction with the token issuing contract. The management team for the sale has an idea of who their ideal purchaser of tokens is, that is their target customer/audience. A score that takes into consideration the characteristic(s) of their ideal customer allows for a layer of control (e.g., in terms of the execution of a contract term) that was previously unavailable. A compiled score provides information about the entity that controls an address, and data-based inferences can be made about that entity's motivations and goals. A score requester can then make an informed judgment if these goals align with their own. The score can therefore be considered a representative identity marker of the controlling entity of an address.
[0285] As another alternative, assume the hypothetical token sale management team has an ongoing token project with live buy and sale transactions on a decentralized exchange. Rather than initially controlling access to their token based on a score, they use an aggregate score, compiled from scoring all addresses interacting with their smart contract, to learn more about the addresses and entities controlling them. With this information they can implement a gating score instance that would identify/filter undesirable addresses and prevent them from being able to acquire the token.
[0286]
[0287] The process is initiated (159) via a lookup query that reads blockchain (162) blocks (162-1, 162-2, as examples), where the address being sought is not found in Block 162-1, and is found in Block 162-2, as non-limiting examples. For the block in which the address being sought is found, the processing identifies transactions (as suggested by 162-3) and the relevant state changes (as suggested by 162-4, 162-5, and 162-6) associated with the address. If a relevant state change is found (as suggested by 162-6), it is conceptually labelled (for the purposes of this disclosure) as an Important State Change and the data is passed to Oracle (154), and subsequently (if necessary) via RDME (164) to Blockchain Data Repository (160).
[0288]
[0289] In general, an embodiment of the invention may be implemented using a set of software instructions that are designed to be executed by a suitably programmed processing element (such as a GPU, TPU, CPU, microprocessor, processor, controller, computing device, etc.). In a complex application or system such instructions are typically arranged into “modules” with each such module typically performing a specific task, process, function, or operation. The entire set of modules may be controlled or coordinated in their operation by an operating system (OS) or other form of organizational platform.
[0290] The application modules and/or submodules may include any suitable computer-executable code or set of instructions (e.g., as would be executed by a suitably programmed processor, microprocessor, or CPU), such as computer-executable code corresponding to a programming language. For example, programming language source code may be compiled into computer-executable code. Alternatively, or in addition, the programming language may be an interpreted programming language such as a scripting language,
[0291] As shown in
[0292] Modules 202 are stored in a memory 220, which typically includes an Operating System module 204 that contains instructions used (among other functions) to access and control the execution of the instructions contained in other modules. The modules 202 in memory 220 are accessed for purposes of transferring data and executing instructions by use of a “bus” or communications line 216, which also serves to permit processor(s) 230 to communicate with the modules for purposes of accessing and executing a set of instructions. Bus or communications line 216 also permits processor(s) 230 to interact with other elements of system 200, such as input or output devices 222, communications elements 224 for exchanging data and information with devices external to system 200, and additional memory devices 226.
[0293] Each application module or submodule may correspond to a specific function, method, process, or operation that is implemented by the module or submodule. Each module or submodule may contain a set of computer-executable instructions that when executed by a programmed processor or processors cause the processor or processors (or a device or devices in which they are contained) to perform the specific function, method, process, or operation. Such function, method, process, or operation may include those used to implement one or more aspects of the disclosed system and methods, such as for: [0294] Initiating a process of score generation or retrieval (may be part of instructions contained in module 206, or provided by external request and processed); [0295] Obtaining the Type of Address Score to be Generated or Retrieved and an Address Corresponding to Entity of Interest (as suggested by module 206); [0296] Determining Transaction Data Associated with the Address that is Contained in the Blockchain (module 208); [0297] Generating Representative Values for Transactions, and Map or Convert Representative Values to Common Scale(s) or Representations (module 210); [0298] Combining Data in Format of Common Scale(s) or Representations into Scoring Groups (Categories) and/or Sub-Groups (module 211); [0299] Combining One or More Scores from Scoring Groups and/or Sub-Groups into Overall Score (module 212); [0300] Accessing Rule, Control Logic, Or Model Applicable To Smart Contract Clause, Interpretation Of Condition, Triggering Of Event, Determination Of Value, Or Condition Related To Stage Of Process Or Transaction (module 214); and [0301] Using Overall Score As Input, Apply Accessed Rule, Control Logic, Or Model To Determine Smart Contract Clause, Interpretation Of Condition, Triggering Of Event, Determination Of Value, Or Condition Related To Stage Of Process Or Transaction (module 215).
[0302] As mentioned, each module may contain instructions which when executed by a programmed processor cause an apparatus (such as a server or client device) perform the specific function or functions. The apparatus may be one or both of a client device or a remote server or platform. Therefore, a module may contain instructions that are performed by the client device, the server or platform, or both.
[0303] The elements, components, processes, processing stages, scoring approaches, and scoring-based logic described herein can be applied in multiple contexts and operating environments, and to assist in making a decision in almost any industry or context that is able to record information on a blockchain. As non-limiting examples, the following sections include a process flow and the associated elements or components for the following: [0304] The generation of a score derived from blockchain data; [0305] An implementation without the use of a Scoring Algorithm calculation; [0306] An example Scoring Method/Algorithm; and [0307] An example of an implementation of the described approach in the context of a Smart Contract.
[0308]
[0309] As shown in the figure, an example of the processing flow begins when a data package (ISCrRP) (element or process 166), which in certain instances can contain multiple important state change results (ISCr), is passed to the Scoring Algorithm, thus creating a first level scoring instance, termed a Component. The scoring algorithm then takes important state change results and plots them on an important state change point table to create a uniform scoring instance, resulting in translation/conversion of ISCr to ISCp.
[0310] With reference to
[0311] Component groups (or simply Groups) are an internal mechanism used in some embodiments to create a thematically similar set of components. Thematical similarity is a subjective grouping concept. For example, if one is interested in the risk tolerance of a particular party as represented by the transaction history of a wallet, one could examine or one or more of a set of characteristics. These might include (as examples): how many times the wallet conducted a transaction with a currently inactive dex (decentralized exchange) enable smart contract (failed project); how many times the wallet conducted a translation with a dex enabled smart contract that has liquidity below 100 ETH (Ethereum); and how many different tokens the wallet holds.
[0312] Within a group each component is assigned an importance value (DCW) in comparison to other components within the group. In this scoring instance/example, the mentioned components have DCW's of 4, 4 and 2 (as indicated by data values 306), cumulatively amounting to a DGW of 10 (as indicated by data value 308), respectively and aCS values of 3.2, 2.8 and 1.6 amounting to an aGS of 7.6 (as indicated by process step, stage, or operation 169 and data value 310). Similarly to when the process calculated the ISCpRP at the component level, the process now performs an aGS to percentile conversion at the group level by dividing the aGS by DGW. This produces the group's representative percentile (GSRP) value (as indicated by process step, stage, or operation 170). This percentile is representative of how well the scored address has performed within the thematic grouping that was created.
[0313] There can be a number of thematic groupings reflecting different behavior characteristics, with the one chosen depending upon the specific characteristics that it is desired the final score of an address reflect. Groupings may be based on one or more of risk tolerance, velocity of trading, value of assets, or asset holding patterns, as non-limiting examples. Each group would follow the same derivative calculations based on the inputs provided and each group having its importance within this level of hierarchy reflected by its own Declared Family Weight (DFW), that is how important that group is within a group of groups which are termed a Family herein.
[0314] Continuing with reference to
[0315] The preceding steps can be repeated for other groups to arrive at their own individual WSG values. The WSG values are then added together to create the Raw Family Score (RFS) (as indicated by process step, stage, or operation 172). In some embodiments, the RFS is the final score the process derives, albeit in a “raw” format. This raw format can be used for the purposes of the algorithm, however there may be instances where a more convenient score is presented to the score requestor, for example where a DSFM (a score modifier, such as a multiplicative value) is applied to the generated score.
[0316] In some embodiments, a DSFM includes not only mathematical transposition but may also include appending or prepending a number or character string with machine and or human readable numbers or characters, giving more granular use case flexibility (as indicated by process step, stage, or operation 173). This generated score (a value of 715 in the example illustrated) is then sent to the Blockchain Data Repository and/or returned to the requestor (as indicated by process step, stage, or operation 174).
[0317]
[0318] This simple derivation of a representative score is extremely powerful and versatile. For example, the processing flow illustrated in
[0319] The resulting process flow provides a score that represents a verified identity of the external entity controlling a wallet. This score can be used to facilitate a Zero Knowledge Proof of identity (ZKPI) interaction on the blockchain, where a communicated score of 1 to a requesting entity signals that the hash/wallet in question has passed a KYC verification process. Although it may appear that adding a value of “False” to the ISCp table is redundant, this does serve a purpose. In score algorithm variations with multiple components, one can weigh the importance of a hash/address not being verified, and so the ability to assign a 0 or arbitrary point value to a False or No result ISCr becomes useful as it influences the derived score.
[0320] In one embodiment, a description of the process flow for the example illustrated in
[0339] The algorithm expressed using document definitions: [0340] 1. ISCr ISCp (optional)
[0341] The algorithm expressed using variables:
[0342] 1. R->A (optional) The algorithm expressed using number into variable:
[0343] 1. 1->Y (optional)
[0344]
[0345] A contract owner (501), contract controlling entity, or an authorized 3rd party (502) defines what information or criteria will determine a decision to permit or deny interaction with the smart contract. For example, the decision to permit or deny interaction may depend upon a requesting address having a history of frequent decentralized exchange (DEX) transactions. As an example, five (5) or more DEX transactions per week may be what the controlling entity considers as sufficient to satisfy this criterion. The criterion is communicated via an Important State Change declaration (ISCd, as suggested by element or process 504). This ISCd can be dynamically set or hard coded in the smart contract. When a request to interact (as indicated by process step, stage, or operation 506) comes from an external address (Requester Address, 505) the smart contract (indicated by element or process 508) sends a query (indicated by process step, stage, or operation 509) to the scoring Oracle (element or process 510) requesting a score that reflects the criteria passed in the ISCd (indicated by process step, stage, or operation 504).
[0346] The Oracle 510 controls the performance of the process of score generation and/or retrieval and communicates the score back to the smart contract (as indicated by process step, stage, or operation 512). Smart contract 508 “reads” the score and evaluates it against the applicable criteria using a decision process/logic (514). Decision process/logic 514 may consider criterion provided by the ISCd (504) and/or criterion that is hardcoded into the contract (as indicated by process step, stage, or operation 513) in its logical processes. If the score satisfies the threshold value, then Smart contract 508 permits interaction; if the score does not satisfy the threshold, then the interaction is denied (as indicated by process step, stage, or operation 515).
[0347] In one embodiment, a description of the process flow for the example illustrated in
[0372] The algorithm expressed using document definitions: [0373] 1. ISCr.sub.1->ISCp.sub.1, ISCr.sub.2->ISCp.sub.2 . . . ISCr.sub.n->ISCp.sub.n [0374] 2. ISCp.sub.1*DCW.sub.1]/mISCp.sub.1=aCS.sub.1, [ISCp.sub.2*DCW.sub.2]/mISCp.sub.2=aCS.sub.2 . . . [ISCp.sub.n*DCW.sub.n]/mISCp.sub.n=aCS.sub.n [0375] 3. aCS.sub.1+aCS.sub.2 . . . aCS.sub.n=aGS.sub.1, aCS.sub.a1+aCS.sub.a2 . . . ADC.sub.an=aGS.sub.2 . . . aCS.sub.n+aCS.sub.n. . . ADC.sub.nn=aGS.sub.n [0376] 4. aGS.sub.1/DGW.sub.1=GSRP.sub.1, aGS.sub.2/DGW.sub.2=DGW.sub.n=GSRP.sub.n [0377] 5. GSRP.sub.1*DFW.sub.1=WSG.sub.1, GSRP.sub.2*DFW.sub.2=WSG.sub.2, GSRP.sub.n*DFW.sub.n=WSG.sub.n [0378] 6. WSG.sub.1+WSG.sub.2 . . . WSG.sub.n=RFS [0379] 7. Optional: RFS*DSFM=UFS
[0380] The algorithm expressed using variables: [0381] 1. R.sub.1->A.sub.1, R.sub.2->A.sub.2 . . . R.sub.n->A.sub.n [0382] 2. [A.sub.1B.sub.1]/C.sub.1=D.sub.1, [A.sub.2*B.sub.2]/C.sub.2=D.sub.2 . . . [A.sub.n*B.sub.n]/C.sub.n=D.sub.n [0383] 3. D.sub.1+D.sub.2+ . . . =E.sub.1, D.sub.a1+D.sub.a2+ . . . =E.sub.2 . . . D.sub.an+D.sub.an+ . . . =E.sub.n [0384] 4. E.sub.1/F.sub.1=G.sub.1, E.sub.2/F.sub.2=G.sub.2 . . . E.sub.n/F.sub.n=G.sub.n [0385] 5. G.sub.1*H.sub.1=I.sub.1, G.sub.2*H.sub.2=I.sub.2 . . . G.sub.n*H.sub.n=I.sub.n [0386] 6. I.sub.1+I.sub.2 . . . I.sub.n=J [0387] 7. Optional: J*K=L
[0388] The algorithm expressed using numbers (abbreviated): [0389] 1. 4->60, 180->50, 90->1 . . . [0390] 2. (60*3)/100=1.8, (50*5)/100=2.5, (90*2)/100 [0391] 3. 1.8+2.5+1.8=6.1 [0392] 4. 6.1/10=0.61 [0393] 5. 0.61*0.18=0.1098, . . . [0394] 6. 0.1098+0.144+0.0936+0.084+0.17+0.114=0.7154 [0395] 7. 0.7154*1000=715
Example Variations of the Scoring Algorithm (SA)
[0396]
[0397] As shown in
[0398] It should be noted that, employing a negative ISCp can result in negative sub-scores as the processing flows through the scoring hierarchies, ultimately resulting in an overall negative master score, if such a possibility is desired.
[0399]
[0400]
[0401]
[0402] A non-exhaustive list of scoring process events or process flow changes that a triggering event may initiate includes: [0403] the addition of some set of variables; [0404] the addition of an external static variable or an external variable; [0405] discarding of a variable, component, group, or family; or [0406] a modification of a SA constituent, where a non-exhaustive list of potentially modified constituents may include weight variables, point tables, or equations.
[0407] Although embodiments have been described with reference to regulating a commercial transaction, the techniques and methods described herein may be applied in other contexts. Scoring blockchain addresses provides a mechanism to evaluate blockchain stored data representing user behavior at a per participant granularity. The score can be used for multiple purposes and in multiple contexts. As examples, the following are further use cases, in addition to the use case of regulating or conditioning an economic transaction.
Qualified Smart Contract Interaction
[0408] A smart contract can set a certain minimum score criteria to permit someone to buy a token, with a person's score determined by evaluation of a person's blockchain data, particularly their data related to experience with purchasing tokens, types of tokens previously purchased, or holding periods, as examples. A smart contract may set a threshold value and any address that attempts to initiate a buy is denied if their score falls below the set value.
Advertising (Qualified display of data)
[0409] A score can be used as part of a process to target a specific audience. A web service that requires users to log in by connecting their wallet can use the score of the connected wallet to decide the advertising content to serve. Advertisers can declare the type of behavior they seek as an audience for content. For example, they may want to present content to frequent participants in low value transactions. Based on this declaration, a score that reflects frequent low value transactions can be used to determine who is served the advertisers messaging.
Credit Scoring (Ranking)
[0410] Based on on-chain behavior a credit score can be issued to a wallet. Additionally, a financial credit scoring agency can incorporate the described blockchain score into the formula from which their credit score is derived. This is an example of bridging on-chain and off-chain behavior and creating a hybrid scoring mechanism.
[0411] A credit score or rating can be derived for smart contracts and/or organizations using smart contracts or the blockchain as an underlying operational technology (DAO—Decentralized autonomous organizations or Token/Coin based projects, as examples). In addition, as the regulatory framework surrounding blockchain matures, blockchain derived assets are increasingly likely to be classified as securities (at least for some use cases or contexts), making issuing entities subject to security offering/trading regulations. The scoring mechanism(s) disclosed herein may be used as part of a process to evaluate behaviors within such environments and/or assist regulatory agencies to track and monitor behaviors to ensure compliance with relevant rules and regulations.
Incentivizing Behavior (Conditioning)
[0412] A party that desires to incentivize a certain behavior can set a score to be achieved by the parties that it wishes to influence. These parties are encouraged to follow a set pattern of behaviour to reach the score or target and receive the benefit from the party setting the score value.
Off-Chain Commercial Interactions
[0413] Customer-to-Customer (C2C), Business-to-Customer (B2C), and Business-to-Business (B2B) interactions can be moderated by incorporating the score into a process to permit, deny, or allow a qualified permit/deny for a transaction. For example, offering goods and services to clients that meet a desired score threshold value.
Finance
[0414] A lender/investor can incorporate the score into their risk analysis algorithms. The score may be used to influence the lending/investing terms offered to a requesting party.
Regulation
[0415] As governments consider use of Central Bank Digital Currencies (CBDCs), the disclosed scoring approach may enable regulatory entities to monitor and assess CBDC holders, enabling regulatory policy development/changes to fit real world usage statistics.
Performance Assessment
[0416] For example, medical practitioner performance records kept on a blockchain could be scored and any anomalies would be made more clearly identifiable and addressable. Performance scoring can also be employed with physical goods, such as critical car components, where blockchain recorded problems can be evaluated and scored using a version of the proposed scoring mechanism.
NFTs
[0417] Non-Fungible tokens are smart contracts or the products thereof and can be evaluated and scored by leveraging on-chain data. This may range from trading history scores (such as where velocity of transfers is evaluated), to more complex scoring based on NFT characteristics in relation to the market desirability of those characteristics.
Decentralized Blockchain Gaming
[0418] In decentralized gaming, variants of the disclosed scoring algorithm can be used to evaluate in game aggregate or individual actions and combine them into a generated meta score or individual granular scores.
Metaverses
[0419] In instances of real/digital world hybrids such as AR driven Metaverses where blockchain is part of the technology employed, scoring of state changes is also applicable. Transactions, assets, or entities in such metaverses can be assessed via their associated and recorded chain data and issued a score, with the score then used by participants or in-world processes to make a decision.
Identification
[0420] KYC, ZKPI and other identification related uses where an entity's verified identity status can be reduced, using the proposed methods, to a score variable are not limited to single criterion examples. A score can reflect different levels of verification, thus enabling greater granularity. A score of an address that reflects verification of identity papers could be different then the score of an address that reflects verification of identity papers and a confirmation of residential address details, for example.
Data Analytics
[0421] An assigned wallet score facilitates aggregation of anonymized on-chain activity data. For example, a scoring instance can be run against all wallets that interacted with a smart contract. The returned scores represent a representative profile of the interacting parties, as well as identifying those parties by their addresses. Both sets of information may have uses to other entities for purposes of advertising, promotion, providing services, or regulation, as examples.
Security
[0422] Monitoring or scanning blockchains for scores that reflect interactions with questionable entities using the disclosed scoring approaches may also be possible and facilitates flagging or indicating suspicious activity, and qualified flagging based on a supplied severity index. For example, interaction with crypto mixing services, known money/crypto laundering offramps such as bullion for crypto entities, or sanctioned exchanges or banks, could be used to generate a specific type of score that would be communicated to a monitoring entity for further investigation.
[0423] Further, the described scoring method or algorithm can be modified to incorporate other factors (other types of blockchain data) and data processing rules. Multiple types of scores may be created using varying ISC, modifiers, and data sources depending on the intended use. External (off-blockchain) factors can also be used to combine, append to, or change a score or its algorithm. As non-limiting examples: [0424] A metric formed from a combined Score+Home Ownership Status; [0425] A metric formed from a combined Score+Citizenship status; [0426] A metric formed from an appended Score+Net Worth; [0427] A metric formed from a combined Score+Employee Count; [0428] A metric formed from an appended Score+Internet Browsing History; [0429] A metric formed from a modified score based on off-chain Identity Verification; or [0430] A metric formed from a combined Score+other off chain factor,
[0431] In some embodiments, the disclosed scoring algorithm can be modified. For example, variables can be inserted, removed, or modified as decided upon by the score requester. These changes can be triggered by on-chain and off-chain events. Non-limiting examples of such triggers are: [0432] Machine learning (ML) triggered updates of the steps to derive a score based on industry specific use cases. For example, if a score requester is identified by an ML process to be in the financial industry, then this might trigger the inclusion of financial industry specific changes to the scoring algorithm, such as the use of variable weight components, or use of a specific ISC such as Address Age; [0433] Fluid inputs such as commodity prices that are representative of non-static variables; or [0434] Current metrics found in blockchain services focus on evaluating smart contracts, and in particular, smart contracts that issue tokens or coins as means of exchange and/or investment. This represents a focus on factors such as available liquidity, price, number of holders, and the circulating and fully diluted market capitalization of the smart contract and its issued token. While useful, this is a very narrow and limited approach to a data-based understanding of blockchain participants, and their corresponding value, quality, desirability, utility, or veracity, as examples.
[0435] The disclosed score or index is a mechanism/method of categorizing, profiling, ranking, and segmenting/grouping blockchain hashes (addresses) based on their activity, thereby allowing the assignment of a score based on that activity from data retrieved from a blockchain record(s). In one sense, the described scoring system shifts the focus from tokens and smart contracts to blockchain hashes that represent individual blockchain wallets, where the described scoring system can be applied to any address on the blockchain (which would include smart contracts as well).
[0436] The disclosure includes the following clauses and embodiments: [0437] 1. A method, comprising: [0438] obtaining a blockchain address; [0439] determining a set of transactions associated with the address that are recorded on the blockchain; [0440] processing data obtained from the blockchain to generate a representative value for each of the set of transactions; [0441] mapping or converting the representative value for each of the set of transactions to a standardized representation; [0442] combining one or more of the standard representations into a group score, sub-group score, or an overall score associated with the address; [0443] based on the group score, sub-group score, or overall score, determining if a condition related to a stage of a process or transaction is satisfied; [0444] if the condition is satisfied, then performing the stage of the process or transaction; and [0445] if the condition is not satisfied, then not performing the stage of the process or transaction. [0446] 2. The method of clause 1, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises: [0447] accessing a rule-set, control logic, or model that uses the group score, sub-group score, or overall score as an input; and [0448] based on the rule-set, control logic, or model and the group score, sub-group score, or overall score, determining if the condition related to the stage of the process or transaction is satisfied. [0449] 3. The method of clause 1, wherein the process or transaction is one of a token purchase, an agreement to purchase a product or service, a selection of content to present to an entity in control of the address, an event in a gaming environment, an assessment of a performance, or the approval or disapproval of an output of the process. [0450] 4. The method of clause 3, wherein the condition related to the stage of the process or transaction is determined by a smart contract. [0451] 5. The method of clause 1, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises: [0452] combining the group, sub-group, or overall score and one or more factors associated with the address into a total score; and [0453] using the total score to determine if the condition is satisfied. [0454] 6. The method of clause 5, wherein the one or more factors associated with the address comprise home ownership status, citizenship status, net worth, employee count, Internet browsing history, or a result of an off-chain identity verification. [0455] 7. The method of clause 1, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises determining if the group score, sub-group score, or overall score exceeds a predetermined value. [0456] 8. A system, comprising: [0457] one or more electronic processors configured to execute a set of computer-executable instructions; and [0458] the set of computer-executable instructions, wherein when executed, the instructions cause the one or more electronic processors to [0459] obtain a blockchain address; [0460] determine a set of transactions associated with the address that are recorded on the blockchain; [0461] process data obtained from the blockchain to generate a representative value for each of the set of transactions; [0462] map or convert the representative value for each of the set of transactions to a standardized representation; [0463] combine one or more of the standard representations into a group score, sub-group score, or an overall score associated with the address; [0464] based on the group score, sub-group score, or overall score, determine if a condition related to a stage of a process or transaction is satisfied; [0465] if the condition is satisfied, then perform the stage of the process or transaction; and [0466] if the condition is not satisfied, then not perform the stage of the process or transaction. [0467] 9. The system of clause 8, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises: [0468] accessing a rule-set, control logic, or model that uses the group score, sub-group score, or overall score as an input; and [0469] based on the rule-set, control logic, or model and the group score, sub-group score, or overall score, determining if the condition related to the stage of the process or transaction is satisfied. [0470] 10. The system of clause 8, wherein the process or transaction is one of a token purchase, an agreement to purchase a product or service, a selection of content to present to an entity in control of the address, an event in a gaming environment, an assessment of a performance, or the approval or disapproval of an output of the process. [0471] 11. The system of clause 8, wherein the condition related to the stage of the process or transaction is determined by a smart contract. [0472] 12. The system of clause 8, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises: [0473] combining the group, sub-group, or overall score and one or more factors associated with the address into a total score; and [0474] using the total score to determine if the condition is satisfied. [0475] 13. The system of clause 12, wherein the one or more factors associated with the address comprise home ownership status, citizenship status, net worth, employee count, internet browsing history, or a result of an off-chain identity verification. [0476] 14. The system of clause 8, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises determining if the group score, sub-group score, or overall score exceeds a predetermined value. [0477] 15. A set of computer-executable instructions that when executed by one or more programmed electronic processors, cause the processors to: [0478] obtain a blockchain address; [0479] determine a set of transactions associated with the address that are recorded on the blockchain; [0480] process data obtained from the blockchain to generate a representative value for each of the set of transactions; [0481] map or convert the representative value for each of the set of transactions to a standardized representation; [0482] combine one or more of the standard representations into a group score, sub-group score, or an overall score associated with the address; [0483] based on the group score, sub-group score, or overall score, determine if a condition related to a stage of a process or transaction is satisfied; [0484] if the condition is satisfied, then perform the stage of the process or transaction; and [0485] if the condition is not satisfied, then not perform the stage of the process or transaction. [0486] 16. The set of computer-executable instructions of clause 15, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises: [0487] accessing a rule-set, control logic, or model that uses the group score, sub-group score, or overall score as an input; and [0488] based on the rule-set, control logic, or model and the group score, sub-group score, or overall score, determining if the condition related to the stage of the process or transaction is satisfied. [0489] 17. The set of computer-executable instructions of clause 15, wherein the process or transaction is one of a token purchase, an agreement to purchase a product or service, a selection of content to present to an entity in control of the address, an event in a gaming environment, an assessment of a performance, or the approval or disapproval of an output of the process. [0490] 18. The set of computer-executable instructions of clause 15, wherein the condition related to the stage of the process or transaction is determined by a smart contract. [0491] 19. The set of computer-executable instructions of clause 15, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises: [0492] combining the group, sub-group, or overall score and one or more factors associated with the address into a total score; and [0493] using the total score to determine if the condition is satisfied. [0494] 20. The set of computer-executable instructions of clause 19, wherein the one or more factors associated with the address comprise home ownership status, citizenship status, net worth, employee count, internet browsing history, or a result of an off-chain identity verification. [0495] 21. The set of computer-executable instructions of clause 15, wherein determining if a condition related to a stage of a process or transaction is satisfied further comprises determining if the group score, sub-group score, or overall score exceeds a predetermined value. [0496] 22. The method of clause 2, wherein the model is a trained machine learning model. [0497] 23. The method of clause 1, wherein mapping or converting the representative value for each of the set of transactions to a standardized representation or combining one or more of the standard representations into a group score, sub-group score, or an overall score associated with the address is performed using a trained model. [0498] 24. The method of clause 7, wherein the predetermined value is determined by a trained model. [0499] 25. The system of clause 9, wherein the model is a trained machine learning model. [0500] 26. The system of clause 8, wherein mapping or converting the representative value for each of the set of transactions to a standardized representation or combining one or more of the standard representations into a group score, sub-group score, or an overall score associated with the address is performed using a trained model. [0501] 27. The system of clause 14, wherein the predetermined value is determined by a trained model. [0502] 28. The set of computer-executable instructions of clause 16, wherein the model is a trained machine learning model. [0503] 26. The set of computer-executable instructions of clause 15, wherein mapping or converting the representative value for each of the set of transactions to a standardized representation or combining one or more of the standard representations into a group score, sub-group score, or an overall score associated with the address is performed using a trained model. [0504] 27. The set of computer-executable instructions of clause 21, wherein the predetermined value is determined by a trained model,
[0505] It should he understood that the present invention as described above can he implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement the present invention using hardware and a combination of hardware and software.
[0506] Machine learning (ML) is being used more and more to enable the analysis of data and assist in making decisions in multiple industries. To benefit from using machine learning, a machine learning algorithm is applied to a set of training data and labels to generate a “model” which represents what the application of the algorithm has “learned” from the training data. Each element (or instances or example, in the form of one or more parameters, variables, characteristics or “features”) of the set of training data is associated with a label or annotation that defines how the element should be classified by the trained model. A machine learning model in the form of a neural network is a set of layers of connected neurons that operate to make a decision (such as a classification) regarding a sample of input data. When trained (i.e., the weights connecting neurons have converged and become stable or within an acceptable amount of variation), the model will operate on a new element of input data to generate the correct label or classification as an output.
[0507] In some embodiments, certain of the methods, models or functions described herein may be embodied in the form of a trained neural network, where the network is implemented by the execution of a set of computer-executable instructions or representation of a data structure. The instructions may be stored in (or on) a non-transitory computer-readable medium and executed by a programmed processor or processing element. The set of instructions may be conveyed to a user through a transfer of instructions or an application that executes a set of instructions (such as over a network, e.g., the Internet). The set of instructions or an application may be utilized by an end-user through access to a SaaS platform or a service provided through such a platform. A trained neural network, trained machine learning model, or any other form of decision or classification process may be used to implement one or more of the methods, functions, processes, or operations described herein. Note that a neural network or deep learning model may be characterized in the form of a data structure in which are stored data representing a set of layers containing nodes, and connections between nodes in different layers are created (or formed) that operate on an input to provide a decision or value as an output.
[0508] In general terms, a neural network may be viewed as a system of interconnected artificial “neurons” or nodes that exchange messages between each other. The connections have numeric weights that are “tuned” during a training process, so that a properly trained network will respond correctly when presented with an image or pattern to recognize (for example). In this characterization, the network consists of multiple layers of feature-detecting “neurons”; each layer has neurons that respond to different combinations of inputs from the previous layers. Training of a network is performed using a “labeled” dataset of inputs in a wide assortment of representative input patterns that are associated with their intended output response. Training uses general-purpose methods to iteratively determine the weights for intermediate and final feature neurons. In terms of a computational model, each neuron calculates the dot product of inputs and weights, adds the bias, and applies a non-linear trigger or activation function (for example, using a sigmoid response function).
[0509] Any of the software components, processes or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as Python, Java, JavaScript, C, C++, or Perl using conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands in (or on) a non-transitory computer-readable medium, such as a random-access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. In this context, a non-transitory computer-readable medium is almost any medium suitable for the storage of data or an instruction set aside from a transitory waveform. Any such computer readable medium may reside on or within a single computational apparatus and may be present on or within different computational apparatuses within a system or network.
[0510] According to one example implementation, the term processing element or processor, as used herein, may be a central processing unit (CPU), or conceptualized as a CPU (such as a virtual machine). In this example implementation, the CPU or a device in which the CPU is incorporated may be coupled, connected, and/or in communication with one or more peripheral devices, such as display. In another example implementation, the processing element or processor may be incorporated into a mobile computing device, such as a smartphone or tablet computer.
[0511] The non-transitory computer-readable storage medium referred to herein may include a number of physical drive units, such as a redundant array of independent disks (RAID), a floppy disk drive, a flash memory, a USB flash drive, an external hard disk drive, thumb drive, pen drive, key drive, a High-Density Digital Versatile Disc (HD-DVD) optical disc drive, an internal hard disk drive, a Blu-Ray optical disc drive, or a Holographic Digital Data Storage (HDDS) optical disc drive, synchronous dynamic random access memory (SDRAM), or similar devices or other forms of memories based on similar technologies. Such computer-readable storage media allow the processing element or processor to access computer-executable process steps, application programs and the like, stored on removable and non-removable memory media, to off-load data from a device or to upload data to a device. As mentioned, with regards to the embodiments described herein, a non-transitory computer-readable medium may include almost any structure, technology, or method apart from a transitory waveform or similar medium.
[0512] Certain implementations of the disclosed technology are described herein with reference to block diagrams of systems, and/or to flowcharts or flow diagrams of functions, operations, processes, or methods. It will be understood that one or more blocks of the block diagrams, or one or more stages or steps of the flowcharts or flow diagrams, and combinations of blocks in the block diagrams and stages or steps of the flowcharts or flow diagrams, respectively, can be implemented by computer-executable program instructions. Note that in some embodiments, one or more of the blocks, or stages or steps may not necessarily need to be performed in the order presented or may not necessarily need to be performed at all.
[0513] These computer-executable program instructions may be loaded onto a general-purpose computer, a special purpose computer, a processor, or other programmable data processing apparatus to produce a specific example of a machine, such that the instructions that are executed by the computer, processor, or other programmable data processing apparatus create means for implementing one or more of the functions, operations, processes, or methods described herein. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement one or more of the functions, operations, processes, or methods described herein.
[0514] While certain implementations of the disclosed technology have been described in connection with what is presently considered to be the most practical and various implementations, it is to be understood that the disclosed technology is not to be limited to the disclosed implementations. Instead, the disclosed implementations are intended to cover various modifications and equivalent arrangements included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
[0515] This written description uses examples to disclose certain implementations of the disclosed technology, and to enable any person skilled in the art to practice certain implementations of the disclosed technology, including making and using any devices or systems and performing any incorporated methods. The patentable scope of certain implementations of the disclosed technology is defined in the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural and/or functional elements that do not differ from the literal language of the claims, or if they include structural and/or functional elements with insubstantial differences from the literal language of the claims.
[0516] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and/or were set forth in its entirety herein.
[0517] The use of the terms “a” and “an” and “the” and similar referents in the specification and in the following claims are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms “having,” “including,” “containing” and similar referents in the specification and in the following claims are to be construed as open-ended terms (e.g., meaning “including, but not limited to,”) unless otherwise noted. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value inclusively falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illuminate embodiments of the invention and does not pose a limitation to the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to each embodiment of the present invention.
[0518] As used herein (i.e., the claims, figures, and specification), the term “or” is used inclusively to refer to items in the alternative and in combination.
[0519] Different arrangements of the components depicted in the drawings or described above, as well as components and steps not shown or described are possible. Similarly, some features and sub-combinations are useful and may be employed without reference to other features and sub-combinations. Embodiments of the invention have been described for illustrative and not restrictive purposes, and alternative embodiments will become apparent to readers of this patent. Accordingly, the present invention is not limited to the embodiments described above or depicted in the drawings, and various embodiments and modifications can be made without departing from the scope of the claims below.