JP2021514507A - Methods and systems for demonstrating the credibility of the other party based on value - Google Patents

Abstract

The present invention is a method of proving the credibility of a counterparty in commerce, buying and selling, and lending, which involves creating an account, associating personally identifiable information with the account, and the individual associated with the account. The step of assigning a limiter value based on the type of identifying information and the step of receiving a request from the guarantor to prove the credibility of the entity, in which the guarantor is documented with the other party. A step that has a previous involvement or verifiable connection, and a step that assigns a guarantor to prove an entity, including assigning a tokenized asset associated with the guarantor. , The step of receiving a rating or termination notice from a third party (or the other party) regarding the involvement between the third party (or the other party) and the entity, the step of analyzing the associated rating or outcome, and the rating or outcome. A method comprising coordinating a first portion of a tokenized asset associated with a guarantor with a second portion of the tokenized asset based on an analysis.

Description

Mutual reference to related applications This application is U.S. Patent Application No. 62/629827 filed February 13, 2018 and U.S. Patent Application No. 62/6754100 filed May 23, 2018. (And claims the benefit of priority under Section 120 of the US Patent Act). The disclosure of the prior application is considered part of the disclosure of this application (and shall be incorporated by reference into the disclosure of this application).

Background This disclosure is supported by value in general with respect to certification systems and methods, and more specifically with respect to the credibility of those entities as they seek to engage in commerce, sale, or lending activities with third parties. With respect to methods, computer programs, and computer systems for making guaranteed warranties.

Trust forms the basis of buying and selling, commerce and finance. The center of trust is credibility. There is no universal formula for establishing credibility. This is because the credibility system is fluid in nature and responds to technological advances that increase the transparency and accountability of the other party.

With the advent of Internet-based social-sourced consumer opinion platforms such as Yelp®, Angie's List®, Google Reviews®, and Facebook Business®, individuals are now owning their own. Got a voluntary and powerful signal that incrementally signals purchasing and patronage decisions. These signals also embody new discoveries in credibility, merely to informal "word-of-mouth" insights, limited to the decentralized signals of direct social or business networks. It is driving rapid changes in consumer behavior, from dependence to deepening trust in the social web of "electronic" word-of-mouth platforms.

No matter how successful these systems are in establishing a new baseline for credibility, they prove to be far from ideal, as research has shown their inherent vulnerability to fraud. Consumers are becoming more and more cautious about the tactics that take advantage of system loopholes adopted by the listed entities.

According to some surveys, 20% of online reviews are fraudulent, and companies are trying to mask negative feedback through guided reviews or paid reviews.

Existing reputation systems have a centralized opaque nature of third-party consumer opinion platforms; due to misalignment of the economic benefits of pay-to-play listings or advertising services, algorithm filtering or search rankings. Unfair / wrong priorities; biased towards negative reviews because customers with negative experience are more likely to express disapproval than customers with positive experience That: Positive review / rating bias as a result of corporate guidance (email, messaging apps, etc.); Loss of personal accountability protocol, i.e. customer review incentive program at no risk all rewards , Public tampering; there is a social impact bias where social signals overly influence the reviewer's sentiment; post-purchase review involvement is estimated to be only 2-5% It is vulnerable to fraud because it is inadequate to represent the entire history of involvement, which distorts the vendor's profile;

In addition, current credit rating systems often exclude the majority of loan applicants, such as self-employed or those who do not have sufficient collateral or a reliable credit history, from access to credit institutions regardless of their actual debt repayment capacity. Attempts to establish the borrower's financial credibility or creditworthiness based on several factors. To further complicate matters, there is more than one criterion for determining the creditworthiness of a potential borrower, which is arbitrary, confusing, and often results in conflicting credit scoring results. ..

Therefore, staking values against the outcome of the above transaction or involvement, motivating participants to accurately represent the credibility of the entity, and deterring fraud for the benefit of all participating parties. A method, computer program, or computer system for dealing with deficiencies inherent in existing systems for establishing the reputation or credibility of counterparties in commerce and lending, by which an entity can guarantee a trading party. desired.

Overview In the first embodiment, the present invention utilizes a value staking guarantee mechanism to prove the credibility of an entity involved in commerce and buying and selling, supporting a positive outcome. And, conversely, if the negative consequences are supported, there is an economic penalty for the certifier, and the method is cryptographically secure distribution by one or more processors. The step of creating an account for all participants on the type ledger, where the account is identified by a unique account name, number, key, or address, by the step and one or more processors. , One or more steps to attach at least one personally identifiable information data to the account, and one or more processors to assign limiter values based on the type of personally identifiable information data associated with the account. It is a step of receiving a request from the guarantor account to prove the credibility of the entity or to stake the credibility of the entity by multiple processors, and the guarantor account is still with the entity. Steps with previous documented financial involvement and the step of assigning a guarantor account to prove the credibility of an entity or to steak into the credibility of an entity by one or more processors. And the allocation receives a rating of the entity's activity by a third party by a step and one or more processors that allocate a portion of at least one tokenized asset associated with the guarantor account. Steps and steps to analyze an entity's rating by one or more processors, and tokenized by one or more processors associated with the guarantor account to reflect the entity's involvement rating. A step of adjusting the amount or balance of assets, including a step in which the amount of positive adjustment is limited by the account limiter.

In a second embodiment, the invention utilizes a stake-based collateral or insurance mechanism to prove the creditworthiness of the entity involved in the borrowing, in which the borrower lends according to contractual repayment terms. If it is confirmed that the mortgage is redeemed, there will be an economic reward to the certifier, and conversely, if it is confirmed that the borrower has failed to redeem the loan according to the contractual obligation, the collateral of the backer Delivered to the lender in the form of compensation, the method is the step of creating an account for all participants on a cryptographically secure distributed ledger by one or more processors. Is identified by a unique account name, number, key, or address, and one or more processors that associate at least one personally identifiable information data with an account by one or more processors. Receives a request from a certifier account to secure a loan for an entity by one or more processors, with the step of assigning a limiter value based on the type of personally identifiable information data associated with the account. It is a step, yet the certifier account has expressed its intention to pledge on behalf of the borrowing entity, to secure the entity's loan by the step and one or more processors, or the entity. As insurance for a loan, the step of allocating a certifier account, which allocates at least one tokenized asset owned by the certifier account, by the step and one or more processors, the debtor. The step of receiving evidence of successful or unsuccessful redemption of the loan obligation by the debtor, if the debtor redeems the loan in a timely manner, or if the borrower defaults on the loan, with collateral based on the certifier's stake Includes the step of allocating the amount from loan interest to the certifier's account by one or more processors when delivered to the creditor.

In a third embodiment, the present invention is a computer program product for demonstrating the credibility of an entity involved in commerce and buying and selling by utilizing a value staking guarantee mechanism, with a positive ending. If supported, there will be an economic reward for the certifier, and conversely, if supported for a negative outcome, there will be an economic penalty for the certifier, and the computer program product will be one or more computer-readable storage media. And program instructions stored on one or more computer-readable storage media, the program instructions for creating an account for all participants on a cryptographically secure distributed ledger. A program instruction, the account is identified by a unique account name, number, key, or address, to the program instruction and to attach at least one personally identifiable information data to the account. A guarantor account with program instructions to assign limiter values based on the type of associated personally identifiable information data and requests to prove the credibility of the entity or to steak into the credibility of the entity. A program instruction to receive from, yet the guarantor account has a documented previous financial involvement with the entity, to prove the credibility of the program instruction and the entity, or to credit the entity. A program instruction to assign a guarantor account for sexual staking, the assignment is a program instruction and a third that allocates a portion of at least one tokenized asset associated with the guarantor account. Tokenized associated with the guarantor account to reflect the program instructions for receiving the party's rating of the entity's activity, the program instructions for analyzing the entity's rating, and the entity's involvement rating. A program instruction for adjusting the amount or balance of assets, including a program instruction in which the amount of positive adjustment is limited by an account limiter.

