WO2020256680A1 - Method for executing a digital asset transfer transaction - Google Patents

Method for executing a digital asset transfer transaction Download PDF

Info

Publication number
WO2020256680A1
WO2020256680A1 PCT/UA2020/000004 UA2020000004W WO2020256680A1 WO 2020256680 A1 WO2020256680 A1 WO 2020256680A1 UA 2020000004 W UA2020000004 W UA 2020000004W WO 2020256680 A1 WO2020256680 A1 WO 2020256680A1
Authority
WO
WIPO (PCT)
Prior art keywords
communicator
transaction
recipient
payer
digital asset
Prior art date
Application number
PCT/UA2020/000004
Other languages
French (fr)
Inventor
Aleksandr KUD
Original Assignee
Tovarystvo Z Obmezhenoiu Vidpovidalnistiu "Simcord"
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 Tovarystvo Z Obmezhenoiu Vidpovidalnistiu "Simcord" filed Critical Tovarystvo Z Obmezhenoiu Vidpovidalnistiu "Simcord"
Publication of WO2020256680A1 publication Critical patent/WO2020256680A1/en

Links

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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • 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/382—Payment protocols; Details thereof insuring higher security of 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • 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
    • G06Q2220/00—Business processing using cryptography

Definitions

  • the claimed utility model is related to information technologies and intended to be used in the financial field, for managing the rights to digital assets, and for transfer of the rights to digital assets.
  • the utility model can be used by companies, entrepreneurs, and ordinary individuals.
  • non-cash payments between private persons have also become widespread. For example, it is a typical situation where one person finds information about the sale of goods placed by another person on a classified website and makes a non-cash payment to the seller’s card account.
  • There is a known method for executing payment transactions which includes initiating the request by the payer to the payment system to execute a payment transaction in favor of the recipient, entering the amount of the payment, recipient’s name, and recipient’s address into the payment system by the payer, saving the recipient’s name, amount of the payment, and recipient’s address in the payment system, generating the transaction code by the payment system and sending it to the payer, sending the amount of the transfer and authentication code to the recipient by the payer, generating the request to receive the payment in the payment system by the recipient, entering the transaction code in the payment system by the recipient, verifying the transaction code by the payment system, executing the transaction upon the successful verification or cancelling the transaction if the verification is failed (see the description of Western Union system on the website https://www.westernunion.com/us/en/home.html).
  • the method is intended for executing transactions with cash and non-cash funds.
  • the recipient is authenticated by his/her personal details and by the transaction code.
  • the disadvantage of the method is the inability to execute transactions using other values than money.
  • the method requires the obligatory indication of the recipient’s name and his/her address and does not allow transactions to be executed in favor of an anonymous recipient.
  • Another disadvantage of the method is the inability of the payer to specify the conditions for executing a transaction (date, geographic location).
  • the known method is focused on automation of processing invoices for payment received by the payer from the recipients and is not intended for executing transactions generated by a payer.
  • the method is not able to execute transactions in favor of the recipients whose details have not been previously entered in the system and for whom the payment rules have not been established.
  • the closest analogue of the claimed method is the known method of executing payment transactions, which involves the consecutive initiating the request in the payment system for a transaction to transfer funds to the recipient by the payer, entering the recipient’s name and amount of the payment into the payment system by the payer, saving the transaction details in the payment system, in particular the recipient’s name entered by the payer, the amount of the payment entered by the payer, as well as the transaction execution conditions and authentication parameters, generating the request to receive funds from the payer in the payment system by the recipient, entering the authentication parameters into the payment system by the recipient, verifying the authentication parameters entered by the recipient by the payment system, verifying the transaction execution conditions, executing the transaction upon the successful verification or cancelling the transaction if the verification is failed (patent EP 2743873, IPC G06Q20/40, publication date 18.06.2014).
  • a distinctive feature of the known method is that the transaction execution conditions and authentication parameters are set by the payment system and cannot be established by the payer.
  • the method does not allow the payer to establish the specific transaction conditions for each transaction made by him/her and the authentication parameters for the recipient. For example, the payer cannot specify that the transaction A can only be executed after three weeks and on condition that the recipient X is located in the city of Paris, while the transaction B can only be executed after five days and on condition that the recipient Y is located in the city of Barcelona.
  • Another disadvantage of the known method is the inability of the payer to set additional authentication parameters.
  • the payer cannot specify that the transaction A can only be executed on condition that the recipient X enters the pin code“97531” specified by the payer only for this transaction in the payment system and enters a photo of a postcard with the image of the Tower of Pisa in the payment system.
  • this known method like the primary majority of other similar methods does not allow transactions to be executed in favor of the recipient whose name is unknown to the payer while ensuring a high level of security and reliability of the transaction.
  • Another analogue of the claimed method is known from the prior art method for execution of payment transactions, which involves the consecutive initiating the request for a transaction to transfer funds to the recipient in the payment system by the payer, entering the recipient’s name and amount of the payment into the payment system by the payer, saving the transaction details in the payment system, in particular the recipient’s name entered by the payer, the amount of the payment entered by the payer, as well as the transaction execution conditions and authentication parameters, generating the request to receive funds from the payer in the payment system by the recipient, entering the authentication parameters into the payment system by the recipient, verifying the authentication parameters entered by the recipient by the payment system, verifying the transaction execution conditions, executing the transaction upon the successful verification or cancelling the transaction if the verification is failed (patent application TJS2016/0071097, IPC G06Q20/38, publication date 10.03.2016).
  • the method involves using a sequence of symbols, images, audio data, biometric data, MAC address, and gestures as a transaction ID.
  • recipient authentication is required, the recipient enters the so-called“potential transaction identifier” in the form of a sequence of symbols or an image, or audio data, or biometric data. Then the system verifies whether the entered potential transaction ID matches any deferred transaction.
  • the objective of the utility model is the development of the method for digital asset transfer, which allows the payer, when initiating a request to the system for executing a transaction, to determine and enter at his/her own discretion additional transaction execution conditions (in particular, date and time of the transaction, desired time period for the transaction, data on the recipient’s geographic location), to establish and enter additional authentication parameters (alphanumerical code, graphic image, audio record, video record, text), to reliably store the information about the created and completed transaction with the possibility of subsequent review whenever necessary.
  • additional transaction execution conditions in particular, date and time of the transaction, desired time period for the transaction, data on the recipient’s geographic location
  • additional authentication parameters alphanumerical code, graphic image, audio record, video record, text
  • the set task is achieved in such a way that in the known method of executing a transaction of digital asset transfer that comprises the consecutive: receiving a request for a transaction of digital asset transfer to a recipient from the payer’s communicator by the digital value transfer system;
  • the technical result of the claimed method is an increase in the security of transaction execution through transmitting to the digital asset transfer system the additional conditions for transaction execution, alphanumeric code, and primary authentication artifacts from the payer’s communicator when receiving a request to execute the transaction by the system, and by subsequent transmitting the reproduced primary authentication artifacts to the system by the recipient’s communicator.
  • the reliability of the transaction is increased by using a physical object to create the primary authentication artifact.
  • the graphic image of any physical object and the metadata of this image stored in the payer’s communicator may be used to create the primary authentication artifact, or a series of graphic images of any physical object and the metadata of these images stored in the payer’s communicator may be used to create the primary authentication artifact.
  • the recipient’s communicator must use the graphic image of the same physical object.
  • this solution excludes the possibility of receiving a digital asset by another person.
  • the security of the transaction is further improved by receiving the secondary artifacts from the payer’s communicator, which are created using audio record with its metadata, video record with its metadata, or text with its metadata.
  • the claimed method makes possible to execute the transaction at a specific date and time, or in any desired time period (for example, with a delay of several days, weeks or months) and in a specified geographic location. It becomes possible by the use, as the additional conditions for transaction execution, of the specified date, time, and transaction time period along with the data about geographic location of the recipient’s communicator and subsequent verification of these data. Furthermore, each transaction, even with any time delay, is executed in only one step, which includes the withdrawal of the previously blocked digital asset from the payer’s account and crediting it to the recipient’s account. It also increases the transaction security by eliminating the use of the interim transfers to correspondent and transit accounts that are used by banking institutions and payment systems.
  • Digital Asset means an information resource derivative of the right to a value and circulating in a public distributed ledger (blockchain) in the form of a unique identifier.
  • a Digital Asset has a unique identifier and the nominal value in the amount determined by the procedure established by the Protocol, which corresponds to a certain part of property rights to assets. Any transactions with the Digital Asset (issue, transfer from one owner to another, splitting of nominal value, and other transactions) are recorded in a public distributed ledger as the records that cannot be deleted or modified.
  • Digital Asset attributes include:
  • Nominal value is a positive real number corresponding to the part of the user’s property rights to Assets
  • Protocol means a digital document that defines the attributes and properties of Digital Asset, rules and conditions of its creation and circulation in the public distributed ledger (blockchain), as well as the procedure for implementing the Protocol of Digital Asset.
  • Metadata means information about other information or data related to additional information about the content or the object. Metadata discloses information about the characteristics and properties describing any entities that allow automatically searching and managing them in large information flows.
  • Payer means a user of the system who initiates a transaction to transfer the Digital Asset owned by him/her to another user.
  • Recipient means a user of the system receiving the Digital Asset from the
  • Payer s Authentication Parameters mean a sequence of data, which is determined in accordance with the Protocol and identifies the Payer.
  • Recipient s Authentication Parameters mean a sequence of data, which is determined in accordance with the Protocol and identifies the Recipient.
  • Authentication Artifact means a sequence of digital data describing the characteristics of a physical object or a phenomenon.
  • the Authentication Artifact can be digital data describing the appearance of a postcard.
  • Primary Authentication Artifact means the data which describe created by the Payer digital graphic image (or a series of images) of any physical object.
  • the entered data are processed by the system, which creates on this basis a mathematical model with a specified error level.
  • the Mathematical Model is a system of characteristic equations, coefficient tensors, and a set of initial conditions (configuration).
  • the Primary Authentication Artifact is created by the system on the basis of the coefficient tensors, configuration, type (and/or the complexity) of the mathematical model, and the specified error level.
  • Secondary Authentication Artifact means the data that describe a digital audio record (video record, text) entered by the Payer.
  • the entered data are processed by the system, which creates on this basis a mathematical model with a specified error level.
  • the Mathematical Model is a system of characteristic equations, coefficient tensors, and a set of initial conditions (configuration).
  • the Secondary Authentication Artifact is created by the system on the basis of coefficient tensors, configurations of the type (and/or of the complexity) of the mathematical model, and the specified error level.
  • Conditions for Transaction Execution mean general Transaction Conditions in the system defined by the Payer in the Protocol. Additional Conditions for Transaction Execution mean conditions specified in the Protocol by the Payer for each specific transaction in the system, in particular, the desired date of the transaction, the data about the desired time period of the transaction, and the data about the Recipient’s geographic location.
  • Fig. 1 digital asset transfer system composition and interaction of its components.
  • Fig. 2 flow chart of the method implementation for executing a digital asset transfer transaction using electronic money as an example.
  • Fig. 3 flow chart of the method implementation for executing a digital asset transfer transaction using electronic money as an example (flow chart continued from Fig. 2).
  • Fig. 4 flow chart of the method implementation for executing a digital asset transfer transaction in favor of an anonymous recipient using electronic money as an example.
  • Fig. 5 flow chart of the method implementation for executing a digital asset transfer transaction in favor of an anonymous recipient using electronic money as an example (flow chart continued from Fig. 4).
  • Fig. 6 flow chart of the method implementation for executing a digital asset transfer transaction using Bitbon as an example.
  • Fig. 7 flow chart of the method implementation for digital asset transfer transaction using Bitbon as an example (flow chart continued from Fig. 6).
  • the Digital Asset transfer system consists of a network of interconnected hardware and software complexes able of performing data redundancy, and each of which includes a processing server 101, authentication artifact storage server 102, module 103 for verification of Authentication Artifacts, alphanumeric code, and Additional Conditions for Transaction Execution, public distributed ledger 104.
  • the Payer interacts with the system using the communicator 105
  • the Recipient interacts with the system using the communicator 106.
  • the communicators 105 and 106 may be programmable devices with the ability to connect to the Internet, in particular, smartphones, desktop computers, laptops, tablets, etc.
  • the server 102 is configured with the ability to save the Additional Conditions for Transaction Execution, alphanumeric code, and created Authentication Artifacts, which were received from the Payer’s communicator.
  • the server 102 contains at least one medium for recording data on it with the program instructions to the processor and the data about Additional Conditions for Transaction Execution and Authentication Artifacts.
  • the server 102 also contains the processor capable of executing instructions recorded on the storage media, which describes the procedure of receiving and consequent storage in digital form of the data about Additional Conditions for Transaction Execution and Authentication Artifacts.
  • the module 103 for verification of Authentication Artifacts, alphanumeric code, and Additional Conditions for Transaction Execution is configured with the ability to compare the Authentication Artifacts and alphanumeric code received from the Payer’s communicator and the Authentication Artifacts and alphanumeric code received from the Recipient’s communicator.
  • the verification module 103 may be configured as a separate hardware and software complex containing the processor capable of executing instructions recorded on storage media.
  • the public distributed ledger 104 of transactions is configured as a network of interconnected hardware and software complexes.
  • Example 1 Method for executing a Digital Asset transfer transaction
  • Processing servers 101 receive from the Payer’s communicator 105 a request for a Digital Asset transfer transaction as a certain amount of electronic money from the Payer to the Recipient (step 210).
  • the step includes the authentication of the Payer in the system according to the Protocol (for example, by entering login and password).
  • the communicator 105 interacts with the system using modern means of communication.
  • the Recipient’s name for example, John Smith
  • the nominal value of the Digital Asset expressed as an amount of electronic money are received from the Payer’s communicator 105 (step 220).
  • Processing servers 101 receive from the Payer’s communicator 105 the transaction type (for example, private), alphanumeric code (for example, “12345pineapple”), and Additional Conditions for Transaction Execution.
  • the Primary Authentication Artifact is received from the Payer’s communicator 105 (step 230).
  • the Additional Conditions for Transaction Execution may be the date of September 01, 2019 as well as the name of the city of Baden-Baden, from which the request to receive the transaction must be sent by the Recipient’s communicator 106.
  • the Payer can use, for example, a postcard with the image of the Tower of Pisa.
  • the Payer’s communicator 105 saves the postcard image as a digital graphic file, which, in addition to the image data, contains the Metadata related to the image.
  • the entered data are processed by the system, which use them to create a mathematical model with a specified error level.
  • the Mathematical Model is a system of characteristic equations, coefficient tensors, and a set of initial conditions (configuration).
  • the Primary Authentication Artifact is created by the system on the basis of the coefficient tensors, configuration, type (and/or the complexity) of the mathematical model, and the specified error level.
  • the Primary Authentication Artifact, alphanumeric code, transaction type, and Additional Conditions for Transaction Execution are uploaded and saved on the server 102 (step 240).
  • the information about the created transaction is saved in the public distributed ledger 104 as follows: the Recipient’s name, nominal value of the Digital Asset, and transaction type (step 250).
  • Processing servers 101 block the Digital Asset of the specified nominal value in the Payer’s account (step 260).
  • the message is sent to the Recipient’s communicator 106 about the physical object used to create the Primary Authentication Artifact, about the Additional Conditions for Transaction Execution, about the transaction identifier, and alphanumeric code (step 270).
  • the Processing servers 101 receive the request to receive the Digital Asset from the Recipient’s communicator 106 (step 310). At the same time, the Recipient is authenticated in the system according to the Protocol (for example, by entering login and password).
  • the processing servers 101 validate the received request and if its execution is possible, send the request for issuing the Authentication Artifacts to the artifact verification module 103, which, in turn, sends the request to the authentication artifact storage server 102.
  • the server 102 sends the instructions for creating the Primary Authentication Artifact to the Recipient’s communication device 106.
  • the Recipient’s communicator 106 sends the alphanumeric code “12345pineapple” to the verification module 103, reproduces the Primary Authentication Artifact on the basis of the postcard with the image of the Tower of Pisa and sends it to the verification module 103 as well (step 320).
  • the server 102 sends the Primary Authentication Artifact, which was received from the Payer’s communicator 105 and stored on it, to the verification module 103.
  • the server 102 also sends the Additional Conditions for Transaction Execution stored on it to the verification module 103.
  • the Primary Authentication Artifact and Additional Conditions for Transaction Execution are verified in the verification module 103 (step 330).
  • the Primary Authentication Artifact is verified by comparing the Primary Authentication Artifact received from the Peyer’s communicator 105 and the Primary Authentication Artifact received from the Recipient’s communicator 106.
  • the Additional Conditions for Transaction Execution are also verified in the verification module 103 (step 330). For this purpose, the date of September 01 , 2019 received from the Payer’s communicator 105 is compared with the current date, and the name of the city of Baden-Baden received from the Payer’s communicator 105 is compared with the data about the current geographic location of the Recipient’s communicator 106. If the Primary Authentication Artifact or at least one of the Additional Conditions for Transaction Execution is not verified, the transaction of crediting the Digital Asset is cancelled (step 340).
  • processing server 101 Upon successful verification of the Primary Authentication Artifact and the Additional Conditions for Transaction Execution, processing server 101 executes the transaction (step 350) by withdrawing the Digital Asset from the Payer’s account and crediting it to the Recipient’s account. Next, the information about the completed transaction is saved in the public distributed ledger 104 (step 360).
  • the message about the transaction completion is sent to the Payer’s communicator 105 and Recipient’s communicator 106.
  • the server 102 designates the Authentication Artifacts as extracted and deletes them from its storage medium.
  • Example 2 Method for executing a Digital Asset transfer transaction in favor of an anonymous Recipient using electronic money as an example (Fig. 4,
  • Processing servers 101 receive from the Payer’s communicator 105 a request for a transaction of transferring the Digital Asset as a certain amount of electronic money from the Payer to the anonymous Recipient (step 410).
  • the step includes the authentication of the Payer in the system according to the Protocol (for example, by entering login and password).
  • the Payer’s communication device 105 interacts with the system using modem means of communication.
  • the system receives the data about the anonymous Recipient (for example, Anonymous or John Doe) and the nominal value of the Digital Asset expressed as an amount of electronic currency units from the Payer’s communicator 105 (step 420).
  • the transaction type for example, public
  • alphanumeric code for example, “12345pineapple”
  • Additional Conditions for Transaction Execution are received from the Payer’s communicator 105.
  • the created Primary Authentication Artifact is received from the Payer’s communicator 105 (step 430).
  • the Additional Conditions for Transaction Execution may be the date of September 01, 2019, as well as the name of the city of Kunststoff, from which the request to receive the transaction must be sent by the Recipient’s communicator 106.
  • the Payer can use, for example, a photo of a half- full Coca-Cola glass bottle.
  • the software of the Payer’s communication device 105 saves the image of the bottle as a digital graphic file, which, in addition to the image data, contains the Metadata related to the image.
  • the entered data are processed by the system, which creates a mathematical model with a specified error level.
  • the mathematical model is a system of characteristic equations, coefficient tensors, and a set of initial conditions (configuration).
  • the Primary Authentication Artifact is created by the system on the basis of the coefficient tensors, configuration, type (and/or the complexity) of the mathematical model, and the specified error level.
  • the“Yellow Submarine” song by the Beatles can be used, which was downloaded to the Payer’s communication device 105.
  • the song is saved as a digital audio file, which, in addition to the audio data, contains the Metadata related to the audio record (step 440).
  • the entered data are processed by the system, which creates a mathematical model with a specified error level.
  • the mathematical model is a system of characteristic equations, coefficient tensors, and a set of initial conditions (configuration).
  • the Secondary Authentication Artifact is created by the system on the basis of coefficient tensors, configurations of the type (and/or of the complexity) of the mathematical model, and the specified error level.
  • the Primary and Secondary Authentication Artifacts, alphanumeric code, transaction type, and Additional Conditions for Transaction Execution are uploaded and saved on the server 102 (step 450).
  • the information about the created transaction is saved in the public distributed ledger 104 including the anonymous Recipient’s name, nominal value of the Digital Asset, and transaction type (step 460).
  • Processing servers 101 block the Digital Asset of the specified nominal value in the Payer’s account (step 470).
  • the message is sent to the Recipient’s communicator 106 about the physical object used to create the Primary Authentication Artifact, about the song that was used for creating the Secondary Authentication Artifact, about the Additional Conditions for Transaction Execution, about the transaction identifier, and alphanumeric code (step 480).
  • the system may inform the Recipient by sending a personal message via SMS, e-mail or messenger. It is also possible to inform a large number of people by sending mass messages to their communicators. Such method of informing may be useful for conducting large- scale advertising campaigns and prize drawings, when it is not known in advance who exactly will be the Recipient.
  • the processing servers 101 receive the request to receive the Digital Asset from the Recipient’s communicator 106 (step 510).
  • the Recipient is authenticated in the system according to the Protocol (for example, by entering login and password).
  • the Processing servers 101 validate the received request and if its execution is possible, send the request for issuing the Authentication Artifacts to the artifact verification module 103, which, in turn, sends the request to the authentication artifact storage server 102.
  • the server 102 sends the instructions for creating the Primary and Secondary Authentication Artifacts to the communication device 106.
  • the Recipient’s communicator 106 sends the alphanumeric code “12345pineapple” and, using the software, reproduces the Primary and Secondary Authentication Artifacts on the basis of the photo of a half-full Coca-Cola glass bottle, the“Yellow Submarine” song by the Beatles, and the relevant Metadata.
  • the Recipient’s communicator 106 sends the created Primary Authentication Artifact (step 520) and the created Secondary Authentication Artifact (step 530) to the verification module 103.
  • the server 102 sends the created Primary and the Secondary Authentication Artifacts, which were received from the Payer’s communicator 105 and stored on it, to the verification module 103.
  • the server 102 also sends the Additional Conditions for Transaction Execution stored on it to the verification module 103.
  • the Primary and the Secondary Authentication Artifacts, and Additional Conditions for Transaction Execution are verified in the verification module 103 (step 540).
  • the Primary Authentication Artifact is verified by comparing the Primary Authentication Artifact received from the Peyer’s communicator 105 and the Primary Authentication Artifact received from the Recipient’s communicator 106.
  • the Secondary Authentication Artifact is verified by comparing the Secondary Authentication Artifact received from the Peyer’s communicator 105 and the Secondary Authentication Artifact received from the Recipient’s communicator 106.
  • the Additional Conditions for Transaction Execution are also verified in the verification module 103 (step 540). For this purpose, the date of September 01, 2019 received from the Payer’s communicator 105 is compared with the current date, and the name of the city of Kunststoff received from the Payer’s communicator 105 is compared with the data about the current geographic location of the Recipient’s communicator 106.
  • the transaction is cancelled (step 550).
  • the processing server 101 Upon successful verification of the Primary Authentication Artifact and the Additional Conditions for Transaction Execution, the processing server 101 executes the transaction (step 560) by withdrawing the Digital Asset from the Payer’s account and crediting it to the Recipient’s account. Next, the information about the completed transaction is saved in the public distributed ledger 104 (step 570).
  • the message about the transaction completion is sent to the Payer’s communicator 105 and Recipient’s communicator 106.
  • the server 102 designates the Authentication Artifacts as extracted and deletes them from its storage medium.
  • Example 3 Method for executing a Digital Asset transfer transaction using Bitbon as an example (Fig. 6, Fig. 7).
  • the Processing servers 101 receive from the communicator 105 of the Payer (Bitbon owner) a request to transfer the Digital Asset as Bitbon from the Payer to the Recipient according to the Protocol (step 610).
  • the Payer’s communicator 105 interacts with the system using modem means of communication.
  • the processing servers 101 receive from the Payer’s communicator 105 the Recipient’s name (for example, John Smith) and the nominal value of the Digital Asset expressed as an amount of Bitbon (step 620).
  • the transaction type for example, private
  • alphanumeric code for example, “12345pineapple”
  • Additional Conditions for Transaction Execution are received from the Payer’s communicator 105; the Primary Authentication Artifact is also created (step 630).
  • the Additional Conditions for Transaction Execution may be the date of September 01 , 2019, as well as the name of the city of London, from which the request to receive Bitbon must be sent by the Recipient’s communicator 106.
  • a photo of a cat statuette can be used, which is entered into the Payer’s communication device 105.
  • the photo is saved as a digital image file, which, in addition to the image data, contains the Metadata related to the image.
  • the entered data are processed by the system, which creates a mathematical model with a specified error level.
  • the mathematical model is a system of characteristic equations, coefficient tensors, and a set of initial conditions (configuration).
  • the Primary Authentication Artifact is created by the system on the basis of the coefficient tensors, configuration, type (and/or the complexity) of the mathematical model, and the specified error level.
  • the information about the created transaction is saved in the public distributed ledger 104 including the Recipient’s name, Bitbon nominal value, and transaction type (step 650).
  • the message is sent to the Recipient’s communication device 106 about the physical object used to create the Primary Authentication Artifact, about the Additional Conditions for Transaction Execution, about the transaction identifier, and alphanumeric code (step 670).
  • the Processing servers 101 receive the request to receive the Digital Asset from the Recipient’s communicator 106 (step 710). At the same time, the Recipient is authenticated in the system according to the Protocol (for example, by entering login and password).
  • the Processing servers 101 validate the Recipient’s request and if its execution is possible, send the request for issuing the authentication artifacts to the artifact verification module 103, which, in turn, sends the request to the authentication artifact storage server 102.
  • the server 102 sends the instructions for creating the Primary Authentication Artifact to the Recipient’s communication device 106.
  • the Recipient’s communication device 106 sends to the system the alphanumeric code “12345pineapple” and, using the software, reproduces the Primary Authentication Artifact on the basis of the cat statuette image and the Metadata of the image.
  • the reproduced Primary Authentication Artifact is uploaded from the communicator 106 to the verification module 103 (step 720).
  • the server 102 sends the Primary Authentication Artifact, which was received from the Payer’s communicator 105 and stored on it, to the verification module 103.
  • the server 102 also sends the Additional Conditions for Transaction Execution stored on it to the verification module 103.
  • the Primary Authentication Artifact and Additional Conditions for Transaction Execution are verified in the verification module 103 (step 730).
  • the Primary Authentication Artifact is verified by comparing the Primary Authentication Artifact received from the Payer’s communicator 105 and the Primary Authentication Artifact received from the Recipient’s communicator 106.
  • the Additional Conditions for Transaction Execution are verified in the verification module 103 (step 730).
  • the date of September 01, 2019 received from the Payer’s communicator 105 is compared with the current date, and the name of the city of London received from the Payer’s communicator is compared with the data about the current geographic location of the Recipient’s communicator.
  • processing server 101 Upon successful verification of the Primary Authentication Artifact and the Additional Conditions for Transaction Execution, processing server 101 executes the Bitbon transaction (step 750) by withdrawing it from the Payer’s account and crediting it to the Recipient’s account. Next, the information about the completed transaction is saved in the public distributed ledger 104 (step 760).
  • the message about the transaction completion is sent to the Payer’s communicator 105 and Recipient’s communicator 106.
  • the Authentication Artifacts on the server 102 are designated as extracted and are deleted.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

A method for executing a digital asset transfer transaction comprising receiving by a digital asset transfer system from a payer's communicator (105) a request for the transaction of digital asset transfer to a recipient, additional conditions tor the transaction execution, a transaction type, an alphanumeric code and a primary authentication artifact created using a physical object; saving details of the created transaction including a recipient's name, a nominal value of the digital asset and the transaction type in a public distributed ledger (104); blocking the digital asset of the specified nominal value in a payer's account; sending a message about the physical object used to create the primary authentication artifact, about the additional conditions for the transaction execution, a transaction identifier, and the alphanumeric code to a recipient's communicator (106); receiving a request to receive the digital asset from the recipient's communicator by the digital asset transfer system; verifying by the digital asset transfer system a compliance with the additional conditions for the transaction execution including comparing the alphanumeric code and the primary authentication artifact received from the recipient's communicator with the alphanumeric code and the primary authentication artifact received from the payer's communicator; withdrawing the digital asset from the payer's account and crediting it to a recipient's account; saving an information about the executed transaction in the public distributed ledger.

Description

METHOD FOR EXECUTING A DIGITAL ASSET
TRANSFER TRANSACTION
Technical Field
The claimed utility model is related to information technologies and intended to be used in the financial field, for managing the rights to digital assets, and for transfer of the rights to digital assets. The utility model can be used by companies, entrepreneurs, and ordinary individuals.
Background Art
With the development and global spread of payment systems, non-cash payments between private persons have also become widespread. For example, it is a typical situation where one person finds information about the sale of goods placed by another person on a classified website and makes a non-cash payment to the seller’s card account.
It is a common situation when one person makes a non-cash transfer to the card account of another person to pay for any service, which they provide (for example, cleaning the house, looking after the child or a dog walking service).
It is a typical situation when parents send money to their child through a non-cash transfer by crediting his/her card account. Or vice versa, adult children make a non-cash transfer to the card account of their parents providing them with financial assistance.
The situation when the cost equivalents of monetary units (electronic money, digital assets, and other digital assets) are used for making payments between people is becoming more frequent. In addition, such payments are made using a computer and/or a cellular network provided by telecom operators without having to visit a traditional financial institution such as bank or to use a payment system.
In all these instances the claimed method for executing a digital asset transfer transaction can be used. It should be also noted that the listed cases do not limit the application field of the claimed method.
There is a known method for executing payment transactions, which includes initiating the request by the payer to the payment system to execute a payment transaction in favor of the recipient, entering the amount of the payment, recipient’s name, and recipient’s address into the payment system by the payer, saving the recipient’s name, amount of the payment, and recipient’s address in the payment system, generating the transaction code by the payment system and sending it to the payer, sending the amount of the transfer and authentication code to the recipient by the payer, generating the request to receive the payment in the payment system by the recipient, entering the transaction code in the payment system by the recipient, verifying the transaction code by the payment system, executing the transaction upon the successful verification or cancelling the transaction if the verification is failed (see the description of Western Union system on the website https://www.westernunion.com/us/en/home.html).
The method is intended for executing transactions with cash and non-cash funds. The recipient is authenticated by his/her personal details and by the transaction code. The disadvantage of the method is the inability to execute transactions using other values than money. In addition, the method requires the obligatory indication of the recipient’s name and his/her address and does not allow transactions to be executed in favor of an anonymous recipient. Another disadvantage of the method is the inability of the payer to specify the conditions for executing a transaction (date, geographic location). There is a known method for executing payment transactions, which includes receiving an invoice for payment from the recipient, identifying a graphic image (signature or logo) on the invoice that identifies the recipient, identifying the recipient by recognizing the signatures and logos of the known recipients existing in the system, implementing the payment rule intended for the identified recipient (patent application US20130226798, IPC G06Q20/10, G06Q20/40, publication date 29.08.2013).
The known method is focused on automation of processing invoices for payment received by the payer from the recipients and is not intended for executing transactions generated by a payer. The method is not able to execute transactions in favor of the recipients whose details have not been previously entered in the system and for whom the payment rules have not been established.
The closest analogue of the claimed method is the known method of executing payment transactions, which involves the consecutive initiating the request in the payment system for a transaction to transfer funds to the recipient by the payer, entering the recipient’s name and amount of the payment into the payment system by the payer, saving the transaction details in the payment system, in particular the recipient’s name entered by the payer, the amount of the payment entered by the payer, as well as the transaction execution conditions and authentication parameters, generating the request to receive funds from the payer in the payment system by the recipient, entering the authentication parameters into the payment system by the recipient, verifying the authentication parameters entered by the recipient by the payment system, verifying the transaction execution conditions, executing the transaction upon the successful verification or cancelling the transaction if the verification is failed (patent EP 2743873, IPC G06Q20/40, publication date 18.06.2014). A distinctive feature of the known method is that the transaction execution conditions and authentication parameters are set by the payment system and cannot be established by the payer. The method does not allow the payer to establish the specific transaction conditions for each transaction made by him/her and the authentication parameters for the recipient. For example, the payer cannot specify that the transaction A can only be executed after three weeks and on condition that the recipient X is located in the city of Paris, while the transaction B can only be executed after five days and on condition that the recipient Y is located in the city of Barcelona.
Another disadvantage of the known method is the inability of the payer to set additional authentication parameters. For example, the payer cannot specify that the transaction A can only be executed on condition that the recipient X enters the pin code“97531” specified by the payer only for this transaction in the payment system and enters a photo of a postcard with the image of the Tower of Pisa in the payment system.
Inability of the payer to establish specific transaction conditions and authentication parameters makes the known method insufficiently reliable and inflexible in use.
Moreover, this known method like the primary majority of other similar methods does not allow transactions to be executed in favor of the recipient whose name is unknown to the payer while ensuring a high level of security and reliability of the transaction.
Another analogue of the claimed method is known from the prior art method for execution of payment transactions, which involves the consecutive initiating the request for a transaction to transfer funds to the recipient in the payment system by the payer, entering the recipient’s name and amount of the payment into the payment system by the payer, saving the transaction details in the payment system, in particular the recipient’s name entered by the payer, the amount of the payment entered by the payer, as well as the transaction execution conditions and authentication parameters, generating the request to receive funds from the payer in the payment system by the recipient, entering the authentication parameters into the payment system by the recipient, verifying the authentication parameters entered by the recipient by the payment system, verifying the transaction execution conditions, executing the transaction upon the successful verification or cancelling the transaction if the verification is failed (patent application TJS2016/0071097, IPC G06Q20/38, publication date 10.03.2016). The method involves using a sequence of symbols, images, audio data, biometric data, MAC address, and gestures as a transaction ID. To receive the payment, recipient authentication is required, the recipient enters the so-called“potential transaction identifier” in the form of a sequence of symbols or an image, or audio data, or biometric data. Then the system verifies whether the entered potential transaction ID matches any deferred transaction.
It should be noted that the processing of graphic, audio, and video data requires considerable computing power and a considerable amount of storage media for data recording. Transmission of a potential transaction ID in the form of graphic, audio or video data requires a reliable and high-speed communication channel between the server and the user’s terminal. Each attempt by the recipient to enter a potential transaction ID will require transmitting and processing a significant amount of information. In case of an error, the potential transaction ID needs to be re-entered by sending a significant amount of information once more. This implementation of the method makes the system vulnerable to DoS attacks. By deliberately entering incorrect potential transaction IDs into the system, it is possible to load the system in such a way that it will not be able to respond to user requests or will respond very slowly. The objective of the utility model is the development of the method for digital asset transfer, which allows the payer, when initiating a request to the system for executing a transaction, to determine and enter at his/her own discretion additional transaction execution conditions (in particular, date and time of the transaction, desired time period for the transaction, data on the recipient’s geographic location), to establish and enter additional authentication parameters (alphanumerical code, graphic image, audio record, video record, text), to reliably store the information about the created and completed transaction with the possibility of subsequent review whenever necessary.
Disclosure of Invention
The set task is achieved in such a way that in the known method of executing a transaction of digital asset transfer that comprises the consecutive: receiving a request for a transaction of digital asset transfer to a recipient from the payer’s communicator by the digital value transfer system;
receiving the nominal value of digital asset and the recipient’s name whenever necessary from the payer’s communicator by the money transfer system; saving the transaction details in the digital asset transfer system, in particular the recipient’s name, nominal value of digital asset, transaction type, as well as the transaction execution conditions and authentication parameters;
receiving, by the digital asset transfer system, a request to receive a digital asset from the payer that was sent from the recipient’s communicator;
receiving, by the digital asset transfer system, authentication parameters from the recipient’s communicator;
verifying, by the digital asset transfer system, the authentication parameters received from the recipient’s communicator;
verifying the transaction execution conditions by the digital asset transfer system; executing the transaction upon the successful verification or cancelling the transaction if the verification is failed; in accordance with the proposed technical solution, when receiving a request for a transaction of digital asset transfer to the recipient from the payer’s communicator by the digital asset transfer system, additional conditions for transaction execution, transaction type, alphanumeric code, and primary authentication artifact created using the physical object are additionally received from the payer’s communicator; the details of the created transaction are saved in the public distributed ledger including the recipient’s name, nominal value of digital asset, and transaction type; the additional conditions for transaction execution, transaction type, alphanumeric code, and primary authentication artifact received from the payer’s communicator are saved in the system; digital asset of the specified nominal value is blocked in the payer’s account; the message is sent to the recipient’s communicator about the physical object used to create the primary authentication artifact, about the additional conditions for transaction execution, the transaction identifier, and alphanumeric code; when receiving a request to receive the digital asset from the recipient’s communicator by the digital asset transfer system, alphanumeric code and primary authentication artifact created using the physical object are additionally received from the payer’s communicator; then the digital asset transfer system verifies the compliance with additional conditions for transaction execution that includes also comparing, by the system, the alphanumeric code received from the recipient’s communicator with the alphanumeric code received from the payer’s communicator, and comparing, by the system, the primary authentication artifact received from the recipient’s communicator with the primary authentication artifact received from the payer’s communicator; the digital asset is withdrawn from the payer’s account and is credited to the recipient’s account; the information about the executed transaction is saved in a public distributed ledger. It is possible to implement a method in which the date and time of the transaction received from the payer’s communicator are used as additional conditions for transaction execution.
It is possible to implement a method in which the data on the desired time period of the transaction received from the payer’s communicator are used as additional conditions for transaction execution.
It is possible to implement a method in which the data on the geographic location of the recipient’s communicator received from the payer’s communicator are used as additional conditions for transaction execution.
It is possible to implement a method in which a graphic image of any physical object processed by the payer’s communicator and metadata of this image are used to create the primary authentication artifact.
It is possible to implement a method in which a series of graphic images of any physical object processed by the payer’s communicator and metadata of these images are used to create the primary authentication artifact.
It is possible to implement a method in which, additionally, when the digital asset transfer system receives the request for executing a digital asset transfer transaction to the recipient from the payer’s communicator, the secondary authentication artifact created by the payer’s communicator is uploaded and saved in the system, and then a message about it is sent to the recipient’s communicator; when the digital asset transfer system received the request for receiving a digital asset from the recipient’s communicator, the secondary authentication artifact created by the recipient’s communicator is uploaded in the system, and then the system compares the secondary authentication artifact received from the recipient’s communicator and the secondary authentication artifact received from the payer’s communicator. It is possible to implement a method in which an audio record received from the payer’s communicator and metadata of this audio record are used to create the secondary authentication artifact.
It is possible to implement a method in which a video record received from the payer’s communicator and metadata of this video record are used to create the secondary authentication artifact.
It is possible to implement a method in which a text received from the payer’s communicator and metadata of this text are used to create the secondary authentication artifact.
It is possible to implement a method in which, when the digital asset transfer system receives a request to execute a digital asset transfer transaction to the recipient from the payer’s communicator, an anonymous recipient is entered in the recipient’s name field.
The technical result of the claimed method is an increase in the security of transaction execution through transmitting to the digital asset transfer system the additional conditions for transaction execution, alphanumeric code, and primary authentication artifacts from the payer’s communicator when receiving a request to execute the transaction by the system, and by subsequent transmitting the reproduced primary authentication artifacts to the system by the recipient’s communicator.
In particular, the reliability of the transaction is increased by using a physical object to create the primary authentication artifact. For example, the graphic image of any physical object and the metadata of this image stored in the payer’s communicator may be used to create the primary authentication artifact, or a series of graphic images of any physical object and the metadata of these images stored in the payer’s communicator may be used to create the primary authentication artifact. Accordingly, to reproduce the primary authentication artifact, the recipient’s communicator must use the graphic image of the same physical object. Along with the need to send an alphanumeric code, this solution excludes the possibility of receiving a digital asset by another person.
The security of the transaction is further improved by receiving the secondary artifacts from the payer’s communicator, which are created using audio record with its metadata, video record with its metadata, or text with its metadata.
The claimed method makes possible to execute the transaction at a specific date and time, or in any desired time period (for example, with a delay of several days, weeks or months) and in a specified geographic location. It becomes possible by the use, as the additional conditions for transaction execution, of the specified date, time, and transaction time period along with the data about geographic location of the recipient’s communicator and subsequent verification of these data. Furthermore, each transaction, even with any time delay, is executed in only one step, which includes the withdrawal of the previously blocked digital asset from the payer’s account and crediting it to the recipient’s account. It also increases the transaction security by eliminating the use of the interim transfers to correspondent and transit accounts that are used by banking institutions and payment systems.
It is possible to safely store the information about initiated and executed transactions by saving it to the public distributed ledger. Since the public distributed ledger is stored on an unlimited number of interconnected hardware- software complexes, the possibility of forgery of transaction information is excluded.
In addition, it becomes possible to execute transactions in favor of an anonymous recipient (i.e. a recipient whose name is not known to the payer) while maintaining the high level of security and reliability of the transaction due to the recipient’s identification by primary and/or secondary authentication artifacts only.
The main point of the claimed method for executing a digital asset transfer transaction will be described in detail in the following materials. Glossary of terms used in the document
Digital Asset means an information resource derivative of the right to a value and circulating in a public distributed ledger (blockchain) in the form of a unique identifier. A Digital Asset has a unique identifier and the nominal value in the amount determined by the procedure established by the Protocol, which corresponds to a certain part of property rights to assets. Any transactions with the Digital Asset (issue, transfer from one owner to another, splitting of nominal value, and other transactions) are recorded in a public distributed ledger as the records that cannot be deleted or modified.
Digital Asset attributes include:
• Unique identifier is a unique sequence of alphabetic and numeric characters;
• Nominal value is a positive real number corresponding to the part of the user’s property rights to Assets;
• Records in the public distributed ledger, which register all operations with each Digital Asset;
• Protocol.
Protocol means a digital document that defines the attributes and properties of Digital Asset, rules and conditions of its creation and circulation in the public distributed ledger (blockchain), as well as the procedure for implementing the Protocol of Digital Asset.
Metadata means information about other information or data related to additional information about the content or the object. Metadata discloses information about the characteristics and properties describing any entities that allow automatically searching and managing them in large information flows.
Payer means a user of the system who initiates a transaction to transfer the Digital Asset owned by him/her to another user. Recipient means a user of the system receiving the Digital Asset from the
Payer.
Payer’s Authentication Parameters mean a sequence of data, which is determined in accordance with the Protocol and identifies the Payer.
Recipient’s Authentication Parameters mean a sequence of data, which is determined in accordance with the Protocol and identifies the Recipient.
Authentication Artifact means a sequence of digital data describing the characteristics of a physical object or a phenomenon. For example, the Authentication Artifact can be digital data describing the appearance of a postcard.
Primary Authentication Artifact means the data which describe created by the Payer digital graphic image (or a series of images) of any physical object. The entered data are processed by the system, which creates on this basis a mathematical model with a specified error level. The Mathematical Model is a system of characteristic equations, coefficient tensors, and a set of initial conditions (configuration). The Primary Authentication Artifact is created by the system on the basis of the coefficient tensors, configuration, type (and/or the complexity) of the mathematical model, and the specified error level.
Secondary Authentication Artifact means the data that describe a digital audio record (video record, text) entered by the Payer. The entered data are processed by the system, which creates on this basis a mathematical model with a specified error level. The Mathematical Model is a system of characteristic equations, coefficient tensors, and a set of initial conditions (configuration). The Secondary Authentication Artifact is created by the system on the basis of coefficient tensors, configurations of the type (and/or of the complexity) of the mathematical model, and the specified error level.
Conditions for Transaction Execution mean general Transaction Conditions in the system defined by the Payer in the Protocol. Additional Conditions for Transaction Execution mean conditions specified in the Protocol by the Payer for each specific transaction in the system, in particular, the desired date of the transaction, the data about the desired time period of the transaction, and the data about the Recipient’s geographic location.
Brief Description of Drawings
The declared method is illustrated with the following drawings:
Fig. 1— digital asset transfer system composition and interaction of its components.
Fig. 2— flow chart of the method implementation for executing a digital asset transfer transaction using electronic money as an example.
Fig. 3— flow chart of the method implementation for executing a digital asset transfer transaction using electronic money as an example (flow chart continued from Fig. 2).
Fig. 4— flow chart of the method implementation for executing a digital asset transfer transaction in favor of an anonymous recipient using electronic money as an example.
Fig. 5— flow chart of the method implementation for executing a digital asset transfer transaction in favor of an anonymous recipient using electronic money as an example (flow chart continued from Fig. 4).
Fig. 6— flow chart of the method implementation for executing a digital asset transfer transaction using Bitbon as an example.
Fig. 7— flow chart of the method implementation for digital asset transfer transaction using Bitbon as an example (flow chart continued from Fig. 6).
Detailed Description of Drawings The claimed method is implemented using the Digital Asset transfer system
(Fig· I)·
The Digital Asset transfer system consists of a network of interconnected hardware and software complexes able of performing data redundancy, and each of which includes a processing server 101, authentication artifact storage server 102, module 103 for verification of Authentication Artifacts, alphanumeric code, and Additional Conditions for Transaction Execution, public distributed ledger 104. The Payer interacts with the system using the communicator 105, and the Recipient interacts with the system using the communicator 106. The communicators 105 and 106 may be programmable devices with the ability to connect to the Internet, in particular, smartphones, desktop computers, laptops, tablets, etc.
The server 102 is configured with the ability to save the Additional Conditions for Transaction Execution, alphanumeric code, and created Authentication Artifacts, which were received from the Payer’s communicator. For this purpose, the server 102 contains at least one medium for recording data on it with the program instructions to the processor and the data about Additional Conditions for Transaction Execution and Authentication Artifacts. The server 102 also contains the processor capable of executing instructions recorded on the storage media, which describes the procedure of receiving and consequent storage in digital form of the data about Additional Conditions for Transaction Execution and Authentication Artifacts.
The module 103 for verification of Authentication Artifacts, alphanumeric code, and Additional Conditions for Transaction Execution is configured with the ability to compare the Authentication Artifacts and alphanumeric code received from the Payer’s communicator and the Authentication Artifacts and alphanumeric code received from the Recipient’s communicator. The verification module 103 may be configured as a separate hardware and software complex containing the processor capable of executing instructions recorded on storage media.
The public distributed ledger 104 of transactions is configured as a network of interconnected hardware and software complexes.
All components of the system are interconnected using modern means of communication.
Let us consider the implementation of the claimed method for executing a Digital Asset transfer transaction and the system operation using the following examples.
Example 1. Method for executing a Digital Asset transfer transaction
using electronic money as an example (Fig. 2, Fig. 3).
Processing servers 101 receive from the Payer’s communicator 105 a request for a Digital Asset transfer transaction as a certain amount of electronic money from the Payer to the Recipient (step 210). The step includes the authentication of the Payer in the system according to the Protocol (for example, by entering login and password). The communicator 105 interacts with the system using modern means of communication. The Recipient’s name (for example, John Smith) and the nominal value of the Digital Asset expressed as an amount of electronic money are received from the Payer’s communicator 105 (step 220).
Processing servers 101 receive from the Payer’s communicator 105 the transaction type (for example, private), alphanumeric code (for example, “12345pineapple”), and Additional Conditions for Transaction Execution. The Primary Authentication Artifact is received from the Payer’s communicator 105 (step 230). For example, the Additional Conditions for Transaction Execution may be the date of September 01, 2019 as well as the name of the city of Baden-Baden, from which the request to receive the transaction must be sent by the Recipient’s communicator 106.
To create the Primary Authentication Artifact, the Payer can use, for example, a postcard with the image of the Tower of Pisa. The Payer’s communicator 105 saves the postcard image as a digital graphic file, which, in addition to the image data, contains the Metadata related to the image.
The entered data are processed by the system, which use them to create a mathematical model with a specified error level. The Mathematical Model is a system of characteristic equations, coefficient tensors, and a set of initial conditions (configuration). The Primary Authentication Artifact is created by the system on the basis of the coefficient tensors, configuration, type (and/or the complexity) of the mathematical model, and the specified error level.
The Primary Authentication Artifact, alphanumeric code, transaction type, and Additional Conditions for Transaction Execution are uploaded and saved on the server 102 (step 240).
The information about the created transaction is saved in the public distributed ledger 104 as follows: the Recipient’s name, nominal value of the Digital Asset, and transaction type (step 250).
Processing servers 101 block the Digital Asset of the specified nominal value in the Payer’s account (step 260).
Then the message is sent to the Recipient’s communicator 106 about the physical object used to create the Primary Authentication Artifact, about the Additional Conditions for Transaction Execution, about the transaction identifier, and alphanumeric code (step 270).
The Processing servers 101 receive the request to receive the Digital Asset from the Recipient’s communicator 106 (step 310). At the same time, the Recipient is authenticated in the system according to the Protocol (for example, by entering login and password).
The processing servers 101 validate the received request and if its execution is possible, send the request for issuing the Authentication Artifacts to the artifact verification module 103, which, in turn, sends the request to the authentication artifact storage server 102. The server 102 sends the instructions for creating the Primary Authentication Artifact to the Recipient’s communication device 106. According to the received instructions, the Recipient’s communicator 106 sends the alphanumeric code “12345pineapple” to the verification module 103, reproduces the Primary Authentication Artifact on the basis of the postcard with the image of the Tower of Pisa and sends it to the verification module 103 as well (step 320).
The server 102 sends the Primary Authentication Artifact, which was received from the Payer’s communicator 105 and stored on it, to the verification module 103. The server 102 also sends the Additional Conditions for Transaction Execution stored on it to the verification module 103. Then, the Primary Authentication Artifact and Additional Conditions for Transaction Execution are verified in the verification module 103 (step 330). The Primary Authentication Artifact is verified by comparing the Primary Authentication Artifact received from the Peyer’s communicator 105 and the Primary Authentication Artifact received from the Recipient’s communicator 106.
The Additional Conditions for Transaction Execution are also verified in the verification module 103 (step 330). For this purpose, the date of September 01 , 2019 received from the Payer’s communicator 105 is compared with the current date, and the name of the city of Baden-Baden received from the Payer’s communicator 105 is compared with the data about the current geographic location of the Recipient’s communicator 106. If the Primary Authentication Artifact or at least one of the Additional Conditions for Transaction Execution is not verified, the transaction of crediting the Digital Asset is cancelled (step 340).
Upon successful verification of the Primary Authentication Artifact and the Additional Conditions for Transaction Execution, processing server 101 executes the transaction (step 350) by withdrawing the Digital Asset from the Payer’s account and crediting it to the Recipient’s account. Next, the information about the completed transaction is saved in the public distributed ledger 104 (step 360).
The message about the transaction completion is sent to the Payer’s communicator 105 and Recipient’s communicator 106. The server 102 designates the Authentication Artifacts as extracted and deletes them from its storage medium.
Example 2. Method for executing a Digital Asset transfer transaction in favor of an anonymous Recipient using electronic money as an example (Fig. 4,
Fig. 5).
Processing servers 101 receive from the Payer’s communicator 105 a request for a transaction of transferring the Digital Asset as a certain amount of electronic money from the Payer to the anonymous Recipient (step 410). The step includes the authentication of the Payer in the system according to the Protocol (for example, by entering login and password). The Payer’s communication device 105 interacts with the system using modem means of communication.
The system receives the data about the anonymous Recipient (for example, Anonymous or John Doe) and the nominal value of the Digital Asset expressed as an amount of electronic currency units from the Payer’s communicator 105 (step 420). The transaction type (for example, public), alphanumeric code (for example, “12345pineapple”), and Additional Conditions for Transaction Execution are received from the Payer’s communicator 105. The created Primary Authentication Artifact is received from the Payer’s communicator 105 (step 430). For example, the Additional Conditions for Transaction Execution may be the date of September 01, 2019, as well as the name of the city of Munich, from which the request to receive the transaction must be sent by the Recipient’s communicator 106.
To create the Primary Authentication Artifact, the Payer can use, for example, a photo of a half- full Coca-Cola glass bottle. The software of the Payer’s communication device 105 saves the image of the bottle as a digital graphic file, which, in addition to the image data, contains the Metadata related to the image. The entered data are processed by the system, which creates a mathematical model with a specified error level. The mathematical model is a system of characteristic equations, coefficient tensors, and a set of initial conditions (configuration). The Primary Authentication Artifact is created by the system on the basis of the coefficient tensors, configuration, type (and/or the complexity) of the mathematical model, and the specified error level.
To create the Secondary Authentication Artifact, for example, the“Yellow Submarine” song by the Beatles can be used, which was downloaded to the Payer’s communication device 105. The song is saved as a digital audio file, which, in addition to the audio data, contains the Metadata related to the audio record (step 440). The entered data are processed by the system, which creates a mathematical model with a specified error level. The mathematical model is a system of characteristic equations, coefficient tensors, and a set of initial conditions (configuration). The Secondary Authentication Artifact is created by the system on the basis of coefficient tensors, configurations of the type (and/or of the complexity) of the mathematical model, and the specified error level.
The Primary and Secondary Authentication Artifacts, alphanumeric code, transaction type, and Additional Conditions for Transaction Execution are uploaded and saved on the server 102 (step 450). The information about the created transaction is saved in the public distributed ledger 104 including the anonymous Recipient’s name, nominal value of the Digital Asset, and transaction type (step 460).
Then, Processing servers 101 block the Digital Asset of the specified nominal value in the Payer’s account (step 470).
Then the message is sent to the Recipient’s communicator 106 about the physical object used to create the Primary Authentication Artifact, about the song that was used for creating the Secondary Authentication Artifact, about the Additional Conditions for Transaction Execution, about the transaction identifier, and alphanumeric code (step 480). For example, the system may inform the Recipient by sending a personal message via SMS, e-mail or messenger. It is also possible to inform a large number of people by sending mass messages to their communicators. Such method of informing may be useful for conducting large- scale advertising campaigns and prize drawings, when it is not known in advance who exactly will be the Recipient.
Then, the processing servers 101 receive the request to receive the Digital Asset from the Recipient’s communicator 106 (step 510). At the same time, the Recipient is authenticated in the system according to the Protocol (for example, by entering login and password).
The Processing servers 101 validate the received request and if its execution is possible, send the request for issuing the Authentication Artifacts to the artifact verification module 103, which, in turn, sends the request to the authentication artifact storage server 102. The server 102 sends the instructions for creating the Primary and Secondary Authentication Artifacts to the communication device 106. In accordance with the received instructions, the Recipient’s communicator 106 sends the alphanumeric code “12345pineapple” and, using the software, reproduces the Primary and Secondary Authentication Artifacts on the basis of the photo of a half-full Coca-Cola glass bottle, the“Yellow Submarine” song by the Beatles, and the relevant Metadata. The Recipient’s communicator 106 sends the created Primary Authentication Artifact (step 520) and the created Secondary Authentication Artifact (step 530) to the verification module 103.
The server 102 sends the created Primary and the Secondary Authentication Artifacts, which were received from the Payer’s communicator 105 and stored on it, to the verification module 103. The server 102 also sends the Additional Conditions for Transaction Execution stored on it to the verification module 103. Then, the Primary and the Secondary Authentication Artifacts, and Additional Conditions for Transaction Execution are verified in the verification module 103 (step 540). The Primary Authentication Artifact is verified by comparing the Primary Authentication Artifact received from the Peyer’s communicator 105 and the Primary Authentication Artifact received from the Recipient’s communicator 106. The Secondary Authentication Artifact is verified by comparing the Secondary Authentication Artifact received from the Peyer’s communicator 105 and the Secondary Authentication Artifact received from the Recipient’s communicator 106.
The Additional Conditions for Transaction Execution are also verified in the verification module 103 (step 540). For this purpose, the date of September 01, 2019 received from the Payer’s communicator 105 is compared with the current date, and the name of the city of Munich received from the Payer’s communicator 105 is compared with the data about the current geographic location of the Recipient’s communicator 106.
If the Primary Authentication Artifact or the Secondary Authentication Artifact, or at least one of the Additional Conditions for Transaction Execution is not verified, the transaction is cancelled (step 550).
Upon successful verification of the Primary Authentication Artifact and the Additional Conditions for Transaction Execution, the processing server 101 executes the transaction (step 560) by withdrawing the Digital Asset from the Payer’s account and crediting it to the Recipient’s account. Next, the information about the completed transaction is saved in the public distributed ledger 104 (step 570).
The message about the transaction completion is sent to the Payer’s communicator 105 and Recipient’s communicator 106. The server 102 designates the Authentication Artifacts as extracted and deletes them from its storage medium.
Example 3. Method for executing a Digital Asset transfer transaction using Bitbon as an example (Fig. 6, Fig. 7).
Before transferring the Digital Asset as Bitbon, the procedure of Bitbon issuing is implemented. This procedure is described in detail by the applicant in the international application PCT/UA2017/000050 (publication date: 03.08.2017, international filing date: 27.04.2017).
The Processing servers 101 receive from the communicator 105 of the Payer (Bitbon owner) a request to transfer the Digital Asset as Bitbon from the Payer to the Recipient according to the Protocol (step 610). The Payer’s communicator 105 interacts with the system using modem means of communication.
The processing servers 101 receive from the Payer’s communicator 105 the Recipient’s name (for example, John Smith) and the nominal value of the Digital Asset expressed as an amount of Bitbon (step 620).
The transaction type (for example, private), alphanumeric code (for example, “12345pineapple”), and Additional Conditions for Transaction Execution are received from the Payer’s communicator 105; the Primary Authentication Artifact is also created (step 630). For example, the Additional Conditions for Transaction Execution may be the date of September 01 , 2019, as well as the name of the city of London, from which the request to receive Bitbon must be sent by the Recipient’s communicator 106. To create the Primary Authentication Artifact, for example, a photo of a cat statuette can be used, which is entered into the Payer’s communication device 105. The photo is saved as a digital image file, which, in addition to the image data, contains the Metadata related to the image. The entered data are processed by the system, which creates a mathematical model with a specified error level. The mathematical model is a system of characteristic equations, coefficient tensors, and a set of initial conditions (configuration). The Primary Authentication Artifact is created by the system on the basis of the coefficient tensors, configuration, type (and/or the complexity) of the mathematical model, and the specified error level.
Next, the Primary Authentication Artifact, alphanumeric code, transaction type, and Additional Conditions for Transaction Execution are saved on the server 102 (step 640).
The information about the created transaction is saved in the public distributed ledger 104 including the Recipient’s name, Bitbon nominal value, and transaction type (step 650).
Next, the Bitbon nominal value specified by the Payer is blocked in the Payer’s account (step 660).
Then, the message is sent to the Recipient’s communication device 106 about the physical object used to create the Primary Authentication Artifact, about the Additional Conditions for Transaction Execution, about the transaction identifier, and alphanumeric code (step 670).
The Processing servers 101 receive the request to receive the Digital Asset from the Recipient’s communicator 106 (step 710). At the same time, the Recipient is authenticated in the system according to the Protocol (for example, by entering login and password). The Processing servers 101 validate the Recipient’s request and if its execution is possible, send the request for issuing the authentication artifacts to the artifact verification module 103, which, in turn, sends the request to the authentication artifact storage server 102. The server 102 sends the instructions for creating the Primary Authentication Artifact to the Recipient’s communication device 106. According to the received instructions, the Recipient’s communication device 106 sends to the system the alphanumeric code “12345pineapple” and, using the software, reproduces the Primary Authentication Artifact on the basis of the cat statuette image and the Metadata of the image. The reproduced Primary Authentication Artifact is uploaded from the communicator 106 to the verification module 103 (step 720).
The server 102 sends the Primary Authentication Artifact, which was received from the Payer’s communicator 105 and stored on it, to the verification module 103. The server 102 also sends the Additional Conditions for Transaction Execution stored on it to the verification module 103. Then, the Primary Authentication Artifact and Additional Conditions for Transaction Execution are verified in the verification module 103 (step 730). The Primary Authentication Artifact is verified by comparing the Primary Authentication Artifact received from the Payer’s communicator 105 and the Primary Authentication Artifact received from the Recipient’s communicator 106.
Furthermore, the Additional Conditions for Transaction Execution are verified in the verification module 103 (step 730). For this purpose, the date of September 01, 2019 received from the Payer’s communicator 105 is compared with the current date, and the name of the city of London received from the Payer’s communicator is compared with the data about the current geographic location of the Recipient’s communicator.
If the Primary Authentication Artifact or at least one of the Additional Conditions for Transaction Execution is not verified, then the transaction is cancelled (step 740).
Upon successful verification of the Primary Authentication Artifact and the Additional Conditions for Transaction Execution, processing server 101 executes the Bitbon transaction (step 750) by withdrawing it from the Payer’s account and crediting it to the Recipient’s account. Next, the information about the completed transaction is saved in the public distributed ledger 104 (step 760).
The message about the transaction completion is sent to the Payer’s communicator 105 and Recipient’s communicator 106. The Authentication Artifacts on the server 102 are designated as extracted and are deleted.
The above examples of the use of the claimed method illustrate the possibilities of its implementation only and are not intended to limit the implementation scope of this method.

Claims

Claims
1. The method for executing a digital asset transfer transaction that comprises the consecutive:
receiving a request for a digital asset transfer transaction to a recipient from the payer’s communicator by the digital asset transfer system;
receiving the nominal value of digital asset and the recipient’s name whenever necessary from the payer’s communicator by the money transfer system; saving the transaction details in the digital asset transfer system, in particular the recipient’s name, nominal value of digital asset, transaction type, as well as the conditions transaction execution and authentication parameters;
receiving, by the digital asset transfer system, a request to receive the digital asset from the payer that was sent from the recipient’s communicator;
receiving, by the digital asset transfer system, authentication parameters from the recipient’s communicator;
verifying, by the digital asset transfer system, the authentication parameters received from the recipient’s communicator;
verifying the transaction execution conditions by the digital asset transfer system;
executing the transaction upon the successful verification or cancelling the transaction if the verification is failed; characterized in that: when receiving a request for a transaction of digital asset transfer to a recipient from the payer’s communicator by the digital asset transfer system, additional conditions for transaction execution, transaction type, alphanumeric code, and primary authentication artifact created using the physical object are additionally received from the payer’s communicator; created transaction details are saved in the public distributed ledger including the recipient’s name, nominal value of digital asset, and transaction type; the additional conditions for transaction execution, transaction type, alphanumeric code, and primary authentication artifact are saved in the system; digital asset of the specified nominal value is blocked in the payer’s account; the message is sent to the recipient’s communicator about the physical object used to create the primary authentication artifact, about the additional conditions for transaction execution, the transaction identifier, and alphanumeric code;
when the digital value transfer system receives the request from the recipient’s communicator to receive the digital asset, alphanumeric code and primary authentication artifact generated using the physical object are additionally received from the payer’s communicator; then the digital asset transfer system verifies the compliance with additional conditions for transaction execution that includes also comparing, by the system, the alphanumeric code received from the recipient’s communicator with the alphanumeric code received from the payer’s communicator, and comparing, by the system, the primary authentication artifact received from the recipient’s communicator with the primary authentication artifact received from the payer’s communicator;
the digital asset is withdrawn from the payer’s account and is credited to the recipient’s account;
the information about the executed transaction is saved in a public distributed ledger.
2. The method of claim 1, wherein the date and time of the transaction received from the payer’s communicator are used as additional conditions for transaction execution.
3. The method of claim 1, wherein the data on the desired time period of the transaction received from the payer’s communicator are used as additional conditions for transaction execution.
4. The method of claim 1, wherein the data on the geographic location of the recipient’s communicator received from the payer’s communicator are used as additional conditions for transaction execution.
5. The method of claim 1 , wherein a graphic image of any physical object processed by the payer’s communicator and metadata of this image are used to create the primary authentication artifact.
6. The method of claim 1, wherein a series of graphic images of any physical object processed by the payer’s communicator and metadata of these images are used to create the primary authentication artifact.
7. The method of claim 1, wherein additionally, when the digital asset transfer system receives the request for executing a digital asset transfer transaction to the recipient from the payer’s communicator, the secondary authentication artifact created by the payer’s communicator is uploaded and saved in the system, and then a message about it is sent to the recipient’s communicator; when the digital asset transfer system received the request for receiving a digital asset from the recipient’s communicator, the secondary authentication artifact created by the recipient’s communicator is uploaded in the system, and then the system compares the secondary authentication artifact received from the recipient’s communicator and the secondary authentication artifact received from the payer’s communicator.
8. The method of claim 7, wherein an audio record received from the payer’s communicator and metadata of this audio record are used to create the secondary authentication artifact.
9. The method of claim 7, wherein a video record received from the payer’s communicator and metadata of this video record are used to create the secondary authentication artifact.
10. The method of claim 7, wherein a text received from the payer’s communicator and metadata of this text are used to create the secondary authentication artifact.
11. The method of claim 1 or 7, wherein, when the digital asset transfer system receives a request to execute a digital asset transfer transaction to the recipient from the payer’s communicator, an anonymous recipient is entered in the recipient’s name field.
PCT/UA2020/000004 2019-06-18 2020-01-21 Method for executing a digital asset transfer transaction WO2020256680A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
UAU201906837 2019-06-18
UAU201906837 2019-06-18

Publications (1)

Publication Number Publication Date
WO2020256680A1 true WO2020256680A1 (en) 2020-12-24

Family

ID=74037518

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/UA2020/000004 WO2020256680A1 (en) 2019-06-18 2020-01-21 Method for executing a digital asset transfer transaction

Country Status (1)

Country Link
WO (1) WO2020256680A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113935735A (en) * 2021-09-24 2022-01-14 星矿科技(北京)有限公司 Block chain-based digital asset transfer method

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160071097A1 (en) * 2014-09-05 2016-03-10 Silouet, Inc. Payment system that reduces or eliminates the need to exchange personal information
US20160110696A1 (en) * 2014-10-15 2016-04-21 Mastercard International Incorporated Bottom of the pyramid pay method and system
WO2016186869A1 (en) * 2015-05-21 2016-11-24 Mastercard International Incorporated Method and system for integration of market exchange and issuer processing for blockchain-based transactions
US20170048235A1 (en) * 2015-07-14 2017-02-16 Fmr Llc Crypto Captcha and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
WO2017171733A1 (en) * 2016-03-28 2017-10-05 Black Gold Coin, Inc. Systems and methods for providing block chain-based multifactor personal identity verification
WO2017196289A2 (en) * 2017-04-25 2017-11-16 Tovarystvo Z Obmezhenoiu Vidpovidalnistiu "Simcord" The method for executing a digital value transfer transaction and the digital value transfer system for its implementation

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160071097A1 (en) * 2014-09-05 2016-03-10 Silouet, Inc. Payment system that reduces or eliminates the need to exchange personal information
US20160110696A1 (en) * 2014-10-15 2016-04-21 Mastercard International Incorporated Bottom of the pyramid pay method and system
WO2016186869A1 (en) * 2015-05-21 2016-11-24 Mastercard International Incorporated Method and system for integration of market exchange and issuer processing for blockchain-based transactions
US20170048235A1 (en) * 2015-07-14 2017-02-16 Fmr Llc Crypto Captcha and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
WO2017171733A1 (en) * 2016-03-28 2017-10-05 Black Gold Coin, Inc. Systems and methods for providing block chain-based multifactor personal identity verification
WO2017196289A2 (en) * 2017-04-25 2017-11-16 Tovarystvo Z Obmezhenoiu Vidpovidalnistiu "Simcord" The method for executing a digital value transfer transaction and the digital value transfer system for its implementation

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113935735A (en) * 2021-09-24 2022-01-14 星矿科技(北京)有限公司 Block chain-based digital asset transfer method

Similar Documents

Publication Publication Date Title
US12033145B2 (en) Systems and methods for facilitating account verification over a network
US11151546B2 (en) Trigger peer to peer payment with financial cards and phone camera
US20230134838A1 (en) User verification system and method based on restricted url opening on browser of user device
US8285640B2 (en) System and methods for facilitating fund transfers over a network
US11636479B2 (en) Computer-implemented system and method for performing social network secure transactions
US8893229B2 (en) Focus-based challenge-response authentication
US20190295083A1 (en) The method for executing a digital value transfer transaction and the digital value transfer system for its implementation
CN105389488B (en) Identity identifying method and device
CN110322317B (en) Transaction data processing method and device, electronic equipment and medium
CN104967553B (en) Method for message interaction and relevant apparatus and communication system
Shulman The underground credentials market
CN106161183B (en) Method for message interaction and social interaction server device and communication system
US11227220B2 (en) Automatic discovery of data required by a rule engine
WO2020256680A1 (en) Method for executing a digital asset transfer transaction
US20100153275A1 (en) Method and apparatus for throttling access using small payments
CA2998543A1 (en) Processing method for obtaining target data, server, and online financing method
US20220245628A1 (en) Secure Transactions Over Communications Sessions
CN111915109B (en) Medical funding device, system and method
WO2020256681A1 (en) Digital asset transfer system
Kho et al. How to Bitcoin
UA137352U (en) METHOD OF TRANSACTION FOR DIGITAL ASSET TRANSFER
CN110610367A (en) Transaction data payment method and device, electronic equipment and server
KR102522981B1 (en) Blockchain-based Smishing Prevention method and apparatus thereof
US20240364723A1 (en) Content-oblivious fraudulent email detection system
US20240005325A1 (en) Using a conversation interface to transfer digital assets

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20827223

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20827223

Country of ref document: EP

Kind code of ref document: A1