System and method for traversing distributed ledger data structure to generate encrypted verifiable presentation data objects

Abstract

The invention provides a method for traversing a distributed account book data structure based on a block chain / distributed account book to generate an encrypted verifiable demonstration data object. The method may be used as a mechanism for using cryptographically generated verifiable credential data objects in conjunction with cryptographically generated verifiable presentation data objects to verify characteristics of a user or computing process, such as whether the user is a graduate of a particular educational institution, whether the user has a transaction history that ensures that a score is greater than a threshold, and whether the user has a transaction history that ensures that a score is greater than a threshold. Or whether the user has sufficient access credentials to access the controlled resource. Zero knowledge proof is proposed as a mechanism to generate verifiable proof to protect sensitive verifiable credential data objects. The score generation may use a black box machine learning model.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to the field of encrypted data object generation. Specifically, embodiments relate to systems and methods for traversing a distributed ledger data structure to generate encrypted and verifiable presentation data objects. Background Art

[0002] One challenge faced by the credit investigation process of traditional credit institutions is that the user data formats of each platform are not unified, making it difficult to integrate and model. Different data formats require complex cleaning of user data, consuming a large amount of manpower and material resources. In addition, since user data is scattered and stored on each platform (for example, data such as vehicle ownership, property rights, and intellectual property rights), it is difficult for users to directly use all the data because each platform may have permission restrictions that prevent users from using this data in other applications, resulting in users losing control of their own user data.