In a fourth embodiment, the present invention is a computer system for proving the credibility of an entity involved in commerce and buying and selling by utilizing a guarantee mechanism in which values are stakes, with a positive ending. If supported, there will be an economic reward for the certifier, and conversely, if backed up for a negative outcome, there will be an economic penalty for the certifier, and the computer system will have one or more computer processors and one. Alternatively, the program instructions include cryptographically secure program instructions, including multiple computer-readable storage media and program instructions executed on one or more computer-readable storage media and stored on one or more computer-readable storage media. A program instruction to create an account for all participants on a distributed ledger, the account being identified by a unique account name, number, key, or address, with a program instruction and at least one. Prove the credibility of an entity with a program instruction to attach one personally identifiable information data to an account, a program instruction to assign a limiter value based on the type of personally identifiable information data associated with the account, and a program instruction to assign a limiter value. , Or a program instruction to receive a request from the guarantor account to stake the credibility of the entity, yet the guarantor account has a documented previous financial involvement with the entity. Have a program instruction and a program instruction to assign a guarantor account to prove the credibility of the entity or to stake the credibility of the entity, the assignment associated with the guarantor account. Program instructions to allocate a portion of at least one tokenized asset, program instructions to receive a rating of an entity's activity by a third party, program instructions to analyze an entity's rating, and entity involvement. A program instruction to adjust the amount or balance of tokenized assets associated with a guarantor account to reflect the rating of, in which the amount of positive adjustment is limited by the account limiter. Includes program instructions that are made.

It is a block diagram which shows the computing environment by one Embodiment of this invention. It is a block diagram which shows the computing environment by another embodiment of this invention. Credit for verifying the level of personal identification attached to the guarantor's profile and applying the reward limiter to the guarantor's account within the computing environment of FIG. 1 according to one embodiment of the invention. It is a flowchart of the operation step performed by an evaluation program. It is a block diagram which shows the structure of the account in the computing environment by another embodiment of this invention. An image of a federated identification source within a computing environment, according to another embodiment of the invention. It is an image of the process of registering a protocol integrator with an account in a computing environment according to another embodiment of the present invention. It is a block diagram which shows the computing environment by another embodiment of this invention. It is a flowchart of the operation step performed by the credit evaluation program for processing the guarantee of the entity and the reward or penalty in the computing environment of FIG. 1 according to the embodiment of the present invention. It is a flowchart of the operation step performed by the credit evaluation program for processing the generation, guarantee, and dispute resolution of the event outside the network in the computing environment of FIG. 1 according to the embodiment of the present invention. According to one embodiment of the present invention, by a credit evaluation program for processing bids by guarantors competing for the maximum number of slots of bidders per event in the computing environment of FIG. It is a flowchart of the operation step. It is a block diagram which shows the computing environment by another embodiment of this invention. It is a flowchart of the operation step performed by the credit evaluation program for demonstrating the creditworthiness of the entity involved in borrowing in the computing environment of FIG. 1 according to the embodiment of the present invention. It is a flowchart of the operation step performed by the credit evaluation program for implementing the token protocol in the computing environment of FIG. 1 according to the embodiment of the present invention. It is a block diagram which shows the computing environment by another embodiment of this invention. It is a flowchart of the operation step performed by the credit evaluation program for processing a dispute resolution in the computing environment of FIG. 1 according to the embodiment of the present invention. FIG. 3 is a block diagram showing internal and external components of the server of FIG. 1 according to one embodiment of the present invention.

The drawings show various embodiments of the techniques of the present disclosure for illustrative purposes only, and similar reference numerals are used to identify similar elements. Those skilled in the art will readily appreciate from the following discussion that alternative embodiments of the structures and methods illustrated in the drawings may be employed without departing from the principles of the art of the present disclosure described herein. You will recognize.

Detailed Description As will be appreciated by those skilled in the art, aspects of the invention are feasible as a system, method, or computer program product. Accordingly, aspects of the invention are exclusively in hardware embodiments, exclusively in software embodiments (including firmware, resident software, microcode, smart contracts, etc.), or in software and hardware embodiments. In the present specification, it can be generally referred to as a "circuit", a "module", or a "system". Further, aspects of the invention can take the form of computer program products implemented within one or more computer-readable media incorporating computer-readable program codes / instructions.

Embodiments of the present invention disclose stake-based protocols and frameworks for multilaterally proving the credibility of a counterparty.

The present invention is both a "reputation network" protocol that relies on distributed ledger technology and a set of web technologies that enable the invention to be seamlessly integrated into existing commercial, trading, and lending platforms. The present invention is also an incentive-based fraud deterrence mechanism for establishing the credibility or credibility of the other party, in more practically adjusting the interests of participants in the commerce, sale and lending ecosystem. It plays an essential role, resulting in higher reliability and improved service.

The guarantee mechanism of the present invention is that the guarantor (the person giving the guarantee or a group of people) personally stakes the outcome of an economic event in which the entity to which the guarantee is given participates. , Is an important differentiator to existing reputation, rating, and review systems. The stake here consists of cryptographically protected tokens. If the event is positive, the guarantor will be rewarded with additional tokens commensurate with the amount of staking. Conversely, in the event of a negative outcome, the guarantor is penalized by a proportional deduction from the token balance, also known as slash. Guarantor activities are limited to participants with a history of verifiable transactions or involvement with parties seeking credibility backed by the guarantor. In the lending context, the guarantor will need to prove a relationship with the borrower to secure the borrower's loan or as insurance for the borrower's loan. Both of these processes are referred to herein as "credification".

The invention can also be incorporated and integrated into the lending system as a form of third-party collateral or insurance for the borrower's default. One example of the integration of the present invention is integration into microfinance, especially microcredit, to accelerate the adoption of digital commerce. Socially and economically disadvantaged individuals cannot afford to secure collateral because they lack credible and secure means of maintaining ownership of their property. At the same time, the credit scoring system commonly used in advanced financial systems is not available in developing countries. Instead, a trusted reputation system can play a useful role by notifying the risk of default associated with a particular individual. In particular, a standardized reputation system can motivate the provision of capital on a peer-to-peer (P2P) basis and relies on a central intermediary with market power (and thus high fees) as the only source of finance. Eliminate the need to have to. These transactions can be managed by smart contracts, which issue rewards for loan repayments and transfer stakes collateral to lenders to sanction any default in order to mitigate losses. ..

Next, the present invention will be described in detail with reference to the drawings.

FIG. 1A shows a block diagram showing a computing environment 100A according to one embodiment of the present invention. FIG. 1A provides an example of one embodiment and does not imply any environmental limitation, and different embodiments may be implemented.

In the illustrated embodiment, the computing environment 100A includes a network 102, a server 104, a rating service 106, a provider 107, and a computing device 109. In the illustrated embodiment, the server 104 includes a database 108 and a credit evaluation program 109. The computing environment 100A may include additional servers, computers, or other devices (not shown).

The network 102 can be a local area network (LAN), a wide area network (WAN) such as the Internet, or any combination thereof, according to embodiments of the invention, or a server 104 and a rating service 106. And any combination of connections and protocols that can assist in communication between the provider 107 and the computing device 109. The network 102 may include a wired connection, a wireless connection, or a fiber optic connection. Network 102 links using technologies such as Ethernet, 802.11, Global Interoperable Microwave Access (WiMAX), 3G, 4G, 5G, CDMA, GSM, LTE, Digital Subscriber Line (DSL), etc. Can include. Similarly, the network protocols used in network 102 are multi-protocol label switching (MPLS), transmission control protocol / internet protocol (TCP / IP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), and simple. It may include a mail transfer protocol (SMTP), a file transfer protocol (FTP), and the like. Data exchanged over network 102 can be represented using technologies and / or formats including JSON Object Notation (JSON), Hypertext Markup Language (HTML), and XML Markup Language (XML). is there. In addition, all or some communication channels can be encrypted using traditional encryption techniques such as Secure Socket Layer (SSL), Transport Layer Security (TLS), and Internet Protocol Security (IPsec). ..

Identity provider 107 includes one or more third party services for identifying participants in the system. Examples of these providers 107 are various DID providers 107, OAuth providers 107, KYC providers 107, and the like. Provider 107 serves as a source for the entity's account information or identification data. Provider 107 can be represented by various other data sources or structures in the system, including, but not limited to, databases, objects, classes, meta elements, files, or any other data structure. Entities can register with provider 107 to connect their information to their accounts in the system. The provider 107 may differ depending on the network, and may include a provider's web server, blockchain, distributed ledger, API request, external system, authorization department, security system, privacy system, logging system, and the like.

