CN114429348A - Method and device for generating pledge sheet - Google Patents

Method and device for generating pledge sheet Download PDF

Info

Publication number
CN114429348A
CN114429348A CN202210036233.1A CN202210036233A CN114429348A CN 114429348 A CN114429348 A CN 114429348A CN 202210036233 A CN202210036233 A CN 202210036233A CN 114429348 A CN114429348 A CN 114429348A
Authority
CN
China
Prior art keywords
pledge
user
asset
target asset
target
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210036233.1A
Other languages
Chinese (zh)
Inventor
赵金明
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Pross Technology Chongqing Co ltd
Original Assignee
Pross Technology Chongqing Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Pross Technology Chongqing Co ltd filed Critical Pross Technology Chongqing Co ltd
Priority to CN202210036233.1A priority Critical patent/CN114429348A/en
Publication of CN114429348A publication Critical patent/CN114429348A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/03—Credit; Loans; Processing thereof

Abstract

The application provides a method and a device for generating a pledge list, which are applied to a service system; the service system accesses a block chain; the business system maintains a pledge asset pool of the user; wherein the pledge asset pool comprises a plurality of assets used as pledges; the method comprises the following steps: receiving a pledge request which is initiated by a user and aims at target assets to be pledged; according to a preset pledge verification rule, performing pledge verification on the target asset; if the pledge verification of the target asset passes, adding the target asset to a pledge asset pool of the user and generating a pledge sheet corresponding to the target asset; and storing the generated association relationship between the pledge and the pledge asset pool of the user, and storing the pledge in the block chain for evidence.

Description