[0003] For example, the data formats of data from various asset platforms (such as a user's vehicle ownership information and real estate rights) and the user's social identity data (such as educational background, work background, etc.) will be different and it is difficult to merge them to model the user's credit status.

[0004] Some third-party payment platforms have established their own credit systems. Their main data sources are transaction data generated by the platform itself, and there are also some asset and liability data and interpersonal relationship data related to users within the platform service ecosystem, which are used to model and evaluate the credit status of users. However, the scope of application of these systems is relatively limited and it is difficult to be widely applied to more extensive scenarios.

[0005] One potential reason is that the data sources for obtaining user data are limited and cannot comprehensively reflect and represent the user's credit status. Summary of the Invention

[0006] The present invention proposes a blockchain / distributed ledger-based method for traversing a distributed ledger data structure to generate encryptable and verifiable presentation data objects. This method can be used as a mechanism in actual implementation to combine encryptable and verifiable credential (VC) data objects with encryptable and verifiable presentation data objects (VP), and further used to verify characteristics of a user or a computing process, such as whether a user is a graduate of a specific educational institution, whether the user's transaction history guarantees a score higher than a threshold, or whether the user has sufficient access credentials to access a controlled resource.

[0007] A verifiable display data object can be automatically generated or transmitted in response to a verification request message (e.g., an incoming message from a verification device requesting verification). For example, the verification device can be a payment terminal that offers student discounts, or the payment terminal can be configured to modify the user interface flow based on different credit options that may be provided, e.g., if the user's credit score is greater than a specific threshold.

[0008] Alternatively, in addition to serving users, the system can be used to generate verifiable presentation data objects for determining whether a process has sufficient computational process permissions to access virtual controlled resources. In this example, the computational process can have a verifiable credential data object with an access level 5 generated by a certificate authority and generate a verifiable presentation data object when asking for the process's permissions before access.

[0009] The methods described herein provide a computational mechanism that serves as a unified identity management system represented by encrypted data objects, and the generated verifiable proofs can be used to execute transactions such that specific functions can only be accessed by individuals with advanced credentials or permissions. As an applied, non-limiting use case, the data architecture provided herein can be used to evaluate the credit of a user's unified identity and can issue a verifiable credit certificate to the user. This credit certificate can also be used in other systems to provide differentiated services based on the credit level to the user. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The drawings are further illustrated by way of examples. These descriptions and diagrams are for illustrative and helpful understanding purposes only and are not restrictive. Now, by way of example, embodiments are described with reference to the accompanying drawings, in which:

[0011] Figure 1 An example step flowchart of data interaction for generating an encryptable verifiable demonstration data object for demonstration is shown.

[0012] Figure 2 A schematic block diagram of an example service architecture is shown.

[0013] Figure 3A 、 Figure 3B 、 Figure 3C Is an example data message flowchart 300 (across three figures), showing an example service call among three entities (user, issuer, CBDC platform), as a reference for the development of specific product function modules.

[0014] Figure 4 A set of example data sources for a scoring model is shown.

[0015] Figure 5 An example score rating model is shown.

[0016] Figure 6 An actual example is shown where a user attempts to rent a bicycle at a bicycle rental terminal. Detailed implementation

[0017] Examples of specific methods, systems, and devices are described with reference to the accompanying drawings.

[0018] A system is disclosed herein that is configured to generate a unique verifiable credit rating certificate for a user. For example, the system can be configured to model a user's credit rating based on the user's behavior on a digital currency platform.

[0019] With the emergence of "Web3" technology, cryptocurrencies have been extended to a new generation of the Internet based on decentralized networks, blockchain technology, and tokenomics, creating a more distributed and user-driven network environment that improves the transparency and efficiency of financial transactions. Central banks around the world are actively adopting Web3 technology as the basis for the design and development of the next generation of currency, such as central bank digital currency (CBDC). Decentralized identity management technology is also used to empower users to independently hold and manage their own data, eliminating the need for users to store personal data in traditional centralized service databases. Using this technology, users can access corresponding services in different systems through a unified identity. Leveraging Web3 technology and decentralized identity management technology, users can conduct transactions in CBDC using a unified identity and generate financial-related data. This data can be used to evaluate the credit of the user's unified identity, thereby generating and issuing a verifiable credit rating certificate to the user. Such a credit rating certificate is universal in other systems and can provide differentiated services to users based on their credit ratings.

[0020] The traditional credit investigation method of credit reporting agencies has flaws because it requires integrating and modeling user data from various banks, including transaction data, asset and liability data, and data from asset platforms such as vehicle rights, property rights, intellectual property rights, and social identities such as educational background and work background. This data is distributed across different platforms, making it extremely difficult to integrate. Moreover, due to inconsistent data formats, complex data cleaning work is required, consuming a large amount of manpower and material resources. At the same time, all this data is stored on other platforms, making it difficult for users to use it or requiring permission from other service providers to use this data for other services. This results in users losing control of data that originally belongs to them.

[0021] In contrast, the embodiments of the present invention allow users to manage their own password credit rating certificates by themselves, and use the password credit rating certificates generated based on the user's behavior data on their own devices to independently obtain relevant financial services from other service institutions. The technical method described in the present invention provides a more efficient, fair, and personalized credit rating and management system for users, improves the transparency of credit rating determination, and safeguards the user's rights and interests in user data. Users can then directly manage and utilize their credit information using these generated data objects, while providing more accurate and real-time user credit data for financial service institutions, improving the efficiency and quality of financial services.

[0022] The present invention proposes a unified platform that uses unified data objects to enable multiple financial service institutions to conduct system docking and data sharing, improve the collaboration efficiency of different financial service institutions, and make the calculation and management of user credit ratings more direct and convenient. The method provides a distributed ledger / blockchain architecture that provides a platform to aggregate user information from multiple financial institutions and generate data in a unified format to solve the "data island" problem of mutual isolation of user information in different financial institutions. This enables the generation of more comprehensive and objective identity ratings. In some embodiments, the platform can be a blockchain / distributed ledger architecture configured to support one or more central bank digital currencies, such as decentralized data objects.

[0023] In the case of using central bank digital currency data objects, transaction flows and patterns can be tracked and monitored, and holdings accessed using a block explorer tool can be combined to generate a robust snapshot of the financial characteristics of a specific digital wallet (and the user who owns the digital wallet through an agent). As described herein, other signed digital objects can also be maintained locally or on a distributed ledger, and these signed digital objects include, for example, verifiable credentials generated by a university student indicating graduation or enrollment certificates, as well as other fields such as whether the user graduated with honors, the grades of the user at graduation or in individual courses, the course names, the enrollment date, etc.

[0024] Figure 1 According to some embodiments, an example data flow diagram showing data interaction steps for generating encryptable and verifiable demonstration data objects for demonstration is shown. In Figure 1 Figure 100 therein, the method can be divided into three steps.

[0025] In step 102, the data flow starts with the collection and cleaning of user credit investigation-related data, converting various types of personal credit investigation data that are difficult to standardize into a unified data format for subsequent use by the platform. This process requires the platform to provide a unified paradigm definition platform interface and confirm the conversion relationship from business data to platform data one by one.

[0026] In step 104, credit rating calculations are performed using the processed data source and the received data, and a verifiable credential data object representing the calculated rating result is generated and stored on the user's mobile device.

[0027] At 106, in operation, the user can use the user's mobile device as needed to display the rating result to prove their creditworthiness. This proof can use a verifiable display data object generated based on a combination of one or more verifiable credential data objects. The verifiable display data object is generated based on one or more verifiable credential data objects as a zero - knowledge proof authentication, and the user does not need to transmit the underlying one or more verifiable credential data objects to the device for verification.

[0028] Figure 2 It is a block diagram of an example service architecture shown according to some embodiments. In 200, a CBDC platform 202 is provided, which may include one or more smart contracts 204 and accessible transaction records 206. A block explorer data service can be used to query the distributed ledger to obtain information from the CBDC platform 202, such as the ownership of various digital assets, non - fungible tokens representing real - world assets, and process transaction records, such as repayment history, transaction processes, and / or consumption behavior through transaction patterns.

[0029] As Figure 2 shown, the user's smart contract and transaction history are stored on the CBDC platform 202 and can be used as inputs to an offline scoring decision model. The model inputs also include VCs generated by financial product services inside and outside the CBDC platform. The two can be combined for calculation, and the rating result is also published and stored on the user's mobile device in the form of VCs.

[0030] The off - chain asset trusted credential issuance platform 208 can be another data source, configured to generate verifiable credential data objects related to the user's asset ownership and tracked in the user's records. These verifiable credential data objects can include certificates of financial securities ownership, account holdings, land registers that record the ownership of physical objects stored off - chain, etc.

[0031] The verifiable credential data objects can be provided in a unified format, and each data object can be signed by a cryptographic certificate authority associated with each verifiable credential issuer. In some embodiments, the public key of the certificate authority can be used for verification. The verifiable credential data objects are persistently stored on a verifiable credential data object wallet application on the user device and can be confidential / secure data objects that can be transferred from one device to another. The verifiable credential data objects are sensitive information and, in some embodiments, are stored in a trusted execution environment or enclave memory section of the user device, such as a high - security data storage isolated from other data storage.

[0032] One or more smart contracts 204 can access the transaction record 206 to generate an external data output based on the retrieval of on-chain transaction records, define the external data output in a unified format of CBDC (such as VC), and provide an interface for integration with external business entities. The purpose is to convert the external business data traversed in the form of transaction records into a unified format.

[0033] In some embodiments, a credit rating determination engine is configured to generate one or more comprehensive score values based on the on-chain transaction records available to the user by traversing all transactions associated with the public address of the wallet.

[0034] The credit rating determination engine can be implemented in different ways. For example, the credit rating determination engine can be implemented as a data engine that is configured to generate a credit score for the user based on the user's transaction history, and the data engine can operate offline.

[0035] In another variant, the credit rating determination engine is executed by a smart contract that runs on-chain as a state machine and is configured to expose an application programming interface. A data message containing the public wallet address can be used by the credit rating determination engine. The credit rating determination engine automatically traverses the transaction records associated with the public wallet address and generates a verifiable credential data object that is available for a period of time after generation. In this example, the credit rating determination engine includes a generated public / private key pair. The credit rating determination engine exposes the public key and signs the verifiable credential data object with the corresponding private key so that the verifiable credential data object and / or the corresponding generated proof can be verified based on the public key of the smart contract of the credit rating determination engine.

[0036] In a further variant of the smart contract version of the credit rating determination engine, the credit rating method can be encapsulated and implemented as a publicly accessible code circuit that can be easily verified by a third party. The credit rating determination engine in this example can include executable code stored thereon. When executed, the code performs a specific type of pattern or asset test, such as a company's quick ratio, loan-to-value ratio, or a combination thereof. Therefore, in this example, the rating method of the credit rating determination engine can be used for additional verification to meet the needs of verifiers to access and interrogate the publicly accessible code circuit being executed.

[0037] In an alternative variant of the smart contract version of the credit rating determination engine, the credit rating method adopts a "black box" model and the underlying executable code is not accessible to a third party. This is particularly important when the credit rating algorithm itself is a combination of proprietary weights and logic gates. This secrecy of the credit rating algorithm can also prevent a third party from maliciously influencing the algorithm's scoring through intentional transaction activities designed to cause misclassification.

[0038] In a further variant, the "black box" model is a machine learning black box model where the underlying weights and parameters of the scoring method are continuously or periodically iteratively updated to optimize for a specific outcome or parameter. For example, in this variant, the advantage of using a machine learning model is that it is more difficult for a malicious third party to cause the model to misclassify because the model is adjusted in real-time or near real-time based on fraud patterns. In this example, the smart contract is configured to periodically retrieve a dataset of identified unpaid or fraudulent transactions and compare it with different parameters related to the stored digital assets and transaction flows to continuously update the probability distribution representation implemented through the adjustable weights and parameters of the neural network model.

[0039] The issued verifiable credential data object can be stored on the user's mobile device or optionally in a cloud storage backup.

[0040] The computational process for generating the verifiable credential data object can include an issuing authority that generates a signature or encrypts the data object based on a public key / private key architecture, such as a certificate authority server with a public public key for signing the verifiable credential data object.

[0041] In some embodiments, the verifiable credential data object can be stored as a plain text data object with a digital signature. In other embodiments, the verifiable credential data object is an encrypted data object that is signed and encrypted using the corresponding private key so that even if the data object is stolen, it cannot be easily decrypted to obtain the underlying information. In another example, the verifiable credential data object includes a proxy payload that contains a credential pointer object pointing to a secure resource stored on a secure server. Wherein, if the user needs to access the data record, the credential and pointer are still required to access the secure resource on the secure server. All of these variants provide different levels of security for the verifiable credential data object, especially if there is a risk of replay attacks or data breaches in the secure data storage of the verifiable credential data object.

[0042] The verifiable credential data object can be generated using a repeatable process, such as based on a process stored in the records of a third party institution (such as a university, employer, government agency, etc.).

[0043] For financial smart contracts, in another variant embodiment, the verifiable credential data object generation process itself can be publicly presented as a smart contract function accessible through a distributed ledger smart contract execution framework, such as a smart contract for generating verifiable credential data objects with specialized functions. Any party can call the contract by providing the user wallet public key and pay the relevant computing execution fees required for the generation protocol (e.g., the "gas" fee for blockchain operation). The advantage of using this variant is that if the verifiable credential data object generation process can be publicly audited in the publicly accessible execution code of the smart contract, the method used to generate the verifiable credential data object can gain broader trust.

[0044] In this example, the smart contract function then provides a "self-service" mechanism where the user can request at any time on the user or user device to generate a verifiable credential data object corresponding to the user's transaction record to produce a storable token. This token can be stored on the user's device and used, for example, in the offline transaction and verification processes described herein. The advantage of this "self-service" is particularly prominent if the computational verification and credit score generation based on the user's transaction history require long time and high computational volume. The user's device can periodically call the function to receive the verifiable credential data object token after a period of time (e.g., 2 - 3 days when the blockchain network load is low and transactions are queued for execution). Thus, the verifiable credential data object can be stored locally to generate the demonstration proof as the response data message described herein.

[0045] Figure 3A , Figure 3B , Figure 3C Figure 300 (across three figures) is an example data message flow diagram, showing example service calls made among three entities (user, issuer, CBDC platform), which can be used as a reference for the development of specific product function modules.

[0046] As shown in FIGS. 300A, 300B, and 300C, the data message flow is designed to generate verifiable credentials as described above. At the end of one or more asynchronous generation processes, the user's wallet has multiple different verifiable credentials. These can include the following example indications: Xiaoming owns real estate #1001050, Xiaoming has 150,000 RMB in his account, Xiaoming graduated from Tsinghua University in 2006 with a GPA of 3.61 and with honors, Xiaoming owns vehicle registration 3P20MACANZA, Xiaoming owns public wallet abcde111100, and Xiaoming was born in Hong Kong, China on January 1, 1990.

[0047] Each of these primary verifiable credential data objects is generated by a different source, and the verifiable credential data object can include actual field values. These field values have sensitive information, such as his date of birth, his ID number, his student number, etc. Derived credential data objects can also be generated using other primary information, such as a credit score generated by an off-chain verification service of credit scoring company A or a smart contract for verification of credit scoring company B. As described herein, credit scoring company B can use a black box model to implement its proprietary scoring algorithm, and then use the certificate authority system of credit scoring company B to approve the algorithm. In this example, the black box model of credit scoring company B may be a different variant of an adaptive model that continuously traverses unpaid records and updates model parameters.

[0048] The verifiable credential data object should only be stored on the user device when user authorization is obtained and the user requests presentation. For example, when a verifier device (such as the terminal device of the verifier) requests verification, the user device is configured to use zero-knowledge proof objects to merge or otherwise combine or transform the verifiable credential data object to address the verification challenge and generate a zero-knowledge proof, which is transmitted back to the terminal device of the verifier. The advantage of using zero-knowledge proof objects is that the underlying verifiable credentials do not need to be transmitted over an insecure transport protocol or a publicly accessible and potentially untrusted network, thus greatly limiting the ability to use the verifiable credential data object for replay attacks.

[0049] On the other hand, the zero-knowledge proof object representing the verifiable data object can be generated once, and the zero-knowledge proof protocol can generate a verifiable representation of the data object to meet the very specific requests of the verifier device. For example, the verifier device can be satisfied as long as the credit score is greater than 500. And in the method proposed herein, it is not necessary to provide the actual credit score, and the generated verifiable proof only needs to indicate whether the credit score is greater than 500. This allows for better prevention of information leakage because the verifiable representation data object cannot be replayed and cannot be reverse-engineered to obtain the verifiable credential or the underlying value.

[0050] Figure 4 Show a set of example data sources for a scoring model according to some embodiments.

[0051] As described in 400, in addition to the verifiable credentials generated by different organizations, derived verifiable credential data objects can also be generated as proxies for transformation or generation, such as a snapshot based on a user's historical transaction records, to generate a specific score. The derived verifiable credential data object acts as a proxy for the credit score, and the required computational cost for generation is high. However, once generated, it can be used for a period of time before a new data object needs to be generated.

[0052] In some embodiments, the user's device or mobile application is configured to automatically invoke the process based on a refresh period built into the token, such that new verified or newly generated tokens are generated based on the user's transaction information within the period.

[0053] Figure 400 shows a set of example data sources that can be used to provide source data for a user self-managed identity credit model. In some embodiments, these can be based on CBDC transfer flows, such as all data related to a user (e.g., the user's wallet) within a CBDC platform, including but not limited to data directly generated on the CBDC platform and data input from external sources. When invoked, the credit model data structure automatically traverses the on-chain transaction records to obtain the user's transaction data on the CBDC platform, which refers to the transaction data generated by the user within the CBDC platform.

[0054] The CBDC platform can obtain the user's decentralized identity credentials on the CBDC platform, where the decentralized identity credentials refer to the decentralized self-managed identity credentials generated and self-managed by the user on the CBDC platform (e.g., locally saved / stored on the user's device).

[0055] When the user invokes the process, such as by calling a data message through an API, the process begins to obtain the user's credit and risk data from the CBDC platform or a third-party credit and risk system associated with the CBDC platform. The user's credit and risk data refers to the user's credit history and risk performance in financial activities, including but not limited to information obtained from the CBDC platform or a third-party platform associated with the CBDC platform. This information can include activity information such as loan information, credit card information, employment and income information, asset and liability status, legal records (e.g., whether the user has defaulted on a loan and not repaid it, which may result in a legal lawsuit stored in the form of a record on the chain), etc.

[0056] The process is configured to obtain the compliance assessment information of the user's assets on the CBDC platform and the risk information of the transactions generated on the platform. These two pieces of information can be generated by the asset assessment model and the risk assessment model within the CBDC platform, or by a third-party recognized model integrated by the CBDC platform. By extracting the identity information credentials issued by the issuing institutions recognized by the CBDC platform and recorded on the platform, the centralized identity information of the user on the CBDC platform can be obtained, including but not limited to the following information: ID card, driver's license, business license, degree, or diplomatic identity, etc.

[0057] The process may also include obtaining the user's asset information on the CBDC platform, where the asset information refers to any form of asset owned by the user within the CBDC platform that can generate economic benefits. The financial service information data can be retrieved for the user on the CBDC platform. Financial services refer to the services provided by the CBDC platform or other financial service institutions that utilize the CBDC platform to enable users to use and manage their own assets. These services include, but are not limited to: deposit services, loan services, investment services, insurance services, etc.

[0058] The technology of the present invention utilizes the valuable and available data provided on the CBDC platform to model and analyze the user's financial behavior, thereby determining the user's identity rating. And the user can independently manage their identity rating certificate and use these certificates to independently obtain corresponding financial services from other service providers.

[0059] Figure 5 is an example scoring model according to some embodiments. The illustrated credit scoring model 500 can be implemented by a computing circuit or computer module that executes a set of computer instructions based on user input. As described herein, the scoring model can be used to generate derived verifiable credential data objects, which are derived from combinations of various other characteristics that themselves may (but need not) be stored and accessed through the generated verifiable credential data objects. In the example shown in 500, the attributes of credit can include aspects of identity, spending power, assets, and contractual ability, and these attributes can be used to generate weighted scores.

[0060] The input data format of the credit rating model can be standardized and cleaned into a blockchain-readable format for subsequent use and calculation. The input data format includes verifiable credentials (VCs) in the W3C standard. The VCs of different dimensions or business entities should be preset on the CBDC platform in a format that complies with the VC standard and includes the relevant business fields. The blockchain transaction records can be obtained through block explorer data processing or can also include other data formats recognizable by the blockchain, such as NFTs.

[0061] The credit scoring model calculates the weights of different dimensions of credit data using the model source data to obtain the final credit score. Non-limiting examples of assigning weights to different input data dimensions can include: identity proof, based on diverse and trustworthy identity proofs such as ID cards, driver's licenses, government-issued documents, etc., which can contribute to a significant improvement in credit scoring.

[0062] The behavior and capabilities of consumers can be measured through the following proxies: Transaction risk monitoring, the process of which includes conducting security scans on blockchain transactions to prevent financial crimes. For example, blockchain technologies such as anti-financial crime scans and transaction monitoring, or machine learning, are used to trace the sources and destinations of CBDC transaction funds. Funds that may flow into financial crime accounts may have a significant impact on credit ratings.

[0063] Other sources of consumer behavior and capability data can include transaction history, where ongoing transaction activities are considered indicators of higher stability; employment and income verification, where employment and income verification can significantly improve credit ratings; assets and liabilities, where providing diverse asset proofs and lower liabilities can greatly improve credit ratings; CBDC account balances; ownership of digital assets, such as NFTs corresponding to digital twins of real estate rights on the blockchain; equivalent valuations of financial products; liability records, including the use of loans and credit contracts on the CBDC platform.

[0064] It is also possible to obtain stored performance records such as credit products associated with the CBDC account (transaction records between users and bank lending service contracts). Assuming that the CBDC institution launches CBDC-related credit financial products, a good contract performance rate and a low debt ratio help to determine that the user has a good credit level; and existing off-chain credit records, such as repayment records of traditional loans and credit cards. If loan or credit card repayments are not made on time, it may have a negative impact on the credit rating.

[0065] The credit rating for CBDC implementation is obtained by extracting the required source data and performing calculations through the centralized service of the CBDC institution with the user's authorization. Then, the CBDC institution issues the resulting credit rating as a credit rating voucher. The weights assigned to each dimension are not elaborated here as they should be defined by a specific product design organization when implementing a specific product or dynamically adjusted during the model iteration process. Each weight can be configured as an adjustable parameter, and the system can be configured to utilize one or more deep learning methods to adjust according to the feedback data set related to the received corpus of positive payment or negative non-payment interaction data. By allowing the weights to float and iteratively adjust, the system automatically adapts to new patterns of payment or non-payment behavior, which is an improvement over static models. Since real-world payment / non-payment data is used, the weighting method is closer to the ground truth. Different model types and parameters can be used, and in some embodiments, more recent transactions have higher weights to intentionally bias the system towards considering short-term or recent behavioral changes.

[0066] In addition, considering the rules of the scoring model, a method combining rule matching and machine learning can be adopted. For example, using deep learning algorithms, a suitable learning model is constructed using a large amount of user credit data sets for credit rating prediction. The advantages of this method include: regularly retraining the credit model using recent data sets to effectively identify new risks; for individual users, as credit data accumulates, the scoring results can be inferred and adjusted in real time.

[0067] In operation, this method can be used in different actual verification scenarios, where different aspects of the user's verification response change the interaction method with the verifier's terminal. For example, according to the user's credit score, different interactions and different user interface models can be invoked, or different interface paths can be modified to allow enhanced credit options, or conversely, reduce rental options or require a deposit.

[0068] In these examples, the user has generated a set of verifiable credential data objects that are stored in a secure wallet or secure memory area of their device. These verifiable credential data objects can be generated from time to time and issued by various institutions. In this example, the user also has one or more credit score-derived verifiable credential data objects that have been generated and signed by a signing authority, indicating the overall score level associated with the user.

[0069] The first example is "buy now pay later / credit payment", where when the user attempts to make a payment or attempt to purchase an item or service, an optional verification request is encountered on the terminal device acting as a verification device. As part of the purchase transaction data message, the terminal device can automatically send a verification request message to the user device, and the user device can sequentially generate a response message data object when generating a response message, and the response message data object includes one or more verifiable display data objects as payloads. The verifiable display data objects are generated using zero-knowledge proofs to indicate that the user's credit rating is, for example, greater than a specific threshold. In this example, the terminal device sends multiple different requests together, each request for a different credit threshold (e.g., >500, >600, >700, >750).

[0070] The user's device generates verifiable demonstration data objects in response to each query, and these devices together generate a zero-knowledge proof circuit and corresponding secret numbers such that the user's device generates a zero-knowledge proof for each threshold that has been met. In some embodiments, the response proof also includes a verifiable digest based on the signature data object such that the zero-knowledge proof can be reverse-verified according to the underlying certificate authority used to generate the verifiable credential data objects.

[0071] The terminal device verifies whether the user's credit score is greater than a specific threshold, and then can automatically invoke a set of bifurcated user interface interactions through the user interface controller, where now the user is provided with a combined loan option for partial purchase. Thus, in this example, a verifiable presentation data object can be used instead of a specific credit rating to evaluate whether the user is eligible for the buy-now-pay-later option, as well as to determine the credit limit, interest rate, and terms in the credit payment scenario. Different credit limits, interest rates, and terms in the credit payment scenario can be provided according to the user's credit rating threshold.

[0072] Since zero-knowledge proof authentication is used as a proxy for each threshold, the user's private information is provided only to the extent required to obtain the proof, without revealing other irrelevant information, such as the actual credit score number of the user. The less information is leaked, the more difficult it is for malicious users to impersonate the user.

[0073] In another example, the system can be used for services such as renting real estate, cars, etc. Similarly, the credit rating is used to evaluate the probability of the user's performance, which may affect the deposit and rental terms. The credit rating also affects whether the user is eligible for loan deferment, as well as the relevant interest rate and terms.

[0074] Based on the verification, the user may be eligible to obtain certain expedited services through the terminal interface verification. For example, during the verification process, based on the identity proof and credit rating, support can be provided to expedite or waive the submission of proof materials for process-related services (such as visa applications). Similarly, for insurance, the identity proof and credit rating can result in the waiver of some material requirements during the insurance application process. For insurance policies affected by the credit record, the credit rating can also be configured to directly affect the insurance premium and coverage. In the example of microloans, the credit rating can directly determine the loan amount and term of the user.

[0075] The technology of the present invention utilizes the standardized data provided by the CBDC platform, which not only improves the efficiency of financial services but also enhances the collaborative ability between different financial service systems. Since all financial service institutions can operate on the same platform, seamless docking and data sharing between systems can be achieved, greatly improving the collaborative efficiency of financial services. At the same time, the credit rating and management of users are more convenient and direct, further enhancing the overall efficiency of financial services and the user experience.

[0076] Figure 6 An actual example is shown in which a user attempts to rent a bicycle at a bicycle rental terminal according to some embodiments.

[0077] The user owns a user mobile device 602, i.e., the user's smart phone, which has an online banking mobile application that establishes a secure data store in a secure storage area 604 for storing verifiable credential data objects. The secure area is the user's digital wallet and can be used to store the data payloads of verifiable credential data objects.

[0078] The online banking mobile application can be configured to transmit a verifiable presentation payload, which can also be provided as part of a payment transaction, and the online banking mobile application can transmit the payload via various communication protocols (e.g., near field communication).

[0079] The user's online banking application has registered a decentralized identifier with a verifiable credential data object generator 606, which is a computational process that can be interacted with via an application programming interface. The user is a student at a local high school and requests a digital credential via the verifiable credential data object generator 606, and the school's data flow for the student uses its signature engine to cryptographically generate a verifiable credential data object as a payload data file for the student to store on the user mobile device 602 in the secure area 604. The payload data file can include, but is not limited to, specific information about the student's enrollment, such as course load, the semester the student is in, the student's unique identification symbol, whether the student is a boarding or day student, etc.

[0080] The user can also use the verifiable credential data object generator 606 to generate one or more verifiable credential data objects related to the student's bank account history via Web 2.0 banking with the user's financial institution, and can generate a verifiable credential data object via a data message request on an online banking interface triggered by a request from the user via a user interface form, which indicates that the user has an account balance of 10,000 yuan in the user's savings account at the requested timestamp.

[0081] The user also has a digital wallet associated with the online banking application, through which the user can track CBDC or other digital currencies or digital ownership, such as non-fungible tokens, etc. The digital wallet is represented by a public address, and the private key is managed by the online banking application. The user has a CBDC transaction history, and in this non-limiting example, the CBDC is represented by an ERC-20 token on the Ethereum network, and the transaction flow can be tracked as the user uses the digital wallet to pay bills, send money to friends, buy groceries, etc. Thus, the digital wallet serves as a repository of the transaction flow and can be publicly accessed using a block explorer if the digital wallet address is known. However, traversing and generating a block explorer is computationally complex and may be slow.

[0082] The user's online banking application is configured to regularly generate expiration-derived tokens using the verifiable credential data object generator 606, which are derived by the verifiable credential data object generator 606 based on one or more metrics related to the user's transaction flow and wallet holdings. These expiration-derived tokens are special tokens that generate a specific numerical value or score as a proxy for the user's creditworthiness. The user's online banking application regularly generates these tokens and stores them on the device as scheduled, refreshing the token generation one week before the monthly expiration, which can be done automatically in some embodiments.

[0083] In this example, the credit rating model and backend mechanism are proprietary models based on dynamic machine learning, where the credit rating method is designed as a black box to prevent malicious third parties. Thus, as a further non-limiting example, the verifiable credential data object generator 606 can be a smart contract that can store an encrypted machine learning model iteratively updated based on a periodic traversal of token-based credit default transaction records, and the encrypted machine learning model includes parameters that modify the weights of the contribution of specific categories of transaction patterns to the credit score. The initial weights can be based on, for example, baseline initial conditions such as 30% payment frequency, 30% holdings, and 40% loan-to-asset ratio, and over time, these weight values can be configured to float based on the optimization of actual transactions and default behaviors.

[0084] For example, the encrypted machine learning model can periodically traverse the blockchain to identify the latest set of defaults and update the weights of the neural network to optimize the loss function. The model weights themselves can be encrypted so that only the verifiable credential data object generator 606 can decrypt the values to use the model as a true black box. This can be achieved by having the smart contract implementing the verifiable credential data object generator 606 generate and store a key pair, where the public key of the key pair is used to encrypt the weights, but the private key is not available, and the verifiable credential data object generator 606 can only access the private key to process incoming wallet addresses to generate credit scores.

[0085] Thus, the user generates these tokens and saves them in the secure storage area 604 for use, and saves multiple verifiable credential tokens. This can be done at an earlier time because the generation may take time to process (so performing the operation monthly can reduce the overall computational burden and the overall gas fees spent in the generation process).

[0086] In operation, a user approaches a bike rental terminal 608 to rent a bike. The terminal is designed to request a verifiable VP token as part of a login data message flow, and the terminal includes a terminal interface controlled by a backend user interface controller that controls which user interface pages and options are presented to the user. The terminal requests a verifiable presentation token data object so that the bike rental terminal 608 can automatically determine whether to request a security deposit from the user and, if so, how much.

[0087] The user mobile device 602 receives a verifiable presentation token request, and the user device 602 and the bike rental terminal 608 exchange zero-knowledge protocol messages to establish a trusted setup for a one-time communication channel. For example, a zero-knowledge protocol such as the zk-SNARKs protocol can be used to establish logical conditions such as credit score > 500 = TRUE. The mobile device 602 processes the verifiable presentation token request and uses verifiable credential tokens stored in a secure area (individually or in combination) to generate a proof response proof in the form of a response to the verifiable presentation token. The bike rental terminal / kiosk 608 can be configured to request multiple different verifiable presentation tokens simultaneously. For example, there may be a discount program for students.

[0088] The user's mobile device 602 encapsulates a response message that shows, via zero-knowledge proof, that the user is a student (without revealing the student's ID number) and that the user's credit score is greater than 600. The bike rental terminal 608 also sends a request to prove that the user's credit score is greater than 700, but the user's score is not high enough, so the request is ignored. The submission is also sent with a digital signature proof from the underlying source of the verifiable credentials so that the bike rental terminal 608 can independently verify whether the signature is from the user's school or the credit score generation source.