The server 104 can be a management server, a web server, or any other electronic device or computing system capable of processing program instructions and sending and receiving data. In another embodiment, the server 104 can be a laptop computer, a tablet computer, a netbook computer, a personal computer (PC), a desktop computer, or any programmable electronic device capable of communicating via the network 102. In one embodiment, the server 104 can be a server computing system that uses a plurality of computers as a server system, such as in a cloud computing environment. In one embodiment, the server 104 is a computing system that utilizes clustered computers and components to act as a single pool of seamless resources. In the illustrated embodiment, the database 108 is located on the server 104, but may be located outside the server 104. The server 104 may include components as illustrated and described in more detail with respect to FIG.

Computing device 107 includes one or more computing devices used by a guarantor, provider, witness, third party, or other entity to send and receive data over network 102 in connection with the credit evaluation process. .. The computing device 109 can be any other electronic device or computing system capable of processing program instructions and sending and receiving data. In one embodiment, the computing device 109 is, for example, a conventional computer system running a Microsoft Windows compatible operating system (OS), Apple OS X, and / or a Linux® distribution. In another embodiment, the computing device 109 can be a device having computer functions, such as a smartphone, tablet, personal digital assistant (PDA), mobile phone, and the like. In some embodiments, the computing device 109 may communicate with the rating service 106 and server 104 via a laptop computer, tablet computer, netbook computer, personal computer (PC), desktop computer, or network 102. It can be any programmable electronic device that can. In another embodiment, the computing device 109 can be a server computing system that uses a plurality of computers as a server system, such as in a cloud computing environment. In another embodiment, the computing device 109 is a computing system that utilizes clustered computers and components that act as a single pool of seamless resources.

In one embodiment, the computing device 109 interacts with the rating service 106 via an application programming interface such as iOS and Android or a credit rating program 109. The computing device 109 can display the content by processing the markup language, and the credit evaluation program 109 can display this information. Credit evaluation program 109 uses a format or presentation written in a markup language to display the identified content. Examples of markup languages are extensible markup language (XML) data, extensible hypertext markup language (XHTML) data, or other markup language data. Credit rating program 109 also has the ability to process JavaScript Object Notation (JSON) data, JSON with paddig (JSONP), and JavaScript data to facilitate data exchange between rating service 106 and computing device 109. Can include. In other embodiments, the computing device 109 may include any combination of credit evaluation programs 109 or database 108. The computing device 109 may include components as illustrated and described in more detail with respect to FIG.

The credit evaluation program 109 operates to verify the guarantor, process the stake, and process the distribution of the stake, based on the outcome received. In the illustrated embodiment, the credit evaluation program 109 utilizes the network 102 to access the computing device 107, the provider 107, and the rating service 106. In one embodiment, the credit evaluation program 109 resides on the server 104. In another embodiment, the credit evaluation program 109 is provided on another server or computing device, assuming that the credit evaluation program 109, the computing device 109, the provider 107, and the rating service 106 are provided. May be placed in. In the illustrated embodiment, the identity protocol 110, the event registration protocol 112, the token protocol 114, and the staking protocol 116 are elements of the credit rating program 109. In additional embodiments, the identity protocol 110, the event registration protocol 112, the token protocol 114, and the staking protocol 116 are independent elements that communicate over the network 102.

Identity Protocol 110 (CriD) handles identity registration and account management systems, which are submitted or submitted for the strongest possible basis of identity authenticity. It combines personally identifiable information, which may not be available, but is directly provided, with existing identity verification protocols and OAuth-compliant ID services. In the illustrated embodiment, the identity protocol 110 is a function of the credit evaluation program 109. In another embodiment, the identity protocol 110 is located on another server, another computing device, or another location, assuming that the identity protocol 110 has access to other components of the computing environment 100A. It may be a stand-alone program or function.

The event registration protocol 112 (CreV) acts as a cryptographically verifiable event registration system and plays an important role in establishing the authenticity of the interactions of the entities of the identity protocol 110. In this role, the event registration protocol 112 acts as an oracle for the determination algorithm of the token protocol 114. These interactions are necessary for the credit valuation program 109 to determine the ability of an individual or organization to guarantee the party seeking credit valuation. In the illustrated embodiment, the event registration protocol 112 is a function of the credit evaluation program 109. In another embodiment, the event registration protocol 112 is located on another server, another computing device, or another location, assuming that the event registration protocol 112 has access to other components of the computing environment 100A. It may be a deployed stand-alone program or feature.

Token Protocol 114 (CreD) is, in one example, a utility token based on a blockchain smart contract, or, in another example, a digital asset wrapper that is central to the guarantee and incentive protocol of credit evaluation program 109. Smart contracts can register any digitized asset or security. In some embodiments, the digitized asset or security is selectable by the parties or the market. In additional embodiments, digitized assets or securities can be linked to various other currencies (eg, US dollars). In one embodiment, the blockchain smart contract is Ethereum® featuring smart contract functionality, or various other open source, public or private blockchain-based distributed computing platforms or operating systems. Is. More specifically, token protocol 114 is the currency of staking. In the illustrated embodiment, the token protocol 114 is a function of the credit evaluation program 109. In another embodiment, the token protocol 114 is located on another server, another computing device, or another location, assuming that the token protocol 114 has access to other components of the computing environment 100A. It may be a stand-alone program or function.

The staking protocol 116 (CreS) is a distributed service and extension of the event registration protocol 112 and is connected to program 109. The staking protocol 116 implements multi-party dispute resolution logic for peer-to-peer activities and for determining the outcome of an event. The program is responsible for staking protocol reward allocation or stake slashes, depending on the outcome of the event. In the illustrated embodiment, the staking protocol 116 is a function of the credit evaluation program 109. In other embodiments, the staking protocol 116 resides on another server, another computing device, or another location, assuming that the staking protocol 116 has access to other components of the computing environment 100A. It may be a deployed stand-alone program or feature.

Database 108 can be a repository writable and / or readable by credit evaluation program 109, identity protocol 110, event registration protocol 112, token protocol 114, and staking protocol 116. In one embodiment, the database 108 is a database management system (DBMS) used to enable the definition, creation, query, update, and operation of a database. In some embodiments, the database 108 is a distributed ledger. In some embodiments, the database 108 is a decentralized database or decentralized database system. A blockchain is a data structure that stores a list of transactions and can be thought of as a decentralized electronic ledger that records transactions between source and destination identifiers on database 108. Database 108 can store data in one centralized location or in multiple decentralized (decentralized) locations. The decentralized nature of blockchain can also be advantageous for certain applications such as digital cryptocurrencies, as the system or entity is not the only recordkeeper. This eliminates or reduces reliance on banks, governments, and other third parties, and excludes these "intermediaries" from the trading process, resulting in lower transaction costs. it can. In an additional embodiment, the database 108 is designed to receive data from the InterPlanetary File System (IPFS). In the illustrated embodiment, the database 108 resides on the server 104. In another embodiment, the database 108 is on another server or on the assumption that the database 108 is accessible to the credit rating program 109, the identity protocol 110, the event registration protocol 112, and the staking protocol 114. Resident on another computing device.

FIG. 1B shows a block diagram showing a computing environment 100B according to one embodiment of the present invention. FIG. 1B provides an example of one embodiment and does not imply any restrictions on the environment, and different embodiments may be implemented. In the illustrated embodiment, the computing device 109, different types of markets, and different types of P2P lending platforms communicate with the infrastructure of credit evaluation program 109. In some embodiments, the market is, but is not limited to, the market of various third party merchants.

FIG. 2 shows a flowchart 200 of a method for a guarantor to verify the level of personal identification attached to his profile and apply a reward limiter to the guarantor's account. The following paragraphs describe methods and related processes according to one embodiment of the invention with reference to FIG. 2 in detail.

The ability to securely establish accurate and verifiable protocol participant identities is important for a stake-based, decentralized approach to demonstrating counterparties. Without such guarantees, it is difficult to claim with an acceptable level of credibility that participants are acting on their own resources within the system. To verify the guarantor's identity, it is necessary to identify the guarantor through at least one verification and authentication process.

In step 201, the identity protocol 110 receives the metadata associated with the identity information provided by the guarantor. In some embodiments, this supplied metadata is encrypted with the guarantor's private key and in the blockchain to protect this data and the guarantor's private and personal information. Hashed. The identifying information can be, but is not limited to, a government-issued ID, date of birth, telephone number, address, third-party resource, identity provider 107 containing a profile, and the like. For example, Identity Protocol 110 is, but is not limited to, a service that is compliant with a decentralized identifier (DID) (eg, Civic, Gem, and various other decentralized identifiers based on the blockchain protocol). , Or an OAuth 2.0 identity provider 107 that includes a profile (LinkedIn, Facebook, Line, etc.) can be used to verify the guarantor. In some embodiments, a predetermined number of different identification sources are required to verify the guarantor. In some embodiments, Identity Protocol 110 is able to access a variety of sources to collect the required or approved identification information. In some embodiments, the personally identifiable information is stored in an encrypted form. In additional embodiments, the metadata associated with the personally identifiable information is stored instead of the personally identifiable information.