Method and device for generating pledge sheet
Technical Field
The present application relates to the field of block chain technology, and in particular, to a method and an apparatus for generating a pledge.
Background
The traditional mortgage loan mode has higher requirement on the credit of the borrower, inflexible standard for identifying effective assets and lower credit line, and small and medium-sized enterprises such as dealers, wholesalers and retailers in a supply chain usually have low credit rating, and most of owned assets are stock-class mobile assets which are difficult to identify actual value, such as: raw materials, work in process, finished products, etc., such enterprises often face the problem of difficult capital turnover.
In the supply chain financing scenario, since the mobile assets may be involved in the production process, a dynamic pledge may be used to avoid affecting production. The dynamic pledge, which may be referred to as a floating pledge, refers to a business in which an enterprise or an individual may apply for credit to a financial service organization using legally owned mobile property, right of delivery, or the like as a pledge.
In order to ensure that each flow in the dynamic pledge business has legal effectiveness and complete evidence storage, when a user applies for loan or the pledge of the dynamic pledge changes, a corresponding pledge list needs to be generated, and the flows of approval, signing and the like are carried out.
Disclosure of Invention
The application provides a method for generating a pledge list, which is applied to a service system; the service system accesses a block chain; the business system maintains a pledge asset pool of the user; wherein the pledge asset pool comprises a plurality of assets used as pledges; the method comprises the following steps:
receiving a pledge request which is initiated by a user and aims at target assets to be pledged;
according to a preset pledge verification rule, performing pledge verification on the target asset;
if the pledge verification of the target asset passes, adding the target asset to a pledge asset pool of the user and generating a pledge sheet corresponding to the target asset;
and storing the generated association relationship between the pledge sheet and the pledge asset pool of the user, and storing the pledge sheet in the block chain for evidence.
Optionally, the method further includes:
receiving a redemption request initiated by the user for the target asset;
performing redemption verification on the target asset according to preset redemption verification rules;
removing the target asset from the user's pool of pledges assets and generating a pledge change record corresponding to the target asset if redemption verification of the target asset passes;
and storing the generated association relationship between the pledge change record and the pledge sheet, and storing the pledge change record in the block chain for evidence.
Optionally, the pledge validation rule includes one or more of the following:
the asset type of the target asset is matched with a preset admittance asset type;
the remaining effective duration of the target asset is greater than a preset effective duration threshold;
matching the buyer information of the target asset with preset buyer information;
and the seller information of the target asset is matched with preset seller information.
Optionally, the service system further maintains the loaned amount and the repayment amount of the user; the redemption validation rules include:
the first difference value of the user is greater than the second difference value of the user; wherein the first difference is a difference between a total asset worth value of all assets in the user's pledge asset pool and an asset worth value of the target asset; the second difference is a difference between the user's loaned amount and the user's repayment amount.
Optionally, the service system also maintains the credit line of the user; the method further comprises the following steps:
if the pledge of the target asset passes the verification, the credit line of the user is improved according to the asset value of the target asset;
receiving a loan request initiated by the user; wherein the loan request includes an amount to be loaned;
in response to the fact that the sum of the amount to be loaned and a second difference value of the user does not exceed the credit granting amount of the user, adding the amount of loaned of the user according to the amount to be loaned, and generating a financing order corresponding to the amount to be loaned;
and storing the generated association relation between the financing order and the credit line of the user.
Optionally, the method further includes:
receiving a repayment request initiated by the user; wherein the repayment request comprises an amount to be repayed;
in response to determining that the amount to be paid does not exceed the second difference of the user, increasing the amount paid by the user according to the amount to be paid, and generating a payment record corresponding to the amount to be paid;
and storing the generated association relationship between the repayment record and the financing order of the user.
Optionally, the storing the pledge or the pledge change record in the block chain includes:
based on a user private key in the user digital certificate, performing digital signature on the generated pledge or the pledge change record to obtain a pledge or a pledge change record carrying the digital signature of the user;
storing the pledge list or pledge change record carrying the digital signature of the user in the block chain; and enabling the node equipment in the block chain to generate a corresponding pledge contract based on the pledge list or pledge change record carrying the digital signature of the user, and storing the generated pledge contract in the block chain.
Optionally, the business system further maintains an asset set to which assets included in the pledge asset pool belong; assets with different asset attribute information belong to different asset sets; the method further comprises the following steps:
if the pledge of the target asset passes verification, determining an asset set to which the target asset belongs according to the asset attribute information of the target asset;
and storing the association relationship between the asset set to which the target asset belongs and the pledge asset pool of the user and the association relationship between the asset set to which the target asset belongs and the pledge.
The application also provides a device for generating the pledge, which is applied to a service system; the service system accesses a block chain; the business system maintains a pledge asset pool of the user; wherein the pledge asset pool comprises a plurality of assets used as pledges; the device comprises:
the system comprises a receiving unit, a judging unit and a processing unit, wherein the receiving unit is used for receiving a pledge request which is initiated by a user and aims at target assets to be pledged;
the verification unit is used for verifying the pledge of the target asset according to a preset pledge verification rule;
the generation unit is used for adding the target asset to a pledge asset pool of the user and generating a pledge sheet corresponding to the target asset if the pledge verification of the target asset passes;
and the storage unit is used for storing the generated association relationship between the pledge sheet and the pledge asset pool of the user and storing the pledge sheet in the block chain for evidence.
The application also provides an electronic device, which comprises a communication interface, a processor, a memory and a bus, wherein the communication interface, the processor and the memory are mutually connected through the bus;
the memory stores machine-readable instructions, and the processor executes the method by calling the machine-readable instructions.
The present application also provides a machine-readable storage medium having stored thereon machine-readable instructions which, when invoked and executed by a processor, implement the above-described method.
Through the embodiment, on one hand, in response to receiving a pledge request which is initiated by a user and aims at a target asset to be pledged, a business system can perform pledge verification on the target asset according to a preset pledge verification rule, and can add the target asset to a pledge asset pool of the user when pledge verification passes, generate a pledge sheet corresponding to the target asset, and store the generated pledge sheet and the association relationship of the pledge asset pool of the user; therefore, the business system can automatically generate a corresponding pledge sheet in response to receiving a loan request initiated by a user, thereby improving the efficiency of dynamic pledges.
On the other hand, because the data stored in the block chain has the characteristics of non-falsification, whole-course traceability, public transparency, collective maintenance and the like, if the pledge of the target asset passes verification, the business system can store the generated pledge and the association relationship of the pledge pool of the user, and can store the pledge in the block chain, thereby ensuring the complete storage of the business process of the dynamic pledge and further ensuring the legal effectiveness of the pledge.
Drawings
FIG. 1 is a diagram illustrating an exemplary embodiment of a network environment for a HyperLegendr Fabric-based blockchain system;
FIG. 2 is a diagram illustrating a transaction execution flow in a HyperLegendre Fabric-based blockchain system, according to an exemplary embodiment;
FIG. 3 is a flow diagram illustrating a method of generating a pledget in accordance with an exemplary embodiment;
FIG. 4 is a hardware block diagram of an electronic device in which an apparatus for generating a pledget resides in accordance with an exemplary embodiment;
fig. 5 is a block diagram of an apparatus for generating a pledget, according to an exemplary embodiment.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.
In order to make those skilled in the art better understand the technical solutions in the embodiments of the present disclosure, the related technologies related to the embodiments of the present disclosure will be briefly described below.
The traditional mortgage loan method has higher requirement on the credit of the borrower, inflexible standard for identifying effective assets and lower credit granting amount, and small and medium-sized enterprises such as dealers, wholesalers and retailers in the supply chain generally have low credit rating, and most of owned assets are stock type mobile assets which are difficult to identify actual value, such as: raw materials, work in process, finished products, etc., such enterprises often face the problem of difficult capital turnover.
In the supply chain financing scenario, since the mobile assets may be involved in the production process, a dynamic pledge may be used to avoid affecting production. The dynamic pledge, which may be referred to as a floating pledge, refers to a business in which an enterprise or an individual may apply for credit to a financial service organization using legally owned mobile property, right of delivery, or the like as a pledge.
In the related art, in order to ensure that each flow in the dynamic pledge service has legal effectiveness and complete deposit, when a user applies for a loan or when a pledge of a dynamic pledge changes, a corresponding pledge list needs to be generated, and the flows of approval, sign-up, and the like are required. Specifically, when a user applies for a loan from a financial service institution, the user can firstly select the assets which want to be pledged at this time, namely pledges to be pledged, and generate corresponding pledges; further, the financial service institution may evaluate the validity, actual value, etc. of the pledge, and may also compare the actual value of the pledge with the remaining credit amount of the user; after the approval is passed, a pledge contract corresponding to the pledge sheet can be generated, the pledge can be signed in an off-line or on-line signing mode, and the money can be released to the user after the signing is finished. Subsequently, every time the pledge needs to change (for example, redeeming a part of pledge, or replacing pledges), the user needs to provide a pledge list again according to the change of pledges, and perform the procedures of approval and contract.
It can be seen that in the above illustrated embodiment, when the user applies for a loan or the pledge of the dynamic pledge changes, manual operations of multiple parties may be involved, which usually take a long time to complete, resulting in a decrease in the efficiency of the dynamic pledge.
In view of this, the present specification aims to provide a technical solution that can improve the business efficiency of the dynamic pledge while ensuring that the business process of the dynamic pledge is completely certified.
When the method is realized, the service system can receive a pledge request which is initiated by a user and aims at the target asset to be pledged; furthermore, the business system can carry out pledge verification on the target asset according to a preset pledge verification rule; if the pledge verification of the target asset passes, adding the target asset to a pledge asset pool of the user and generating a pledge sheet corresponding to the target asset; further, the business system may store the generated association relationship between the pledge and the pledge asset pool of the user, and store the pledge in the block chain for evidence. Wherein the user's pool of pledges assets can be maintained by the business system; the pledge asset pool can comprise a plurality of assets used as pledges; the service system may access a blockchain.
Therefore, in the technical solution in this specification, on one hand, in response to receiving a pledge request initiated by a user for a target asset to be pledged, a business system may perform pledge verification on the target asset according to a preset pledge verification rule, and when the pledge verification passes, add the target asset to a pledge asset pool of the user, generate a pledge form corresponding to the target asset, and store an association relationship between the generated pledge form and the pledge asset pool of the user; therefore, the business system can automatically generate a corresponding pledge sheet in response to receiving a loan request initiated by a user, thereby improving the efficiency of dynamic pledges.
On the other hand, because the data stored in the block chain has the characteristics of non-falsification, whole-course traceability, public transparency, collective maintenance and the like, if the verification of the pledge of the target asset passes, the business system can store the generated association relationship between the pledge and the pledge asset pool of the user, and can store the pledge in the block chain, thereby ensuring the complete storage of the business process of the dynamic pledge and further ensuring the legal effectiveness of the automatically generated pledge.
It should be noted that, regarding the block chain accessed by the service system, no limitation is made in this specification, and a person skilled in the art can flexibly select the block chain according to needs. In order to make those skilled in the art better understand the technical solution in the present specification, the following describes the technical solution in the present specification by taking an example that the blockchain may specifically include a blockchain system based on Hyperhedger Fabric.
The related art of the block chain will be briefly described below.
Block chains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). In addition, there may be various combinations of the above, such as a combination of a private chain and a federation chain, a combination of a federation chain and a public chain, and so on.
Among them, the most decentralized is the public chain. A party joining the public chain (which may also be referred to as a node in the blockchain) may read the data records on the chain, participate in transactions, compete for accounting rights for new blocks, etc. Moreover, each node can freely join or leave the network and perform related operations.
Private chains are the opposite, with the network's write rights controlled by an organization or organization and the data read rights specified by the organization. Briefly, a private chain can be viewed as a weakly centralized system with strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for use within a particular establishment.
The federation chain is between the public chain and the private chain, and partial decentralization can be realized. Each node in a federation chain typically has a physical organization or organization corresponding to it; the nodes are authorized to join the network and form a benefit-related alliance, and the operation of the block chain is maintained together.
In a blockchain, a node is a logical communication entity; the different types of block chain nodes can run on the same physical server or different physical servers.
For the alliance chain, the blockchain system based on HyperLegendr Fabric is an implementation manner of the alliance chain system.
In the HyperLegend Fabric-based blockchain system, the following three types of blockchain points can be mainly included: a client; an Orderer (ordering service) node; and, Peer nodes. The client can establish connection with a certain Peer node or a certain sequencing service node so as to access a corresponding block chain network through the Peer node or the sequencing service node; the client may submit a transaction proposal (transaction proposal) to a Peer node as an Endorser node, and after obtaining an endorsement result of the endorsement node for the transaction proposal, may construct a corresponding transaction, and submit the transaction to the ordering service node.
In practical application, the client may also establish a connection with a plurality of Peer nodes, so as to access the corresponding blockchain network through each Peer node.
The sequencing service node can receive the transaction submitted by the client, sequence the unpacked transaction, generate a corresponding block, and broadcast the block to the Peer node. It should be noted that ordering the broadcast of the service node can ensure that the nodes on the same chain receive the same data and the received data have the same logical order.
Peer nodes can be classified into Committer (accounting) nodes, endorsement nodes and Leader (master) nodes according to the assumed functions.
Specifically, the accounting node is responsible for maintaining a block chain ledger (legger) and a chain code (chaincode, which may also be called an intelligent contract); the accounting node may periodically acquire the blocks generated by the sequencing service node and attest to the blocks in the blockchain after validating transactions in the blocks. The endorsement node can simulate and execute the transaction proposal and sign the simulation execution result of the transaction proposal so as to complete the endorsement for the transaction proposal. The master node may communicate with the sequencing service node to obtain the latest chunks from the sequencing service node so that these chunks may be synchronized between Peer nodes. It should be noted that all Peer nodes can be used as accounting nodes. That is, for a certain Peer node, the Peer node can be used as both an endorsement node and an accounting node; alternatively, the Peer node may act as both the master node and the accounting node.
In HyperLegger Fabric based blockchain systems, the blockchain points can be generally differentiated based on organization. That is, the participants of the HyperLegendr Fabric-based blockchain system may be organizations.
Specifically, there may be Peer nodes (specifically, there may be multiple accounting nodes, multiple endorsement nodes, and one master node) in each organization that undertake different functions; different organizations may share the same ranking service node or the same ranking service node cluster.
In practice, the organization may be a company, a business, or an association in the real world.
The data storage structure of the blockchain system based on HyperLegendr Fabric can be generally designed into a multi-account book system. To isolate data from different blockchain ledgers, the Hyperridge Fabric-based blockchain system may be logically divided into different channels (channels). The channel can be defined by a block chain account book, a chain code, an organization and a sequencing service node; each channel can be provided with a set of completely independent block chain accounts and a set of completely independent chain codes; different channels can share the same sequencing service node; the same organization can add different channels through different Peer nodes in the organization; each transaction is performed independently in one of the channels. Therefore, in the HyperLegger Fabric-based blockchain system, one channel can be considered as one blockchain. That is, the HyperLegger Fabric-based blockchain system may include a plurality of blockchains.
It should be noted that Peer nodes joining in the same channel may maintain the same blockchain ledger, and cannot access blockchain ledgers maintained by Peer nodes joining in other channels. The same Peer node can be added into different channels; the Peer node may maintain blockchain accounts corresponding to each channel, but the Peer node maintains data isolation between the blockchain accounts.
Referring to fig. 1, fig. 1 is a schematic diagram of a network environment of a Hyperhedger Fabric-based blockchain system according to an exemplary embodiment. As shown in fig. 1, in the blockchain system based on the HyperLegger Fabric, three organizations, namely organization 1, organization 2 and organization 3, may be included, and two channels, namely channel A and channel B, may also be included.
Wherein, the tissue 1 and the tissue 2 belong to the channel A, and the tissue 2 and the tissue 3 belong to the channel B; each organization can be provided with Peer nodes such as a host node, an endorsement node, a billing node and the like, and can also be provided with a client connected with the endorsement node; the Peer nodes in each organization and the sequencing service node shared by all the organizations form a block chain system based on HyperLegger Fabric.
Referring to fig. 2, fig. 2 is a schematic diagram illustrating a transaction execution flow in a blockchain system based on Hyperridge Fabric according to an exemplary embodiment.
As shown in fig. 2, in the blockchain system based on the Hyperleader Fabric, the client may construct a transaction proposal (the transaction proposal may include the identifier, the method, the parameter information, and the like of the chain code that needs to be called in the transaction), select an endorsement node according to the endorsement policy, and submit the transaction proposal to the endorsement node.
After receiving the transaction proposal, the endorsement node can simulate and execute the service logic in the chain code, sign the simulation execution result, and subsequently return the signed simulation execution result to the client.
After receiving the simulated execution result after the signature, the client may first verify the signature, and after the verification is passed, construct a transaction corresponding to the transaction proposal (specifically, the transaction proposal and the simulated execution result after the signature may be packaged into a transaction), and then submit the transaction to the ordering service node.
The sequencing service node may sequence the unpacked transactions in the channel according to the receiving time sequence of the transactions in the same channel, generate a block containing the transactions (specifically, the transactions may be packed into the block), and subsequently broadcast the block to the master node in different organizations in the channel, and since all Peer nodes are accounting nodes, the block received by the master node may be synchronized among all Peer nodes in the channel; at this point, the Peer node in the channel can perform the transaction in the block.
The present application is described below with reference to specific embodiments and specific application scenarios.
Referring to fig. 3, fig. 3 is a flow chart illustrating a method of generating a pledget according to an exemplary embodiment. The method can be applied to business systems. The method may perform the steps of:
step 302: receiving a pledge request which is initiated by a user and aims at target assets to be pledged;
step 304: according to a preset pledge verification rule, performing pledge verification on the target asset;
step 306: if the pledge verification of the target asset passes, adding the target asset to a pledge asset pool of the user and generating a pledge sheet corresponding to the target asset;
step 308: and storing the generated association relationship between the pledge sheet and the pledge asset pool of the user, and storing the pledge sheet in a block chain for evidence.
In this specification, the service system may access the block chain, and may at least perform authentication on the block chain.
For example, please refer to fig. 1 and fig. 2, the service system may be deployed on a node device in a blockchain system, and may also be deployed on a client connected to the node device in the blockchain system, which is not limited in this specification.
In this specification, the business system may maintain a pool of pledges for a user; wherein, the pledge assets pool can comprise a plurality of assets which are used as pledgets.
For example, the business system may specifically include a business system corresponding to a financial service institution; the business system can be used for processing property management businesses such as pledge, redemption and the like, and can also be used for processing fund management businesses such as loan, repayment and the like. The assets may specifically include production equipment, raw materials, semi-finished products, finished products and other mobile assets, and may specifically include owed assets such as receivable assets.
In this specification, a pledge request initiated by the user for a target asset to be pledged may be received; further, the target asset can be subjected to pledge verification according to preset pledge verification rules.
For example, in the credit granting stage, in order to obtain a credit granting amount, the user may use an account receivable as a target asset to be pledged, and initiate a pledge request for the target asset to the business system; the business system can perform pledge verification on the target asset according to a preset pledge verification rule in response to receiving the pledge request initiated by the user so as to determine whether the pledge request passes, namely, whether the target asset can be added to a pledge asset pool of the user.
In one embodiment, the pledge validation rules may include one or more of the following: the asset type of the target asset is matched with a preset admittance asset type; the remaining effective duration of the target asset is greater than a preset effective duration threshold; matching the buyer information of the target asset with preset buyer information; and the seller information of the target asset is matched with preset seller information.
Wherein, regarding the asset types, those skilled in the art can flexibly divide the assets according to the requirements, and the description is not limited in this specification; for example, the asset types may be classified by the type of goods (e.g., digital products, appliances, food, etc.) corresponding to the asset, and the asset types that allow for pledges may also be pre-configured as admissible asset types. Regarding the effective duration threshold, a person skilled in the art may flexibly set the effective duration threshold according to requirements, which is not limited in this specification; for example, a reasonable valid duration threshold may be set based on the shelf life, life cycle, market fluctuations, etc. of the asset itself to indicate a reasonable pledge maximum duration for the pledge. The buyer information and the buyer information may be obtained from transaction information equivalent to a transaction contract related to a target asset in a supply chain finance scenario, the transaction information may be provided together by a user when initiating a pledge request, or related transaction data provided by other data providers may be invoked when obtaining the authorization of the user, which is not limited in this specification.
For example, the business system may be preconfigured with control parameters such as an admission asset type list, an effective duration threshold date, buyer information buyer, buyer information seller, and the like. Specifically, the pledge validation rule may include: (1) the asset type of the target asset is matched with a preset admission asset type list; (2) the remaining effective duration of the target asset is greater than a preset effective duration threshold date; (3) the buyer information of the target asset is matched with preset buyer information layer; (4) and the seller information of the target asset is matched with preset seller information seller.
It should be noted that in the above illustrated embodiment, if the pledge of the target asset passes verification based on one or more pledge verification rules, it may be determined that the pledge of the target asset passes verification. In practical applications, in addition to the above-described pledge validation rules, a person skilled in the art may flexibly set other pledge validation rules according to requirements, which is not limited in this specification.
In this specification, if the pledge verification for the target asset passes, the target asset may be added to the pledge asset pool of the user and a pledge corresponding to the target asset may be generated.
For example, if the pledge for the target asset passes verification, a pledge request for the target asset initiated by the user may be passed, the target asset may be added to a pledge asset pool of the user, and a pledge corresponding to the target asset may be generated.
In practical applications, since the assets may be stored in different entity warehouses or may be managed by different operators, the assets in the user's pledge asset pool may be divided into different asset sets for management according to the asset attribute information of the assets.
The asset attribute information may specifically include, but is not limited to, location information, attribution information, and the like of an asset; the collection of assets may also be referred to as a virtual bin or virtual warehouse. For example, the assets of the cargo class stored in physical warehouses located in different regions can be divided into the same asset set. For another example, assets managed by the same operator may be divided into the same set of assets. Regarding the dividing manner of the asset set, the above is only an exemplary description, and in practical applications, those skilled in the art may also use other manners to divide the asset set according to requirements, and details are not repeated here.
In one illustrated embodiment, the business system may also maintain a collection of assets to which assets included in the pledge asset pool belong; assets with different asset attribute information may belong to different asset collections. The method may further comprise: if the pledge of the target asset passes verification, determining an asset set to which the target asset belongs according to the asset attribute information of the target asset; and storing the association relationship between the asset set to which the target asset belongs and the pledge asset pool of the user and the association relationship between the asset set to which the target asset belongs and the pledge.
In this specification, the service system may access a block chain; after generating the pledge corresponding to the target asset, the generated pledge and the association relationship of the pledge pool of the user can be stored, and the pledge is stored in the block chain for verification.
For example, after generating a pledget corresponding to the target asset, the association of the pledget with the user's pledget pool may be stored, and the pledget may be credited in a blockchain. Optionally, the association relationship between the pledget and the pledget asset pool of the user may include a many-to-one association relationship.
In practical applications, in order to ensure the legal effectiveness of the pledge, the generated pledge may be digitally signed based on the user private key of the user, and then the digitally signed pledge is deposited and certified on the block chain, so as to ensure the non-repudiation of the pledge.
In an embodiment shown, the storing the pledge in the blockchain may specifically include: based on a user private key in the user digital certificate, performing digital signature on the generated pledge to obtain a pledge carrying the digital signature of the user; storing the pledge carrying the digital signature of the user in the block chain; and enabling the node equipment in the block chain to generate a corresponding pledge contract based on the pledge list carrying the digital signature of the user, and storing the generated pledge contract in the block chain.
The digital certificate can be divided into a signature certificate and an encryption certificate; the signing certificate can be used for digitally signing data to ensure non-repudiation of the data; the encryption certificate may be used to encrypt data to be transmitted to ensure authenticity and integrity of the data. The digital certificate of the user can be used for the identity certification of the user in a network, and in each link of electronic transaction, each user participating in the transaction can solve the trust problem among the users by verifying the digital certificates of other users. Specifically, the certificate format and the certificate content of the digital certificate may be referred to in the x.509 standard, which is not described herein again.
For example, the user may obtain a digital certificate issued by an electronic certification service authority that obtains permission for electronic certification service when registering in a business system; the identity authentication can be carried out through the digital certificate when the user logs in the service system subsequently; when the user performs various business operations after logging in successfully, the business system can perform digital signature on the generated pledge based on the user private key in the digital certificate to obtain the pledge carrying the digital signature of the user; further, the pledge carrying the digital signature of the user can be stored in the block chain; and enabling the node equipment in the block chain to generate a corresponding pledge contract based on the pledge list carrying the digital signature of the user, and storing the generated pledge contract in the block chain.
It should be noted that, in the above illustrated embodiment, after the generated pledge is certified in the block chain, the business system may further obtain a corresponding certification storing identifier (also referred to as token or electronic certificate), and may store the obtained certification storing identifier in the business system; wherein the certificate of deposit identification can be used to retrieve the certified pledget on the blockchain.
In addition, in practical applications, in addition to automatically generating a pledge contract corresponding to the pledge through the node device in the block chain, the pledge contract corresponding to the service system may also be generated based on the pledge certified to the block chain, which is not limited in this specification. For example, after the generated pledge is stored in the blockchain, the business system may generate a corresponding pledge contract based on the pledge and perform online sign-up.
In this specification, the business system may automatically generate a pledge form, and may also automatically generate a pledge change record corresponding to the pledge form.
When implemented, the method may further comprise: receiving a redemption request initiated by the user for the target asset; performing redemption verification on the target asset according to preset redemption verification rules; removing the target asset from the user's pool of pledges assets and generating a pledge change record corresponding to the target asset if redemption verification of the target asset passes; and storing the generated association relationship between the pledge change record and the pledge sheet, and storing the pledge change record in the block chain for evidence.
For example, the user may initiate a redemption request for the target asset to the business system; the business system, in response to receiving the redemption request initiated by the user, can perform redemption validation on the target asset according to preset redemption validation rules to determine whether the redemption request is passed, i.e., whether the target asset can be removed from the user's pledge asset pool; further, if redemption of the target asset is verified, the target asset may be removed from the user's pool of pledges and a pledge change record corresponding to the target asset may be generated, if the pledge request is passed; furthermore, the association relationship between the pledge change record and the pledge can be stored, and the pledge change record can be stored in the block chain for evidence storage. Optionally, the association relationship between the pledge change record and the pledge may include a many-to-one association relationship.
In practical application, in order to ensure the legal effectiveness of the pledge change record, the generated pledge change record may be digitally signed based on the user private key of the user, and then the digitally signed pledge change record is stored on the block chain to ensure the non-repudiation of the pledge change record.
In an embodiment shown in the above, the recording the pledge change in the block chain for crediting may specifically include: based on a user private key in the user digital certificate, performing digital signature on the generated pledge change record to obtain a pledge change record carrying the digital signature of the user; storing the pledge change record carrying the digital signature of the user in the block chain; and enabling the node equipment in the block chain to generate a corresponding pledge contract based on the pledge change record carrying the digital signature of the user, and storing the generated pledge contract in the block chain.
In the above illustrated embodiment, after storing the generated pledge change record in the block chain, the service system may further obtain a corresponding certificate storage identifier, and may store the obtained certificate storage identifier in the service system; wherein the certificate of existence identification can be used for retrieving the certified pledge change record on the blockchain.
In one illustrated embodiment, the business system may also maintain a user's loaned and repayed amounts. The redemption validation rules may include: the first difference value of the user is greater than the second difference value of the user; wherein the first difference is a difference between a total asset worth value of all assets in the user's pledge asset pool and an asset worth value of the target asset; the second difference is a difference between the user's loaned amount and the user's repayment amount.
It should be noted that in the above-described embodiment, if the first difference value of the user is greater than the second difference value of the user, that is, if the total asset worth value of the assets remaining in the user's pledge asset pool after the target asset is removed from the user's pledge asset pool is greater than the amount of the borrowed and unspent money of the user, the redemption request can be passed.
In one embodiment shown, the business system may also maintain the credit line of the user; the method may further comprise: if the pledge of the target asset passes verification, the credit line of the user is improved according to the asset value of the target asset; receiving a loan request initiated by the user; wherein the loan request comprises an amount to be loaned; in response to the fact that the sum of the amount to be loaned and the second difference value of the user does not exceed the credit granting amount of the user, adding the loaned amount of the user according to the amount to be loaned, and generating a financing order corresponding to the amount to be loaned; and storing the generated association relation between the financing order and the credit line of the user.
That is, in the credit granting stage, in response to the user initiating a mortgage request for the target asset, the service system may add the target asset to the mortgage asset pool of the user and increase a credit granting amount corresponding to the asset value of the target asset for the user; in the credit phase, responding to the loan request initiated by the user, generating a corresponding financing order, and issuing a corresponding loan amount for the user according to the part which is not used currently in the credit line of the user (namely, the remaining credit line).
In another embodiment shown, the method may further comprise: receiving a repayment request initiated by the user; wherein the repayment request comprises an amount to be repayed; in response to the fact that the amount to be paid does not exceed the second difference value of the user, the amount paid by the user is increased according to the amount to be paid, and a payment record corresponding to the amount to be paid is generated; and storing the generated association relationship between the repayment record and the financing order of the user.
That is, in the credit phase, in response to a repayment request initiated by the user, a repayment record corresponding to the financing order can be generated, and the remaining credit amount of the user is increased according to the amount to be repayed. It should be noted that the repayment request may be for one or more financing orders, and the one or more financing orders may each be associated with the user's credit line.
According to the technical scheme, on one hand, in response to receiving a pledge request which is initiated by a user and aims at a target asset to be pledged, a business system can perform pledge verification on the target asset according to a preset pledge verification rule, and can add the target asset to a pledge asset pool of the user when pledge verification passes, generate a pledge sheet corresponding to the target asset, and store the generated pledge sheet and the association relationship of the pledge asset pool of the user; therefore, the business system can automatically generate a corresponding pledge sheet in response to receiving a loan request initiated by a user, thereby improving the efficiency of dynamic pledges.
On the other hand, because the data stored in the block chain has the characteristics of non-falsification, whole-course traceability, public transparency, collective maintenance and the like, if the verification of the pledge of the target asset passes, the business system can store the generated association relationship between the pledge and the pledge asset pool of the user, and can store the pledge in the block chain, thereby ensuring the complete storage of the business process of the dynamic pledge and further ensuring the legal effectiveness of the automatically generated pledge.
Corresponding to the above embodiment of the method for generating the pledget, the present specification also provides an embodiment of a device for generating a pledget.
Referring to fig. 4, fig. 4 is a hardware structure diagram of an electronic device in which an apparatus for generating a pledge is located according to an exemplary embodiment. At the hardware level, the device includes a processor 402, an internal bus 404, a network interface 406, a memory 408, and a non-volatile memory 410, although it may include hardware required for other services. One or more embodiments of the present description may be implemented in software, such as by processor 402 reading corresponding computer programs from non-volatile storage 410 into memory 408 and then executing. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
Referring to fig. 5, fig. 5 is a block diagram of an apparatus for generating a pledget in accordance with an exemplary embodiment. The apparatus for generating a pledge can be applied to the electronic device shown in fig. 4 to implement the technical solution of the present specification. Wherein, the above-mentioned device for generating the pledge may include:
a receiving unit 502, configured to receive a pledge request initiated by a user for a target asset to be pledged;
a verification unit 504, configured to perform pledge verification on the target asset according to a preset pledge verification rule;
a generating unit 506, configured to add the target asset to a pledge asset pool of the user and generate a pledge form corresponding to the target asset if the pledge verification for the target asset passes;
and the storage unit 508 is configured to store the generated association relationship between the pledge and the pledge asset pool of the user, and store the pledge in the block chain for evidence.
In this embodiment, the receiving unit 502 is further configured to receive a redemption request for the target asset initiated by the user;
the validation unit 504 is further configured to perform redemption validation on the target asset according to preset redemption validation rules;
the generating unit 506 is further configured to remove the target asset from the user's pledge asset pool and generate a pledge change record corresponding to the target asset if redemption verification of the target asset passes;
the storage unit 508 is further configured to store the generated association relationship between the pledge change record and the pledge sheet, and store the pledge change record in the block chain for evidence storage.
In this embodiment, the pledge validation rules include one or more of the following:
the asset type of the target asset is matched with a preset admittance asset type;
the residual effective duration of the target asset is greater than a preset effective duration threshold;
matching the buyer information of the target asset with preset buyer information;
and the seller information of the target asset is matched with preset seller information.
In this embodiment, the business system also maintains the loan amount and the repayment amount of the user; the redemption validation rules include:
the first difference value of the user is greater than the second difference value of the user; wherein the first difference is a difference between a total asset worth value of all assets in the user's pledge asset pool and an asset worth value of the target asset; the second difference is a difference between the user's loaned amount and the user's repayment amount.
In this embodiment, the service system also maintains the credit line of the user;
the storage unit 508 is further configured to, if the pledge of the target asset passes verification, increase the credit line of the user according to the asset value of the target asset;
the receiving unit 502 is further configured to receive a loan request initiated by the user; wherein the loan request includes an amount to be loaned;
the generating unit 506 is further configured to, in response to determining that the sum of the to-be-loaned amount and the second difference of the user does not exceed the credit granting amount of the user, increase the loaned amount of the user according to the to-be-loaned amount, and generate a financing order corresponding to the to-be-loaned amount;
the storage unit 508 is further configured to store an association relationship between the generated financing order and the credit line of the user.
In this embodiment, the method further includes:
the receiving unit 502 is further configured to receive a payment request initiated by the user; wherein the repayment request comprises an amount to be repayed;
the generating unit 506 is further configured to, in response to determining that the amount to be paid does not exceed the second difference of the user, increase the amount of money paid by the user according to the amount to be paid, and generate a payment record corresponding to the amount to be paid;
the storage unit 508 is further configured to store an association relationship between the generated repayment record and the financing order of the user.
In this embodiment, the storage unit 508 is specifically configured to:
based on a user private key in the user digital certificate, performing digital signature on the generated pledge or the pledge change record to obtain a pledge or a pledge change record carrying the digital signature of the user;
storing the pledge list or pledge change record carrying the digital signature of the user in the block chain; and enabling the node equipment in the block chain to generate a corresponding pledge contract based on the pledge list or pledge change record carrying the digital signature of the user, and storing the generated pledge contract in the block chain.
In this embodiment, the business system also maintains a set of assets to which assets included in the pledge asset pool belong; assets with different asset attribute information belong to different asset sets; the storage unit 508 is further configured to:
if the pledge of the target asset passes verification, determining an asset set to which the target asset belongs according to the asset attribute information of the target asset;
and storing the association relationship between the asset set to which the target asset belongs and the pledge asset pool of the user, and the association relationship between the asset set to which the target asset belongs and the pledge.
The specific details of the implementation process of the functions and actions of each unit in the above device are the implementation processes of the corresponding steps in the above method, and are not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are only illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both permanent and non-permanent, removable and non-removable media, may implement the information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims (10)