[0089] The bike rental terminal 608 modifies the user interface flow based on the received response. This can be done by establishing branch / fork user interface behavior conditioned on the verifiable presentation token response. In this example, the user is eligible for a student discount, so the user's total cost is modified. Since the user's credit score is of medium strength, the terminal user interface controller 610 is also configured to request a smaller partial deposit instead of the full bike deposit. If the user's credit score is higher, the user may not need to provide a deposit at all. The terminal user interface controller 610 invokes the deposit processing user interface flow as part of the payment flow.

[0090] Then, the user provides funds to pay for the bicycle rental. The bicycle is provided to the user through the automatic unlocking of the bicycle rental terminal 608, and the bicycle return tracking engine 612 tracks the user's return time and whether the user has returned the bicycle. In an example scenario, the user loses the bicycle and forfeits part of the deposit. However, the bicycle rental company incurs a loss. The bicycle rental company automatically posts the blockchain record of the user's arrears associated with the user's public wallet address to the blockchain through the automatic configuration of the bicycle rental terminal kiosk 608.

[0091] In a further embodiment, when generating a future credit score, the VC generator 606 can reduce similar users represented by the experience of similar patterns in the transaction records on the blockchain transaction record by iteratively updating the machine learning model stored on the VC generator 606, thereby reducing the tendency to allow users similar to students to provide only a partial deposit.