In step 204, the identity protocol 110 analyzes the received metadata associated with the identifying information to determine the accuracy of the information. Identity Protocol 110 can determine the accuracy of the information provided through a third party resource or service. This verified information is stored by Identity Protocol 110.

In some embodiments, the post-mortem analysis of personally identifiable information (PII) provided by the guarantor is encrypted on the client side, for example using the AES256 block cipher, with the guarantor's private key, database 108. Saved in. The data can be hashed by the blockchain protocol before it is stored. Cleartext input to the cipher for decentralized identification resources is represented by its cross-chain JSON payload, while OAuth input removes the authentication token and retains the available profile data. Is normalized by doing. In some embodiments, the ciphertext is stored in the DDB, the digest component of the multi-hash identifier is indexed and put into the guaranteed smart contract. Smart contracts can be of various different forms and types, such as smart contracts, split contracts, and so on.

In step 206, the identity protocol 110 applies a limiter to the guarantor based on the validation information received. Limiters are used to encourage guarantors to provide as much identification as possible. By imposing a limiter on potential rewards / payments, the guarantor is encouraged to provide more information to increase payment / reward opportunities. Each form of identification information is associated with a limiter based on a given variable. In some embodiments, the limiter modifies, adjusts, modifies, or reconfigures based on the type of identifying information, the reputation of the identifying information, and the value of the identity protocol 110 associated with the identifying information.

For example, the initial limiter is set at 90% of the payment, which means that the guarantor can only receive 10% of the reward / payment. In some embodiments, when the guarantor provides the KYC identification information, the limiter is reduced to 50%, and when registered using DID, an additional 15% reduction is provided, and an OAuth-linked account is provided. Then, it is additionally reduced by 5%. Each form of identification information and the source of the identification information has a predetermined limiter modifier, and the guarantor can have the predetermined limiter modifier applied to his / her account. The identification information restrictions are based on the credit evaluation program 109's assessment of each type of identification information. In some embodiments, the type of identifying information is added to or removed from the guarantor, which updates the calculation with the addition or removal of information.

For example, the following equation can be applied to the limiter:

Where φ is the condition for including the KYC, α is the number of linked DIDs, β is the total number of OAuth 2.0 registered accounts and is limited to 2. , The result is expressed as a percentage. FIG. 2B shows exemplary embodiments of the distribution of identification information supplied to the identity protocol 110, and these identification information was analyzed, validated and used in the calculation of limiter values.

In some embodiments, multiple forms of identifying information are required to validate the account through the identity protocol 110. For example, the guarantor may have to provide an email address, full name, and two other personally identifiable information, and at least one account to provide at least two entries that match the account. ..

FIG. 3 shows an image of the identity protocol 110 and smart contract data related to the guarantor according to the present invention. Identity protocol 110 encrypts PII from various providers 107 and services. An exemplary CriD smart contract 202 is shown.

Complementing the identity protocol 110 of the guarantor smart contract is the creation of the guarantor smart contract, the registration of third-party identifiers, the processing of KYC, the DID-compliant representation of the entity of the identity protocol 110, and the protocol participants. A client library that provides a set of utilities for interacting with the blockchain portion of the stack, including registering and querying entity relationships.

Early stage registration is possible through a set of authorized clients that interface with both the warranty smart contract and the external identification provider 107. This process will later be exposed through a standard authentication channel, providing an option for protocol adopters to integrate the registration features specific to Identity Protocol 110 into regular account services.

FIG. 2 shows an image of the connection between the guarantor information and the provider 107 according to the present invention. In the illustrated embodiment, the DID provider 107 is directly connected to the identity protocol 110 and the OAuth provider 107 is connected to the DID provider 107.

In some embodiments, as one of many measures against parties attempting to use the system for money laundering operations, various “Know” when registering government-issued personally identifiable information and / or identification cards. Measures such as "your Customer" (KYC) can be used.

FIG. 5 shows the processing of PII information according to the present invention. FIG. 5 shows the flow associated with identity registration supplied by a third party and the PII and validation process. According to the DID specification, all PIIs can be stored off the chain.

Identity Protocol 110 requires the process to send an authentication token to the email address provided. This token is then presented to the guarantor to verify the email address, a DID entity is created on the blockchain, and the PII data is encrypted with the newly generated private key and stored off the chain. ..

Registration of a protocol participation platform (eg, service market) is required before the guarantor can be involved in the guarantee activity. The guarantor has the ability to register the service platform through both the management application and the authorized platform itself. The registration flow is very simple with standard token-based authentication and system API calls.

FIG. 2E shows the interrelationship representation of the subsystems of Identity Protocol 110 according to the present invention.

FIG. 3A shows a flowchart 300A of how to handle entity guarantees and rewards or penalties. The following paragraphs describe methods and related processes according to one embodiment of the invention with reference to FIG. 3A in detail.

The guarantor is connected to the credit evaluation program 109 to determine if any previous interaction or involvement between the guarantor and the entity has occurred. This is used to ensure that the guarantor had a previous relationship with the entity to be guaranteed. If the guarantor had no previous interaction with the entity, the guarantor would be denied the ability to guarantee the entity.

If this guarantor had an involvement with that entity, this guarantor will have a given or guarantor-specific stake value for future involvement between that entity and a third party. Alternatively, the guarantor value can be applied to that entity. In some embodiments, the entity must verify its intent to be involved in economic activity in order to allow the occurrence of staking / guarantee. Once the stake value is determined, this stake is placed in escrow while the entity is involved in economic activity.

When at least one economic event occurs, and after the outcome of the economic event with a third party has been registered (eg, a review), the credit evaluation program 109 has a positive economic event outcome or Determine if it is negative. If the event outcome is negative, the stake is a given value based on the amount of stake, the entity, the outcome of the economic event, and various other factors determined by the credit valuation program 109. Is slashed to. If the outcome of the event is positive, the credit evaluation program 109 grants the guarantor a reward calculated based on the various factors of the entity, the outcome, the status of the guarantor, and the stake. ..

In addition, it involves the process by which the guarantor requires the ability to stake on a particular entity. The guarantor's credit information is reviewed to determine if the guarantor can guarantee the entity in question. If this guarantor can guarantee the entity, the guarantor's reserve is analyzed to ensure that the amount of assets is sufficient to guarantee the entity. In some embodiments where the guarantor has insufficient assets, the guarantor may purchase additional assets or transfer the assets to the platform. The asset is placed in escrow and the guarantor awaits interaction between the entity and the third party (or counterparty). This interaction is analyzed at completion to determine the outcome of the event.

The event registration protocol 112 functions as a cryptographically verifiable event registration system and plays an important role in establishing the process authenticity of the entity of the identity protocol 110. In this role, the event registration protocol serves as the source of the reward grant / slash protocol determination algorithm. These interactions are necessary for the event registration protocol to determine the ability of an individual or organization to guarantee the party seeking credit evaluation.

In some embodiments, the event registration protocol 112 is a decentralized database of economic activity, and each entry is hashed to the event index of identity protocol 110 to establish the integrity of the entry data. Registration of the event registration protocol includes standardized involvement, a history of outcomes, and details of the assurance activities of the entities of Identity Protocol 110. The event registration protocol is a permitted service, and write access is restricted to protocol-approved integrators.

The subsystem of event registration protocol 112 acts as a subscribed data source, and the client has the ability to register updates in event registration. This is useful for systems that are strongly dependent on the timing of events, for example when multiple activities are interdependent or linked.

Since the guarantee part of the smart contract regarding the truth in engagement with the entity relies on the event registration of the event registration protocol 112, write access is provided with permission and proxied via the service API. Restricting access to protocol-approved integrators ensures fair enforcement directive compliance and protects against the use of loopholes in the reward system due to tampering with the history of engagement with entities.

In determination step 302, event registration protocol 112 determines if the guarantor has any previous involvement with the entity. If this guarantor has no involvement with that entity, the registration protocol will stop the process (step 304). If the guarantor had a previous involvement with the entity, registration protocol 112 allows the guarantor to continue the process of guaranteeing for events by the entity (step 306).

After the guarantor calls the credit evaluation program 109, the platform specified in the call must communicate with the registration protocol 112, which escrows the reward specified by the platform from the reserve and is negative. Set the recipient of the ending. However, in some embodiments, defaults on this platform can be configured to be compensated by the platform, for example in the case of peer-to-peer credit evaluation. Reward and stake values are accessible by Credit Evaluation Program 109 and the parties.

In some embodiments, the interaction must be within a particular time frame from the determination step. In some embodiments, the event registration protocol 112 needs to receive confirmation that the entity is or is about to participate in economic activity (step 308).

In some embodiments, the guarantor is granted the ability to adjust values, quantities, currencies, etc. for the guarantee activity (stake). In some embodiments, the factors associated with the warranty are pre-determined by the market or prior to activating the warranty activity.

In step 310, the event registration protocol 112 places the guarantor's amount or data in an escrow or secure location while the involvement is active. This is to keep digital assets safe and secure while the relationship is active. In some embodiments, the reward is placed in an escrow or a safe place.

In step 312, the event registration protocol 112 receives the registration of an economic event between the guarantor and the entity of interest for which the guarantor intends or wishes to give the guarantee. The event may have occurred before or is currently occurring. In some embodiments, the event registration protocol 112 provides a previous event between the guarantor and the entity.

In determination step 314, the event registration protocol 112 handles the ending of the event between the third party and the entity. This process is for determining whether the event was positive or negative. The positive or negative of an event can be recorded in various ways or processes, depending on the platform or system used to record the interaction between the third party and the entity. (Step 313). The event occurred within a predetermined period of time by the guarantor supporting the entity. In some embodiments, the event occurs after the guarantor backs up the entity. In additional embodiments, the reward must be processed before the event occurs. If the ending of the event is positive (yes branch, go to step 318), the limiter of the event registration protocol 112 is applied to the reward. If the ending of the event is negative (no branch, proceed to step 316), the event registration protocol 112 returns the reward to the platform.

In certain embodiments, the entries are as follows: nonces are used to protect against double entries; tts are issued by a time certificate authority, ANSI ASC X. of the event. A reliable time stamp of the 995 standard; platform is the address of the protocol that integrates the platform on which the event occurred; outcome is a bitfield that encodes information about the outcome of the event. As a minimum requirement, a) the first four are set to 0b0000 to 0b1010 to represent a scaled result score from 0 to 10 as a conclusion about involvement, where 5 is neutral. Yes, less than 5 is negative, greater than 5 is positive, b) The fifth bit is whether the client paid for the goods or services, as in the case of peer-to-peer events, etc. Set to 0 or 1 to specify whether the end of the event was challenged-note that this field is extensible to include platform-specific information; reason. Is a bitfield that represents the categories of causes for which negative (less than 5) results are defined and expanded as protocol adoption increases; vouchers, if present, are guarantee entities. Witnesses is a list of at least three randomly selected dispute resolution arbitrator options offered to integrators who do not have their own internal process for dispute resolution. is there.

In step 316, the event registration protocol 112 returns the reward to the platform where the outcome of the event is determined to be negative. In some embodiments, negative reviews or ratings can be challenged (Fig. 3B). When the reward is returned to the platform, the guarantor's stake is slashed based on the value of the reward amount. In some embodiments, the guarantor's limiter value is applied to the returned reward.

In step 318, the event registration protocol 112 processes the reward. The reward is adjusted based on the limiter value calculated by Identity Protocol 110. Once the reward has been processed and adjusted by the limiter value associated with the guarantor, the modified reward value is served on the guarantor (step 322).

In some embodiments, the outcome of the event is processed within a set time period after the entity's feedback has been submitted. In additional embodiments, feedback snapshots are retained throughout the processing phase.

Once the reward has been processed and adjusted by the limiter value associated with the guarantor, the modified reward value is served on the guarantor (step 322).

FIG. 3E shows a flowchart 300E of a method for proving the creditworthiness of an entity involved in borrowing in the computing environment of FIG. 1 according to an embodiment of the present invention. The illustrated embodiment represents an additional environment in which the system can be implemented. The system can be implemented in a number of interactions between people and entities.

The illustrated embodiment relates to providing a loan and demonstrating the likelihood that a person or entity will repay the loan. In the illustrated embodiment, the lender releases the funds to the borrower and the guarantor demonstrates the borrower's ability to repay the loan (step 306). The collateral is placed in escrow based on the platform design (step 310). In some embodiments, the platform maintains collateral. In additional embodiments, the third party maintains the collateral. The funds are released to the borrower (step 312) and the event registration protocol 112 monitors the loan to determine if it has been repaid or is being repaid. Loan repayments may be made within a given period of time, at a fixed rate on a particular date or time, or to various other milestones that may result from the repayment of the loan. You may depend on it. If the repayment of the loan is not completed (step 316), the collateral is served on the lender. In some embodiments, a portion of the collateral is returned to the guarantor based on the design of the platform and a predetermined agreement between the platform and the guarantor. When the loan is repaid within the requirements, the guarantor receives a payment in addition to the collateral (step 318). The above payments are based on the certifier, the entity, the loan, the loan requirements and the additional factors agreed between the participating parties.

FIG. 3B shows a flowchart 300B of a method for handling dispute resolution. The following paragraphs describe methods and related processes according to one embodiment of the invention with reference to FIG. 3B in detail.

In some embodiments, the event registration protocol 112 is accessible to platforms that do not have payment processing support, such as Craigslist® or Gumtree®, and is a “network” to the event registration protocol 112. Dedicated applications and services are provided that allow "outside" event registration. In these "off-network" embodiments, there are additional requirements that must be achieved in order to reward or stake digital assets. In the illustrated embodiment, an economic event (350) occurs between the producer, the consumer, and the guarantor, who guarantees his or her digital assets with respect to the outcome of this event. Prove a positive solution to an economic event. In some embodiments, each of the guarantor, producer, and consumer must undergo the procedure performed by Identity Protocol 110. In this embodiment, the guarantee payment is the responsibility of the producer unless the consumer does not meet the financial obligations of the transaction, and if the consumer does not meet the financial obligations of the transaction. The reward is deducted from the consumer's escrow. Producers, consumers, and guarantors each place a given amount of digital assets in escrow (step 352). In some embodiments, these values may all be substantially identical or may be based on limiter values calculated by Identity Protocol 110. After the economic event (step 350) has occurred, the event registration protocol 112 determines whether the outcome of the event was positive or negative (determination step 354). This outcome is determined by the party rating the event (eg, consumer, producer, third party) (353).

If the outcome of the event is positive, at least one witness will verify the outcome of the event (step 356). A witness is an individual or entity who has witnessed at least part of an economic event. In some embodiments, the outcome of each event is signed by a majority of three randomly selected "witnesses." To participate as a witness, the entity must be registered with at least one DID identity and at least one OAuth identity.

If a witness is found to exhibit an unacceptable pattern of behavior, the deposit will be slashed and the witness will lose witness privileges for a period of time (eg, one year). If necessary, witnesses are required to participate in a dispute resolution process, in which the trading parties present their own cases and witnesses vote based on these presented cases. In some embodiments, the outcome is determined by a majority vote of witnesses. Upon reaching the end, the witness receives payment for his participation in the arbitration or consultation process. In some embodiments, the maximum possible payment must be placed in escrow by both parties before the credit valuation can be initiated.

In some embodiments, witnesses are randomly selected based on a witness random selection algorithm. The witness random selection algorithm incorporates a weighting system that increases the likelihood of selection based on the witness limiter calculation performed by the identity protocol 110.

Witnesses are the neutral parties to the economic event brought in and testify on the subject matter associated with the economic event or review the evidence or testimony provided by the parties. In some embodiments, the witness is a member of the platform or an employee of the platform. In some embodiments, witnesses are motivated to participate in the program through compensation for Event Registration Protocol 112 for approval and conflict resolution arbitration. In one embodiment, compensation for witnesses is fixed to approval / arbitration, follows the same terms as compensation, and is the responsibility of the parties involved. In additional embodiments, the compensation for the witness is proportional to the witness and various factors associated with the economic event, and the responsibility for paying the compensation to the witness is determined by the participating parties.

If the outcome of the economic event is not positive, witnesses are used to arbitrate the conflict and reach a resolution (step 358). In some embodiments, the arbitration is carried out through a dedicated application and / or web interface that includes Q & A session capabilities provided by a third party, with each party having a product or situation photo or other. Present your case using supporting evidence such as related material. If the arbitration determines that a positive outcome has been reached at the economic event, it is determined whether the consumer has paid for the economic event (determination step 376). If the consumer pays for an economic event, both sides pay a relative guarantor fee (step 378). If the consumer does not pay the guarantor, but it is determined that the other side or a third party has paid, the consumer pays the guarantor (step). 374). As a result, the producer is required to pay all witness fees (step 372). If the arbitration does not determine that the positive outcome of the economic event has been reached, the producer will also be liable for the payment for the witness's participation in the arbitration. In this situation, the guarantor's digital assets are served on the system (step 370).

In some embodiments where there are three witnesses, both parties have the option of requesting more rigorously verified additional witnesses in even increments to avoid a draw scenario during arbitration. .. To request additional witnesses, a fee based on the Event Registration Protocol 112 will be levied on the requesting party, and to avoid abuse of this system, the maximum number of additional witnesses will be 7 people. It has been decided.

In additional embodiments, examination procedures are provided to make expert witnesses available for more accurate dispute resolution in cases where specialized knowledge is required. There is.

In some embodiments, the credit evaluation program 109 is subject to RMA and "cooling-off" regulations regarding the return or refund of goods in a particular jurisdiction, and the protocol implementer has expired the required "cooling-off" period. You can delay the notification of the event until you do. Delaying the result results in the stakes of all parties being locked in the system during the period of the delay.

FIG. 3C shows a flowchart 300C of a method for processing a bid by a guarantor competing for the maximum number of slots for bidders per event. The following paragraphs describe methods and related processes according to one embodiment of the invention with reference to FIG. 3B in detail.

In determination step 330, the event registration protocol 112 determines whether the maximum number of guarantors has been reached. In some circumstances, a particular entity or market may only allow a certain number of guarantors to guarantee an entity. If the number of guarantors exceeds this preset maximum number, event registration protocol 112 activates the process of determining which guarantor is entitled to guarantee the entity. To do. If the event registration protocol 112 determines that the number of guarantors has reached more than the maximum number (yes branch, proceed to step 332), the event registration protocol 112 bids from each guarantor. Request. If the event registration protocol 112 determines that the number of guarantors has reached less than the maximum number (no branch, proceed to step 334), the event registration protocol 112 terminates the event by these guarantors. To process.

In step 332, the event registration protocol 112 requests a bid from each guarantor. Bids include any prescribed action that must be received from the guarantor. In some embodiments, this predetermined act may be a monetary bid, in which case a predetermined number of guarantors who bid the highest amount are entitled to guarantee the entity. In some embodiments, the guarantor may have to bid a predetermined value to guarantee the entity. Various different types of bidding processes can be carried out by the credit evaluation program 109, the market, or the guarantor.

In step 334, event registration protocol 112 confer the ability to guarantee the entity to a given or selected guarantor. A guarantor within a particular market and a given entity are involved in the guarantee activity via the event registration protocol 112. In some embodiments, the guarantor is notified that he or she is involved in a guarantee activity with the entity.

FIG. 3D shows a block diagram showing a computing environment according to another embodiment of the present invention. The following paragraphs describe methods and related processes according to one embodiment of the invention with reference to FIG. 10 in detail. FIG. 10 shows a modified computing environment, where the CreV smart contract 502 is integrated into the environment.

FIG. 12 shows a flowchart 400 of the method of token protocol 114 according to the present invention. The following paragraphs describe methods and related processes according to one embodiment of the invention with reference to FIG. 12 in detail.

As a means of meeting both incentive and cost requirements, token protocol 114 implements a token application process that rewards or stakes based on the outcome of an event. Token protocol 114 identifies when the event is complete (step 402) and identifies the participating parties. This event can be a rating, loan repayment, or any other act "backed" by the guarantor or certifier.

Token Protocol 114 identifies the parties participating in the event and assesses whether the parties have additional digital assets that apply to the transaction. In some embodiments, the platform may have platform-specific incentive programs (eg, loyalty points, discount coupons, etc.) and the parties may apply these incentive programs to payments. You can hope. Token Protocol 114 applies these additional digital assets to payments by "color coding" the digital assets (step 404). Platform-specific rewards are implemented by extending the token's smart contract implementation by mapping a unique identifier to the token number, which is color-coded for each purpose.

In some embodiments, tokens are stakes and locked during warranty and dispute resolution, distributed or slashed as a result of warranty termination, and witness settlement in off-network event registration and dispute resolution protocols. Is the unit of. To implement this wide range of utilities, the token protocol 114 further extends the base token using a special escrow feature.

In one embodiment, the smart contract defines a function for platform registration by the owner of the smart contract and a platform modifier that limits the ability to color code rewards for allowed and registered platforms. Token protocol 114 then processes payments with applied data, information, or incentives (step 406).

FIG. 5B shows a block diagram showing a computing environment according to another embodiment of the present invention.

The set of smart contracts and services, including the staking protocol 116, spans the functional domain of the protocol and therefore requires an additional level of consideration regarding the security implications of these designs. The staking protocol 116 is implemented as an authorized service, with the ultimate guarantor interfacing with the service via a protocol participation platform or an off-network credit rating feature of the system. Communication with the distributed web service of staking protocol 116 uses TLS, the system implements an internal CA for the main service endpoint, extends to a standard CA for the ultimate guarantor, and API. Use JSON Web Token for level session authentication.

The guarantor action requires the guarantor to initiate the sequence by communicating with the staking protocol 116 by a SHA-3 ECDSA message signed by the guarantor's private key, and includes a secure timestamp. After this time stamp, the protocol integration platform approves the guarantee with a similar call to the staking protocol.

All smart contract calls associated with the assurance system are marshalled through a distributed service interface, and the actual call requires a private key delegate or proxy-signed message to interact with the smart contract. ..

Program 109's key management implements cryptographic key management standards, incorporating procedural protocols, including multisig encryption, and storage on DDB-certified hardware security modules.

The staking protocol 116 is, but not limited to, subject to the following conditions: Only entities with a proven transaction history with the other party can participate; the guarantor's stake is escrowed in the system wallet during the event. And tied to this system wallet, that is, the guarantor may not guarantee multiple times at the same time at the same event or at other events using the same staking protocol; the staking protocol rewards also Placed in escrow from the protocol integrator reserve. If the reserves submitted for the active event are inadequate, the protocol integrator will need to raise more tokens until the minimum reserves are met. The maximum number of guarantors and maximum stake amount per event can be set by the integrated platform. In some embodiments, the guarantor needs to bid through various metrics or actions or replace other guarantors.

These specifications provide flexibility for protocol integrators and provide the means necessary to balance the value of credit evaluation program 109 with the cost of protocol participation.

Limiting guarantees to entities with a proven transaction history effectively increases economic costs beyond the potential value generated by any activity, a "click farm" This is a measure taken in combination with the identity protocol 110 limiter as insurance against class abuse.

As outlined above, the system gives implementors flexibility in staking protocol 116 by allowing implementers to configure both the maximum number of guarantors and the limit on the amount of money an entity can stake. provide. By doing so, you can strike a good balance between risk and reward incentives for specific platform requirements.

For example, the platform may wish to implement competition between guarantors with the intention of encouraging stronger signaling of trust in the other party. In such cases, the implementer can set the maximum number of guarantors per event to five, but does not set an upper limit on the amount of stakes. Doing so creates a competitive environment in which participants compete for a limited number of guarantor slots by increasing their intended stakes, thus making the other party more credible. It motivates you to think deeply.

Limiting the number of guarantors is for those who are willing to take the utmost risk to the credibility of the other party, as opposed to the overly widespread distribution of rewards among the group of guarantors. On the other hand, it has proved to be particularly useful in that it guarantees rewards that are worth the risk.

The staking protocol 116 is designed to allow maximum flexibility on the part of the protocol integrator. The payout rate can be dynamically configured by the integrator at the time of guarantee, based on per event. This approach is more than a fixed reward system because it allows integrators to keep their payments within gross margins that are tailored to the market price of the staking protocol and optimize the cost utility function. Is also desirable. This function takes the form:

u (C) = ΔPC