1. A method for generating a pledge is applied to a service system; the business system accesses a block chain; the business system maintains a pledge asset pool of the user; wherein the pledge asset pool comprises a plurality of assets used as pledges; the method comprises the following steps:
receiving a pledge request which is initiated by a user and aims at target assets to be pledged;
according to a preset pledge verification rule, performing pledge verification on the target asset;
if the pledge of the target asset passes verification, adding the target asset to a pledge asset pool of the user and generating a pledge corresponding to the target asset;
and storing the generated association relationship between the pledge sheet and the pledge asset pool of the user, and storing the pledge sheet in the block chain for evidence.
2. The method of claim 1, further comprising:
receiving a redemption request initiated by the user for the target asset;
performing redemption verification on the target asset according to preset redemption verification rules;
removing the target asset from the user's pool of pledges assets and generating a pledge change record corresponding to the target asset if redemption verification of the target asset passes;
and storing the generated association relationship between the pledge change record and the pledge sheet, and storing the pledge change record in the block chain for evidence.
3. The method of claim 1, the pledge validation rule comprising one or more of:
the asset type of the target asset is matched with a preset admittance asset type;
the remaining effective duration of the target asset is greater than a preset effective duration threshold;
matching the buyer information of the target asset with preset buyer information;
and the seller information of the target asset is matched with preset seller information.
4. The method of claim 2, the business system further maintaining a loan amount and a repayment amount for the user; the redemption validation rules include:
the first difference value of the user is greater than the second difference value of the user; wherein the first difference is a difference between a total asset worth value of all assets in the user's pledge asset pool and an asset worth value of the target asset; the second difference is a difference between the user's loaned amount and the user's repayment amount.
5. The method of claim 4, wherein the business system further maintains a credit line of the user; the method further comprises the following steps:
if the pledge of the target asset passes verification, the credit line of the user is improved according to the asset value of the target asset;
receiving a loan request initiated by the user; wherein the loan request includes an amount to be loaned;
in response to the fact that the sum of the amount to be loaned and the second difference value of the user does not exceed the credit granting amount of the user, adding the loaned amount of the user according to the amount to be loaned, and generating a financing order corresponding to the amount to be loaned;
and storing the generated association relation between the financing order and the credit line of the user.
6. The method of claim 5, further comprising:
receiving a repayment request initiated by the user; wherein the repayment request comprises an amount to be repayed;
in response to determining that the amount to be paid does not exceed the second difference of the user, increasing the amount paid by the user according to the amount to be paid, and generating a payment record corresponding to the amount to be paid;
and storing the generated association relationship between the repayment record and the financing order of the user.
7. The method of claim 1 or 2, wherein crediting the pledget or the pledget change record in the blockchain comprises:
based on a user private key in the user digital certificate, performing digital signature on the generated pledge or the pledge change record to obtain a pledge or a pledge change record carrying the digital signature of the user;
storing the pledge list or pledge change record carrying the digital signature of the user in the block chain; and enabling the node equipment in the block chain to generate a corresponding pledge contract based on the pledge list or pledge change record carrying the digital signature of the user, and storing the generated pledge contract in the block chain.
8. The method of claim 1, the business system further maintaining a set of assets to which assets included in the pledge asset pool belong; assets with different asset attribute information belong to different asset sets;
the method further comprises the following steps:
if the pledge of the target asset passes verification, determining an asset set to which the target asset belongs according to the asset attribute information of the target asset;
and storing the association relationship between the asset set to which the target asset belongs and the pledge asset pool of the user, and the association relationship between the asset set to which the target asset belongs and the pledge.
9. A device for generating a pledge list is applied to a business system; the service system accesses a block chain; the business system maintains a pledge asset pool of the user; the pledge asset pool comprises a plurality of assets which are used as pledges; the device comprises:
the system comprises a receiving unit, a judging unit and a processing unit, wherein the receiving unit is used for receiving a pledge request which is initiated by a user and aims at target assets to be pledged;
the verification unit is used for verifying the pledge of the target asset according to a preset pledge verification rule;
the generation unit is used for adding the target asset to a pledge asset pool of the user and generating a pledge sheet corresponding to the target asset if the pledge verification of the target asset passes;
and the storage unit is used for storing the generated association relationship between the pledge sheet and the pledge asset pool of the user and storing the pledge sheet in the block chain for evidence.
10. The apparatus of claim 9:
the receiving unit further configured to receive a redemption request initiated by the user for the target asset;
the verification unit is further used for performing redemption verification on the target asset according to preset redemption verification rules;
the generation unit is further used for removing the target asset from a pledge asset pool of the user and generating a pledge change record corresponding to the target asset if the redemption verification of the target asset passes;
the storage unit is further used for storing the generated correlation between the pledge change record and the pledge sheet and storing the pledge change record in the block chain for evidence storage.
CN202210036233.1A 2022-01-10 2022-01-10 Method and device for generating pledge sheet Pending CN114429348A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210036233.1A CN114429348A (en) 2022-01-10 2022-01-10 Method and device for generating pledge sheet

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210036233.1A CN114429348A (en) 2022-01-10 2022-01-10 Method and device for generating pledge sheet