[0092] In some embodiments, negative records also affect the user's ability to refresh the credit score after the due date, either canceling the ability completely or significantly affecting future scores (e.g., the model penalizes by a score of -400 for 90 days). When the bicycle is found and returned late, the bicycle rental terminal 608 can be configured to automatically update the negative transaction record so that it no longer affects the user's credit score, and since the system can be a "self-service" mechanism, the user can proactively request a new credit score data object to be saved on the user's mobile device. One benefit of the method proposed herein is that once the record is updated by the bicycle rental terminal 608, the user can call the verifiable credential data object generator 606 through the user device to self-provide the credit score on demand without cooperating with any credit scoring agencies, etc.

[0093] To provide a thorough understanding of the exemplary embodiments described herein, numerous specific details are set forth. However, those of ordinary skill in the art should understand that the embodiments described herein can be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the embodiments described herein. Additionally, this description should not be regarded as limiting the scope of the embodiments described herein in any way, but rather as merely describing the implementation of the various example embodiments described herein.

[0094] For example, the protocol for generating a verifiable display data object can be issuer-agnostic, and in some embodiments, the verifiable display data object acceptable for a particular transaction can include a degree of flexibility (e.g., it doesn't matter which financial institution as long as it is one of the major financial institutions), or different combinations of digital assets or credit scores can be used as trigger conditions. For example, a newcomer may have a large amount of assets but no well-established transaction history. Thus, adopting a flexible approach will provide a useful mechanism for more accurately and automatically assessing credit risk.

[0095] The terms "connected" or "coupled to" can include direct coupling (where two coupled elements are in contact with each other) and indirect coupling (where at least one additional element is located between the two elements).

[0096] Although the embodiments have been described in detail, it should be understood that various changes, substitutions, and alterations can be made herein without departing from the scope. Additionally, the scope of the present application is not limited to the specific embodiments of the processes, machines, manufactures, compositions of matter, means, methods, and steps described in the specification.

[0097] Those of ordinary skill in the art will readily understand from this disclosure that processes, machines, manufactures, compositions of matter, devices, methods, or steps that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein can be utilized, whether currently existing or developed later. Accordingly, the appended claims are intended to embrace such processes, machines, manufactures, compositions of matter, devices, methods, or steps within their scope.

[0098] The various operations of the methods described herein can be performed, at least in part, by one or more processors temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute a processor-implemented engine for performing one or more of the operations or functions described herein.

[0099] Similarly, the methods described herein can be at least partially implemented by a processor, where a particular processor is an example of hardware. For example, at least some of the operations of the method can be performed by one or more processors or processor-implemented engines. Additionally, one or more processors can also be operable to support the performance of the relevant operations in a "cloud computing" environment or as a "software as a service" (SaaS) operation. For example, at least some of the operations can be performed by a group of computers (as an example of a machine including processors), and these operations can be accessed via a network (e.g., the Internet) via one or more appropriate interfaces (e.g., an application programming interface (API)).

[0100] The performance of certain operations can be distributed among processors, deployed not only within a single machine but also across multiple machines. In some embodiments, a processor or a processor-implemented engine can be located in a single geographical location (e.g., within a home environment, an office environment, or a server farm). In other embodiments, a processor or a processor-implemented engine can be distributed across multiple geographical locations.

[0101] Although the subject matter has been described in terms of specific embodiments, various modifications and changes can be made to these embodiments without departing from the broader scope of the embodiments herein. The detailed description should not be regarded as limiting, and the scope of the various embodiments is defined only by the appended claims and the full scope of equivalents given by those claims. Additionally, the terms "step 1", "step 2", "step 3", or similar terms do not denote a limitation on the order of steps in this document, but rather represent a possible order that exists in the embodiments. Further, the terms "a", "an", and "plurality" do not denote a limitation on quantity in this document, but rather represent the presence of at least one of the items described.

Claims

1. A computer-implemented method for interacting with a blockchain node to traverse a distributed ledger data structure to generate a verifiable credential token data object that can be used for credit scoring, comprising: Receiving a request data message from a user at a blockchain node to interact with a verifiable credential generation computing process configured to generate a decentralized, self-managed identity certificate for a public key wallet address corresponding to the user, the verifiable credential generation computing process being combined with a signing authority private key stored thereon, the signing authority private key being inaccessible to any external process used to sign the decentralized, self-managed identity certificate; traversing the distributed ledger data structure by executing the verifiable credential generation computation process of a block explorer process to identify a number of data objects stored on the distributed ledger data structure corresponding to the public key wallet address and a number of confirmed transactions corresponding to the public key wallet address; After determining that the number of the data objects stored on the distributed ledger data structure corresponding to the public key wallet address is greater than a predefined threshold and a continuous pattern in a plurality of the confirmed transactions corresponding to the public key wallet address is greater than a predetermined duration, generating a verifiable credential token data object by the verifiable credential generation computation process data object, the verifiable credential token data object having at least an expiration time field digitally signed using the signing authority private key; as well as The signed verifiable credential token data object is output for storage, the signed verifiable credential token data object is configured for downstream electronic transmission to a verifier computing system as a component of a verifiable demonstration data object, the verifier computing system is configured to verify the verifiable credential token data object based on the expiration time field and the signing authority public key corresponding to the signing authority private key, and upon successful verification of the verifiable demonstration data object, the expiration time field and the signing authority public key, the verifier computing system is configured to allow access to a controlled resource.

2. The method according to claim 1, characterized in that The verifiable credential generation computing process is instantiated as an interactive smart contract data object persisted on a blockchain virtual machine, the blockchain virtual machine providing a decentralized virtual environment for consistently executing state-changing code in a distributed ledger data structure stored on a corresponding blockchain node, the interactive smart contract data object automatically causing a block traversal of transaction records associated with the public key wallet address, generating a signed verifiable credential token data object, the verifiable credential token data object being locally stored on a local memory of a portable computing device associated with a user, the portable computing device including one or more electronic transmitters that transmit the signed verifiable credential token data object to the validator computing system during a physical transaction.

3. The method according to claim 1, characterized in that The signed verifiable credential token data object also includes one or more data fields, each of which represents one or more data values ​​associated with the number of data objects or multiple confirmed transactions, and wherein the validator computing system is also configured to modify access to controlled resources based on one or more of the data values.

4. The method according to claim 3, characterized in that The modifying of access to the controlled resource based on one or more data values ​​includes the validator computing system automatically adjusting one or more values ​​associated with parameters of the proposed electronic transaction, the parameters including at least one of a loan amount, an interest rate, and eligibility for a modified service option.

5. The method according to claim 3, characterized in that Modifying access to a controlled resource based on one or more data values ​​includes the validator computing system automatically injecting additional user interface paths into a user interface stream data structure to control presentation of user interface screens on the user interface coupled to the validator computing system.

6. The method according to claim 3, characterized in that The modifying access to the controlled resource based on one or more data values ​​includes the validator computing system automatically removing additional user interface paths from a user interface flow data structure that controls presentation of the user interface screens on a user interface coupled to the validator computing system.

7. The method according to claim 1, characterized in that The verifier computing system is configured to perform offline verification by storing a signing authority public key of the verifiable credential generation computing process on a local data store of the verifier computing system.

8. The system according to claim 2, characterized in that The validator computing system is configured to perform online verification by retrieving a signature authority public key from the smart contract data object by querying a public address persistently stored by the smart contract data object.

9. The method according to claim 8, characterized in that The transaction request data message from the user for connecting to the validator computing system includes the verifiable credential token data object and pointing data to the public address where the smart contract data object is persisted.

10. The method according to claim 3, characterized in that The verifiable credential generating computing process is configured to privately store or access a risk model used to generate one or more data values ​​associated with a number of data objects or a number of confirmed transactions.

11. A computer-implemented system adapted to interact with a blockchain node to traverse a distributed ledger data structure for generating a verifiable credential token data object that can be used for credit scoring, comprising: one or more processors; and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon, the instructions being executable by the one or more processors to perform the method of any one of claims 1 to 10. 12 . A non-transitory computer-readable storage medium configured with instructions executable by one or more processors to cause the one or more processors to perform the method of claim 1 .

Images