Where u is the additional benefit from the integration of the protocols and ΔP is the benefit from, for example, increased platform involvement and reduced costs associated with reduced defaults, RMAs, and disputes. The rate of return increase, C is the total cost of participation in terms of expenditure per transaction, which can be calculated by the following equation:

C = ΣC _txn

C = max {Λ, C _txn } + Σ ^{3 + av} w _j + Σ s _v

Where λ is the maximum guarantee made up of the protocol integrator, κ is the guaranteed staking protocol amount, and τ is the staking protocol acquisition cost at _{the time of guarantee τ i.} , P is the payment rate for the guarantee i, which is limited by the guarantor's reward limiter l. It is important to consider that the guarantor's participation is motivated by the guarantee of rewards, so setting p too low has the negative consequence of insufficient motivation for participation. Ultimately, the total utility of the protocol will be reduced.

In one embodiment, the reward for credit valuation of peer-to-peer transactions is managed by the same cost utility function as above, but the cost equation is extended as follows to account for witness payments:

Where i is the guarantor's index for the vendor (v) side of the transaction, Λ is the maximum payment limiter, w is the witness that can increase by α, and s is. An expert added by the vendor. In this case, _{both p and l of C txn} are configured by the vendor. CreS dynamically imposes a Λ cap on total compensation payments as a limiting measure to protect the network from fraudulent actors who may attempt to abuse the protocol for money laundering purposes. This value is derived as one sample standard deviation from the estimated average over the last 12 months of a random sample of total market compensation payments (p) and is calculated as follows:

A smart contract is a program that can manage relationships between two or more parties by executing and applying the conditions embedded in the code. As a result, smart contracts are primarily associated with distributed ledger networks. These networks allow smart contracts to escrow digital assets and data on behalf of other parties, thereby facilitating the execution of verifiable state-conditional value transfers. If smart contracts work as intended, consensus algorithm execution reduces operational errors, prevents malicious intervention, and eliminates problems related to natural language (and human judgment) ambiguity. It is possible to do. This is a transaction inherent in traditional smart contract processes, including the costs of manual labor, the high legal costs that can impede the use of the judicial system, and the potential unpredictability of court decisions. It comes from the desire to minimize costs.

Staking Protocol 116 proposes that the market utilize split smart contracts for commercial transactions. Split contracts are partially feasible or feasible agreements in both natural language and smart contract code, thereby combining the strengths of their respective media. Natural language and code can refer to the same obligations, but on the other hand, it is possible for each medium to cover a particular part of the smart contract.

At the macro level, markets can embed their existing conditions and services into smart contract code via hashes. By analogy, the blockchain protocol requires the guarantor to attach a hash of the network structure to every transaction to indicate that they agree to comply with the terms. Within a smart contract, the market can also include pointers to external sources where conditions and conditions are described. Along with the token color coding, the split contract forms part of the governance and customization procedures that Program 109 aims to bring to the market.

At the micro level, the market can also allow trading parties to use split contacts. This allows the parties not only to specify what they are aiming to achieve through mutual transactions, but also to include other provisions that cannot be encoded. To facilitate this process, the market can create natural language templates for various use cases and map these natural language templates to their corresponding smart contracts. In doing so, the market also allows non-programmer users to enter the transaction with greater reliability. In the event of any bug, attack, or dispute, the prescribed arbitrator may interpret the parties' intent as referring to natural language and resolve the dispute accordingly.

It is no coincidence that Program 109 is building its own platform based on various blockchain protocols. In addition to being significantly more scalable than competitors, the blockchain protocol allows guarantors to embed natural language as metadata in smart contracts. In addition, the blockchain protocol has a built-in arbitration system that can be used by the parties as a default dispute resolution mechanism. These arbitrators are accustomed to interpreting split contracts and can face the pressure from the blockchain protocol community to make decisions in a rational way.

FIG. 6 shows a flowchart of a method for dispute resolution according to the present invention. Dispute resolution is the responsibility of the protocol integrator, but the witness-based dispute resolution feature of Credit Evaluation Program 109 is available as an option for platforms that do not have this capability and as part of peer-to-peer. is there.

In embodiments where witnesses are required, evidence related to the economic event is provided to the witnesses. Such evidence is submitted through a session or consultation involving witnesses, the vendor providing the goods or services, and the client receiving the goods or services. If, during this session or discussion, it is determined that additional witnesses are needed to provide the relevant necessary evidence or information, these additional witnesses will be collected for the session. Or be incorporated into the council. Whether to leave the ending negative or convert it to a positive ending if sufficient evidence is brought in, or if both the client and the vendor do not have further evidence or witnesses. A decision is made about. Based on this decision, the economic event proceeds with its selected flow and the reward or stake is applied to the guarantor's digital assets.

FIG. 7 shows a block diagram 700 of the components of the computing device 109 according to an exemplary embodiment of the present invention. It should be understood that FIG. 1 provides an example of one implementation and does not imply any restrictions on the environment, and different embodiments may be implemented. .. Many changes can be made to the illustrated environment.

The computing environment 700 represents, in many respects, the various computer subsystems of the present invention. Therefore, the following paragraphs describe some parts of the computing environment 700.

The computing device 700 includes a communication fabric 702, which is between a computer processor 704, a memory 706, a persistent storage 708, a communication unit 710, and an input / output (I / O) interface 712. Provide communication. Communication fabric 702 transmits data and / or control information between a processor (such as a microprocessor, communication processor, and network processor), system memory, peripheral devices, and additional hardware components in the system. It can be implemented by any architecture designed for. For example, the communication fabric 702 can be implemented by one or more buses.

The computing device 700 can communicate with other computer subsystems via the network 701. The network 701 may be, for example, a local area network (LAN), a wide area network (WAN) such as the Internet, or a combination of the two, and may include a wired connection, a wireless connection, or a fiber optic connection. In general, the network 701 can be any combination of connections and protocols that support communication between the computing device 700 and other computing devices.

The memory 706 and the persistent storage 708 are computer-readable storage media. In one embodiment, memory 706 includes random access memory (RAM) and cache memory 714. In general, memory 706 may include any suitable volatile or non-volatile computer-readable storage medium.

The memory 706 is stored for execution by one or more of the respective computer processors 704 of the computing device 700 via one or more storages of the memory 706 of the computing device 700. In the illustrated embodiment, the persistent storage 708 includes a magnetic hard disk drive. In place of or in addition to a magnetic hard disk drive, persistent storage 708 can be a solid state hard drive, semiconductor storage device, read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, or It may include any other computer-readable storage medium capable of storing program instructions or digital information.

The medium used by persistent storage 708 may be removable. For example, a removable hard drive can be used for persistent storage 708. Other examples include optical and magnetic disks, thumb drives, and smart cards that are inserted into the drive for transfer to another computer-readable storage medium that is also part of persistent storage 708.

The communication unit 710 in this example provides communication with other data processing systems or devices, including the computing device 700. In this example, the communication unit 710 includes one or more network interface cards. The communication unit 710 can provide communication via the use of one or both of a physical communication link and a wireless communication link.

The I / O interface 712 enables the input and output of data with other devices that can be connected to the computing device 700. For example, the I / O interface 712 can provide connectivity to external devices 716 such as keyboards, keypads, cameras, touch screens, and / or other suitable input devices. The external device 716 may also include portable computer readable storage media such as thumb drives, portable optical or magnetic disks, and memory cards. The software and data used to implement embodiments of the invention, such as control program 420, can be stored on such portable computer readable storage media and is via the I / O interface 712 of the computing device 700. It can be loaded onto the persistent storage 708 of the computing device 700. The software and data used to implement embodiments of the present invention can be stored on such portable computer readable storage media and through the I / O interface 712 of the computing device 700, the computing device. It can be loaded on 700 persistent storage 708. The I / O interface 712 is also connected to the display 718.

The display 718 provides a mechanism for displaying the data to the guarantor, which may be, for example, a computer monitor.

The present invention can be a system, method, and / or computer program product. A computer program product may include a computer readable storage medium having computer readable program instructions for causing a processor to perform aspects of the invention.

The computer-readable storage medium can be a tangible device that can hold and store the instructions used by the instruction execution device. The computer-readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media is portable computer disksets, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory). , Static Random Access Memory (SRAM), Portable Compact Disk Read-Only Memory (CD-ROM), Digital Versatile Disk (DVD), Memory Stick, Floppy Disk, Punch Card with Instructions or Raised Mizouchi Structure Includes mechanically encoded devices and any suitable combination thereof. Computer-readable storage media as used herein are radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (eg, optical pulses through fiber optic cables). Or it should not be interpreted as a temporary signal itself, such as an electrical signal transmitted through a wire.

The computer-readable program instructions described herein can be downloaded from computer-readable storage media to their respective computing / processing devices, or, for example, the Internet, local area networks, wide area networks and / or wireless networks. It can be downloaded to an external computer or external storage device over the network. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives computer-readable program instructions from the network and stores the computer-readable program instructions in a computer-readable storage medium within each computing / processing device. Transfer to do.

Computer-readable program instructions for performing the operations of the present invention include assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or Smalltalk, C ++, etc. It can be source code or an object written in any combination of one or more programming languages, including an object-oriented programming language, and a traditional procedural programming language such as the "C" programming language. Computer-readable program instructions are issued exclusively on the guarantor's computer, partly on the guarantor's computer as a stand-alone software package, partly on the guarantor's computer and partly on the remote computer, or exclusively on the remote computer. It can be executed on the top or on the server. In the latter scenario, the remote computer can connect to the guarantor's computer via any type of network, including local area networks (LANs) or wide area networks (WANs), or (eg, Internet services). It is possible to establish a connection with an external computer (via the Internet using a provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) is for personalizing this electronic circuit for the purpose of performing aspects of the invention. In addition, the computer-readable program instruction can be executed by using the state information of the computer-readable program instruction.

Aspects of the invention are described herein with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the invention. It will be appreciated that each block of the flowchart and / or block diagram, as well as a combination of multiple blocks of the flowchart and / or block diagram, can be implemented by computer-readable program instructions.

The computer-readable program instructions described above can be provided to a general purpose computer, a dedicated computer, or the processor of another programmable data processor to produce a machine, thereby providing the computer processor or other programmable data processor. These instructions executed through generate means for implementing the functions / actions specified within the blocks of the flowchart and / or block diagram. The computer-readable program instructions described above can also be stored on a computer-readable storage medium capable of issuing instructions to a computer, programmable data processor, and / or other device to function in a particular way. The computer-readable storage medium in which the instructions are stored includes manufactured articles that include instructions that implement the functional / operational aspects specified within the blocks of the flowchart and / or block diagram.

Computer-readable program instructions also cause a computer, other programmable data processor, or other device to perform a series of operating steps on a computer, other programmable device, or other device that spawns a computer-implemented process. It is loadable so that instructions executed on a computer, other programmable device, or other device implement the functions / operations specified within the blocks of the flowchart and / or block diagram.

Flowcharts and block diagrams of the drawings show the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the invention. Each block of the flowchart or block diagram can then represent a module, segment, or part of an instruction that contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions described within the block may be performed in a different order than that described in the drawings. For example, two blocks shown in succession may actually be executed at substantially the same time, depending on the associated function, or sometimes the blocks may be executed in reverse order. There is also. Can each block of the block diagram and / or flowchart diagram, and a combination of multiple blocks of the block diagram and / or flowchart diagram be implemented by a dedicated hardware-based system that performs a specified function or operation? Also note that it can be executed by a combination of dedicated hardware and computer instructions.

The present invention ensures that the subject matter described by the term "invention" is covered by the claims filed or the claims that may ultimately be issued after the examination of the patent. It should not be construed as an indication. That is, the term "invention" is used to help the reader gain a general sense that the disclosures herein are believed to be perhaps novel, but the term "invention". This understanding expressed by the use of is tentative and tentative and is subject to change during the process of patent examination as relevant information may develop and the claims may be amended. is there.

Claims (20)

A method of proving the credibility of entities involved in commercial transactions, buying and selling, and lending, using a value staking guarantee mechanism.
The method is
Steps to create an account on a distributed ledger with one or more processors,
A step of associating at least one personally identifiable information data with the account by one or more processors.
A step of assigning a limiter value based on the type of personally identifiable information data associated with the account by one or more processors.
A step of receiving from said account a request to prove the credibility of an entity by one or more processors, wherein said account is at least one documented earlier with said entity. Steps and steps that have involvement or verified ties,
The step of allocating the account by staking into the activity of the entity to prove the credibility or credibility of the entity by one or more processors, the allocation of which is a tokenized asset. At least a portion of the tokenized asset is associated with the account, with steps.
The step of receiving a closing notification regarding a transaction between a third party and the entity by one or more processors.
A step of analyzing said outcome of said involvement by one or more processors.
A first portion of the tokenized asset associated with the account, along with a second portion of the tokenized asset, by one or more processors based on an analysis of the consequences of the involvement. Methods, including steps to adjust. The step of adjusting the first portion of the tokenized asset
Further comprising adjusting the second portion of the tokenized asset based on a limiter value by one or more processors.
The method according to claim 1. Different types of personally identifiable information data each have a predetermined limiter value associated with the different types of personally identifiable information.
The method according to claim 1. Allowed to assign a given number of accounts to said entity for proof,
The method according to claim 1. The method is
Further comprising the step of creating a smart contract function assigned by one or more processors to the first amount of the tokenized asset associated with the account.
The method according to claim 1. The smart contract function is a blockchain-based distributed computing platform.
The method according to claim 4. The analysis of the ending of the entity
Further comprising processing the dispute resolution procedure brought in by the account by one or more processors based on the analysis of the consequences of the involvement.
The method according to claim 1. The method is
Further including the step of receiving a request for payment to the account by one or more processors.
The method according to claim 1. The payment is calculated based on the sum of the first portion of the tokenized asset, the second portion of the tokenized asset, and the deduction.
The method according to claim 7. The personally identifiable information is encrypted by the entity's private key, stored in distributed data storage or database, and hashed to a smart contract account on a cryptographically secure distributed ledger.
The method according to claim 1. The ending of the involvement is processed along the scale to determine the category of the ending.
The method according to claim 1. When the number of accounts exceeds the predetermined number, the account selection protocol is started.
The method according to claim 4. The selection protocol is
Further including receiving bids from their respective accounts by one or more processors,
12. The method of claim 12. A predetermined number of accounts with the highest bids are selected by one or more processors to prove the entity.
13. The method of claim 13. The method is
Further comprising processing the ending by one or more processors to determine whether the ending complies with a set of requirements for eligibility as a valid ending.
The method according to claim 1. A computer program product for certifying a guarantor and handling endings
The computer program product
Includes one or more computer-readable storage media and program instructions stored on the one or more computer-readable storage media.
The program instruction is
Program instructions for associating personally identifiable information with your account,
A program instruction for assigning a limiter value based on the type of personal identification information data associated with the account, and
A program instruction for receiving a request from the account to prove the credibility of an entity, wherein the account has at least one documented previous involvement with or validated with the entity. With program instructions that have a connection
A program instruction for assigning the account by staking to the activity of the entity to prove the credibility or credibility of the entity, the allocation being the first portion of a tokenized asset. The first part of the tokenized asset is associated with the account, with program instructions.
Program instructions to receive the consequences of the involvement between the third party and the entity,
Program instructions for analyzing the rating of the entity by the third party,
Program instructions for coordinating the first portion of the tokenized asset associated with the account, and
A computer program product comprising a program instruction for generating a second portion of the tokenized asset based on an analysis of the consequences of said involvement. The different types of personal identification information data have a predetermined limiter value associated with the different types of personal identification information.
The computer program product according to claim 15. A computer program product that proves the creditworthiness of the entities involved in the activity.
The computer program product
On one or more computer processors, one or more computer-readable storage media, and one or more computer-readable storage media executed by at least one of the one or more processors. Including program instructions stored in
The program instruction is
Program instructions for associating personally identifiable information with your account,
A program instruction for assigning a limiter value based on the type of personal identification information data associated with the account, and
A program instruction for requesting the account to certify an entity, wherein the account has at least one previous involvement or connection with the entity.
A program instruction for assigning the account by staking the entity's involvement with a third party to prove the entity, and the tokenized asset is associated with the staking of the account. With program instructions
Program instructions for reviewing the consequences of said involvement between said third party and said entity,
Program instructions for analyzing the outcome and
A computer program product comprising a program instruction for adjusting the associated tokenized asset based on an analysis of the outcome of the involvement. The different types of personal identification information data have a predetermined limiter value associated with the different types of personal identification information.
The computer system according to claim 18. Allowed to assign a given number of accounts to said entity for proof,
The computer system according to claim 18.

Images