Publications (1)

Publication Number Publication Date
CN114429348A true CN114429348A (en) 2022-05-03

Family

ID=81312036

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210036233.1A Pending CN114429348A (en) 2022-01-10 2022-01-10 Method and device for generating pledge sheet

Country Status (1)

Country Link
CN (1) CN114429348A (en)

Similar Documents

Publication Publication Date Title
Chen et al. A survey of blockchain applications in different domains
US11188977B2 (en) Method for creating commodity assets from unrefined commodity reserves utilizing blockchain and distributed ledger technology
CN109886677B (en) Commodity purchasing method and device based on block chain
Natarajan et al. Distributed ledger technology and blockchain
Chen et al. Blockchain-based payment collection supervision system using pervasive Bitcoin digital wallet
US11669831B2 (en) Tokenized asset backed by government bonds and identity and risk scoring of associated token transactions
US20210390549A1 (en) Systems and methods for building blockchains for verifying assets for smart contracts
JP2023018052A (en) Method and system for indicating exchange related to token held anonymously on block chain
CN111417977A (en) System and method for managing patent risks
Schar et al. Bitcoin, blockchain, and cryptoassets: A comprehensive introduction
CN110333948A (en) Virtual resource allocation method and apparatus based on block chain
US11637693B2 (en) Distributed blockchain-type implementations configured to execute know-your-customer (kyc) verification for MANAGING tokenized digital assets and improved electronic wallets, and methods of use thereof
CN111127187A (en) Electronic contract order pledge loan method and equipment based on intelligent contracts
CN110599348B (en) Method, device, equipment and storage medium for stock right incentive
WO2022261650A2 (en) Systems and methods for maintenance of nft assets
Toffano et al. E-shekels across borders: a distributed ledger system to settle payments between Israel and the West Bank
Swanson Watermarked tokens and pseudonymity on public blockchains
Kabanda Model Structure for Block Chain Technology and Cryptocurrency for the financial services sector in Zimbabwe
CN114429348A (en) Method and device for generating pledge sheet
Ashfaq et al. Central Bank Digital Currencies and the Global Financial System: Theory and Practice
Salami A proposed purchase cycle audit approach using blockchain technology to increase audit effectiveness and reduce fraud
Kaur et al. Technologies Behind Crypto-Based Decentralized Finance
US11790353B2 (en) System and method for online/offline payment with virtual currency for nodes included in mobile-based blockchain distributed network
KR20220066786A (en) Real asset investment method
Srisukvattananan Overview of blockchain and possible use cases in the Thai payment system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination