WO2020104961A1 - Systems and methods relating to cryptocurrencies - Google Patents
Systems and methods relating to cryptocurrenciesInfo
- Publication number
- WO2020104961A1 WO2020104961A1 PCT/IB2019/059970 IB2019059970W WO2020104961A1 WO 2020104961 A1 WO2020104961 A1 WO 2020104961A1 IB 2019059970 W IB2019059970 W IB 2019059970W WO 2020104961 A1 WO2020104961 A1 WO 2020104961A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- user
- cryptocurrency
- amount
- payment
- administrator
- Prior art date
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/38—Payment protocols; Details thereof
- G06Q20/381—Currency conversion
-
- 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]
- G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
-
- 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/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
- G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
-
- 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/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- 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/08—Payment architectures
- G06Q20/18—Payment architectures involving self-service terminals [SST], vending machines, kiosks or multimedia terminals
-
- 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
- G06Q20/3825—Use of electronic signatures
-
- 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
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
-
- 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/403—Solvency checks
- G06Q20/4037—Remote solvency checks
-
- 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/405—Establishing or using transaction specific rules
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Definitions
- This invention relates to various systems and methods which enable transacting in cryptographic currencies.
- the invention relates to a closed ecosystem for managing and facilitating cryptocurrency-based transacting between various parties forming part of the ecosystem, a cryptocurrency ATM with which amounts of currencies can be exchanged and purchased, a payment system which enables third parties to pay for goods and/or services produced or rendered by users of the system, utilising amounts of cryptocurrency-based currencies, and an electronic commerce gateway which allows users to purchase items electronically utilising cryptocurrencies.
- blockchain-based currencies also known as cryptographic currencies or“cryptocurrencies”
- cryptocurrencies are valued for their inherent security and (relative) anonymity.
- its link to the blockchain renders transactions immutable.
- the identities of payers and payees transacting by way of cryptocurrencies may remain private.
- cryptocurrencies provide an attractive prospect due to its decentralised and non-regulated nature.
- cryptocurrencies are not linked to a specific geographical or economical region. Consequently, the value of the currency is not influenced by political or other economic factors of a specific area or region, a fact that is of particular value in developing countries, where instability often causes inflation to spiral out of control, and where the value of fiat currencies becomes especially volatile. Rather, the value of cryptocurrencies is determined by supply and demand by a global audience.
- cryptocurrency-based transactions are generally associated with delayed transaction times. This can for the most part be attributed to the time and computer processing required to verify and update the blockchain. Typically, these transaction times range between 10 and 30 minutes in some cases. Compared to conventional fiat transaction times, which have transaction delays in the nano-second sphere, trading in cryptocurrencies remains impractical or even risky to some vendors or purveyors.
- an e-commerce system or gateway that allows users to pay for goods and services utilizing cryptocurrencies (even in cases where e-commerce service providers do not yet facilitate the use of cryptocurrencies).
- a system for facilitating a transfer of an amount of cryptocurrency from a first known entity to a second known entity comprising a private blockchain comprising a database of user profiles, each user profile associated a specific known entity and with a unique smart contract for storing frontend and backend data relating to the specific known entity; and a user interface for receiving inputs and displaying frontend data stored on the smart contracts, wherein, in use, backend data relating to the second known entity is retrieved from the specific user’s smart contract, and utilised to effect a transfer of the amount of cryptocurrency from the first user to the second user.
- Each known entity may be associated with a processing module, which may be provided in communication with the private blockchain.
- the user interface may be provided for: receiving, from the first known entity, an input relating to the second known entity;
- a processing module may be provided for:
- the processing module may be provided in communication with an exchange for exchanging fiat currency to cryptocurrency or for exchanging cryptocurrency to fiat currency.
- the private blockchain may be decentralised.
- the frontend data may comprise at least some of: a name of the entity
- the backend data may comprise at least some of:
- a governing body for managing and controlling the system.
- the governing body may prescribe the functioning of the processing module.
- the receive address may be generated by utilising API keys associated with the governing body.
- the system may be provided in communication with a crypto ATM for enabling a user to exchange amounts of fiat-based currency for amounts of cryptocurrency and/or amounts of a cryptocurrency for amounts of another cryptocurrency, and thereby to increase a cryptocurrency balance associated with the user.
- the crypto ATM may furthermore be provided to extract amounts of cryptocurrency from the cryptocurrency balance of the user, and convert the extracted amount to a fiat-based amount.
- the system may be provided with communication means for communicating with public blockchains, associated with known cryptocurrencies.
- the receive address may be generated in a format compatible with a specific cryptocurrency.
- a method of transferring an amount of cryptocurrency from a first known entity to a second known entity comprising the steps of:
- the method may comprise the further step of utilising the backend data of the identified specific user to generate a payment address (or“receive address”) through an API key.
- the payment address may be utilised to transfer the preselected amount of cryptocurrency from the first user to the second user.
- the method may comprise the further step of verifying that the transfer has been made, by prompting a public blockchain associated with the cryptocurrency that was transferred.
- the public blockchain may be prompted by utilising the payment address (or receive address) as input.
- the transfer may be verified by comparing a balance associated with the payment address (or receive address) with the amount that was intended to be transferred from the first entity to the second entity.
- the method may furthermore comprise the step of generating a record of the transfer and storing the record on the private blockchain.
- the record may be encrypted before being stored on the private blockchain.
- the record may be processed by a hash algorithm before being stored on the blockchain.
- the record of the transfer may be utilised to monitor movements in the user’s cryptocurrency balance.
- the method may include preventing a user from transferring an amount of cryptocurrency to an unknown entity which is not associated with a user profile on the private blockchain.
- the method may limit a total amount of cryptocurrency that a user may transfer to unknown entities, within a predetermined time.
- the predetermined time may be one of a daily period, a weekly period, a monthly period, and an annual period.
- the method may include the step of monitoring and recording amounts of cryptocurrency transferred by each user to unknown entities.
- processor module and a memory arrangement associated with the administrator, the processor module provided in communication with the memory arrangement, the memory arrangement comprising a database of user profiles;
- the processor module is provided in communication with a cryptocurrency-fiat exchange or a first cryptocurrency-second cryptocurrency exchange, for determining in real time, a cryptocurrency-fiat exchange rate or the first cryptocurrency-second cryptocurrency exchange rate, and for trading fiat amounts or first cryptocurrency amounts for second cryptocurrency amounts.
- the processor module may determine an initial second cryptocurrency amount associated with the fiat amount or the first cryptocurrency amount, and a subsequent second cryptocurrency amount associated with the initial second cryptocurrency amount, and wherein the processor module may effect a transfer of the subsequent second cryptocurrency amount from the balance amount, to the first user.
- the subsequent second cryptocurrency amount may be transferred from the balance of the second cryptocurrency and may precede the trading of the fiat amount or the first cryptocurrency amount for a second cryptocurrency amount.
- the input module may be one of a personal or laptop computer, a mobile device such as a smartphone, tablet or the like.
- the input module may communicate with the processor via a known wireless communication medium or network.
- a fourth aspect of the invention there is provided a method for an administrator to facilitate, on behalf of a first user, the conversion of a fiat amount or a first cryptocurrency amount to a second cryptocurrency amount, the method comprising the steps of:
- the initial second cryptocurrency amount may be determined by retrieving from the exchange a fiat-second cryptocurrency exchange rate or a first cryptocurrency-second cryptocurrency exchange rate.
- the subsequent second cryptocurrency amount may be determined by deducting from the initial second cryptocurrency amount, a reserve amount to account for exchange rate fluctuations.
- the final second cryptocurrency amount may be an actual second cryptocurrency amount received from the exchange, in exchange for the fiat amount or first cryptocurrency amount.
- the administrator may receive from the first user a payment address (or “receive address”) that may be used to transfer the subsequent second cryptocurrency amount to the first user.
- the method may include the step of verifying the correctness of the payment address or the format of the payment address, considering the type of cryptocurrency required by the first user.
- Data relating to the conversion of the fiat amount or the first cryptocurrency to the second cryptocurrency amount may be stored on a profile relating to the first user.
- the trading of the fiat amount or the first cryptocurrency amount for the final second cryptocurrency amount may be deferred based on prevailing and historic second cryptocurrency-fiat currency exchange rate data or prevailing and historic second cryptocurrency-first cryptocurrency exchange rate data.
- a payment system with which an administrator receives, on behalf of a user, cryptocurrency-based payments from a third party, the system comprising: a processing module associated with the administrator; a memory arrangement provided in communication with the processing module, the memory arrangement having stored thereon a database of user profiles, each user profile associated with a specific one of a plurality of registered users;
- the input module provides the user with access to the user interface to act as a point of sale associated with the user, and wherein the point of sale enables the third party to transfer cryptocurrency to the system.
- the system may furthermore comprise a fiat-based banking account, managed by a commercial bank, and associated with the administrator.
- Each user profile may comprise at least some of:
- the system may comprise an online user interface for communicating with the respective users.
- a sixth aspect of the invention there is provided a method for an administrator to receive, on behalf of a user, a cryptocurrency-based payment from a third party, the method comprising the steps of:
- the method may comprise the step of receiving from the user, an input relating to the completion, by the third party, of the transfer.
- the method may comprise the further step of verifying that the transfer was successfully effected.
- the verification may comprise providing to a blockchain associated with the cryptocurrency, the payment address as an input parameter.
- the transaction amount may be fiat-based and the method may furthermore comprise the step of converting the fiat-based amount to a cryptocurrency- based amount so that the payment amount may be a cryptocurrency-based amount.
- the transaction amount may be converted by retrieving a cryptocurrency-fiat currency exchange rate from an exchange.
- the payment amount may be determined by adding a buffer fee to the transaction amount to account for exchange rate fluctuations.
- the method may comprise the further steps of:
- the fiat-based amount or different type of cryptocurrency-based amount may comprise the transaction amount owed to the user.
- the method may comprise the further step of trading a portion of the buffer fee to account for a shortfall between the fiat-based amount or the different type of cryptocurrency-based amount received on behalf of the user and the amount owed to the user.
- the method may furthermore comprise the step of storing data relating to the transaction on a user profile associated with the user, and updating a cryptocurrency balance and/or fiat balance associated with the user profile.
- the method may furthermore comprise the step of transferring an amount equal to the fiat balance stored on the user profile to a commercial bank account associated with the user.
- an extension module for retrieving a URL relating to a specific page of a domain, which page is identified by the first user
- a processor module for scraping relevant information from the specific page, for displaying the scraped information via a user interface to the first user and for providing input to a cryptocurrency payment processor;
- At least a first bot for receiving information relating to an order placed by the first user and information relating to the first user, and utilizing the received information to place an order with the electronic commerce service provider on behalf of the first user.
- the domain may be controlled by the electronic commerce service provider.
- the administrator may be a registered user with the electronic commerce service provider
- the extension module may comprise a web extension installed on a web browser utilised by the first user.
- the user interface may provide means for the first user to provide input relating to the displayed information, thereby to edit information relating to the order before placing the order.
- the user interface may comprise a cart table for displaying the relevant information scraped from the specific page.
- a method for an administrator to process and place an order with an electronic commerce service provider on behalf of a first user associated with a first user profile including the steps of:
- the domain may be controlled by the electronic commerce service provider.
- the administrator may be a registered user with the electronic commerce service provider.
- the relevant information may relate to a product and a price charged by the electronic commerce service provider.
- the price may be fiat-based.
- the first user may provide the input through an extension module which may be installed on a web browser utilised by the first user.
- the extension module may, in real time, monitor activity of the first user on the specific page.
- the method may comprise the step of storing the URL in a background script stored on a memory arrangement associated with the administrator.
- the method may include utilising bots associated with a processing module of the administrator, to place the order with the electronic commerce service provider.
- the payment received from the first user may be a cryptocurrency-based payment.
- the method of receiving payment from the first user may comprise providing to a payment system in accordance with the fifth aspect of the invention (in which case the administrator is a user of the payment system in accordance with the fifth aspect of the invention), the price charged by the electronic commerce service provider, and providing to the first user, information relating to the price and a payment address generated by the method (in accordance with the method of the sixth aspect of the invention) on behalf of the administrator.
- figure 1 is a diagrammatic representation of a closed ecosystem for facilitating and monitoring cryptocurrency transactions between known entities, according to the invention
- figure 2 is a diagrammatic representation of a private blockchain forming part of the closed ecosystem of figure 1
- figure 3 is a flow diagram setting out a process of registration of a user of the ecosystem of figure 1
- figure 4 is a flow diagram setting out a process of transferring amounts of cryptocurrency between known entities or users within the ecosystem of figure 1 (split between figures 4A and 4B forming a unit)
- figure 5 is a flow diagram outlining a payment processing step of the ecosystem of figure 1
- figure 6 is a flow diagram setting out a process of transferring funds out of the ecosystem of figure 1 (split between figures 6A and 6B forming a unit)
- figure 7 is a diagrammatic representation of a crypto ATM which forms part of the ecosystem of figure 1 , but which could also be used outside thereof
- figure 8 is a flow diagram setting out
- figure 19 is a flow diagram setting out a process with which a user of the e-commerce gateway of figure 18 adds items to a cart table which forms part of the gateway of figure 18;
- figure 20 is a flow diagram setting out a process with which a user of the e-commerce gateway of figure 18 confirms and places an order, relating to items previously added to its cart table, in accordance with the process outlined in figure 19;
- figure 21 is a flow diagram setting out a process with which the URLs scrape relevant information from the webpage via an API;
- figure 22 is a flow diagram setting out a process by which payment is made for orders confirmed accordance with figure 20 by the e-commerce gateway of figure 18;
- figure 23 is a flow diagram setting out a process by which orders confirmed and placed in accordance with figure 20 is processed by the e-commerce gateway of figure 18;
- figure 24 is a flow diagram setting out a process with which a first user of the ecosystem elects the manner in which to pay or transfer cryptocurrency to a second user or electronic commerce service
- API “application programming interface”. An API is a set of functions and procedures that allow the creation of applications which access the features or data of an operating system, application, or other service.
- API Key A code or set of instructions used to track and control the use of an API.
- API keys of an administrator it will be understood that the API keys allows the administrator to perform certain tasks on the exchange, by using the API keys.
- the API keys are associated with certain permissions or restrictions, that allow prevent certain tasks from being executed.
- Blockchain A digital distributed ledger relating to a chronologic chain of recorded events, such as transactions of cryptocurrencies and the like.
- Bot An autonomous program forming part of a network or system which can interact with systems, users or components of the network or system, in order automatically to execute predetermined tasks.
- Cryptocurrency Cryptographic currency or blockchain-based currency.
- Crypto ATM A software-based automated cryptocurrency purchaser as better defined by the third and fourth aspects of the invention and more fully described below with reference to numeral 20 in the figures.
- Node A device forming part of a blockchain network that performs certain predetermined actions in respect of the blockchain.
- URL A uniform (or universal) resource locator, that serves as an address of a webpage.
- Smart contract A computer protocol intended to digitally facilitate, verify, or enforce the negotiation or performance of a contract. Smart contracts allow the performance of credible transactions without third party intervention.
- the term“crypto” will be understood to refer to any or all of“cryptographic”,“cryptographic currency”,“cryptographic-based currency” and/or an amount of a cryptographic-based currency, as will become apparent from the context of each specific instance or use.
- a closed ecosystem for facilitating and monitoring cryptocurrency transactions between known entities is indicated by reference numeral 10 in figure 1.
- the closed ecosystem 10 is governed and controlled by an administrator or governing body 12.
- the ecosystem 10 comprises a decentralised and private blockchain 14 (which is made up of a network of nodes (not shown)).
- the private blockchain 14 may run on a known software platform, such as Ethereum.
- a user interface 16 is built on top of the blockchain 14.
- the ecosystem 10 is associated with a commercial banking account 18 (in fiat currency) and a “Crypto ATM” 20 (which is described in more detail below).
- the ecosystem 10 is associated with a number of users or known entities 22 (such as a first user 22.1 and a second user 22.2).
- the users communicate with the ecosystem 10 through modules 24 (such as a first module 24.1 associated with the first user 22.1 and a second module 24.2 associated with the second user 22.2) through known communication means 26, which enables the users 22 access to the user interface 16.
- the modules 24 may for instance comprise laptop or personal computers, smart devices such as smart phones and the like, while the communication means 26 may comprise wireless communication networks, wired communication media and the like.
- the ecosystem 10 may communicate, through communication means which will be apparent for those skilled in the art, with various public blockchains 28 (such as a first public blockchain 28.1 , a second public blockchain 28.2, a third public blockchain 28.3, an nth public blockchain 28. n and the like).
- Each of the public blockchains 28 may be associated with a known cryptocurrency, such as Bitcoin, Litecoin and the like.
- the ecosystem 10 may furthermore communicate with an exchange 30 which may be used to trade fiat currencies for cryptocurrencies, cryptocurrencies for a different type of cryptocurrencies, or cryptocurrencies for fiat currencies in known fashion.
- the ecosystem 10 communicates with the exchange 30 through the crypto ATM 20.
- the public blockchains 28 as well as the exchange 30 operate separately and independently from the private blockchain 10, in the sense that entities not associated with the ecosystem 10 may interact with these blockchains 28 and the exchange 30 without interacting with the ecosystem 10.
- a database of user profiles 32 is stored on the private blockchain 14.
- Each user or entity 22 is associated with a separate user profile 34 (such as a first user profile 34.1 , a second user profile 34.2 and the like) which is stored in the database 32.
- Each user profile 34 is associated with a smart contract 36, which stores frontend and backend data relating to certain information of the user 22 (it will be understood that the frontend data of various users 22 may be displayed through the user interface 16, and that a first registered user 22.1 may for instance gain access to the front end data of a second registered user 22.2, whereas the backend data is not accessible to any of the users 22).
- the data may vary based on the type of person (such as a natural person, a business etc.). Typically, the data relates to at least some of the following:
- a name 36 and a surname 38 in the case of a natural person
- tradename in the case of a business
- an identification number 40 (such as an ID or social security number, a passport number, or other identification number used in a particular country) (in some cases, where the ecosystem is used on a smaller scale, the identification number 40 may relate to a membership number, employee number, policy number or the like);
- contact information 42 (such as a cellphone number, email address, office phone number, fax number and the like);
- address information 44 (such as a physical address) (which address information 44 may in some cases need to be verified by an independent third party);
- wallet or plurality of wallet address(es) 46 (which wallet, or plurality of wallets, is used for storing amounts of cryptocurrencies, and which will be discussed in more detail below);
- a private key(s) 50 a private key(s) 50; a crypto balance(s) 52; and
- the transaction record 54 comprises a record of encrypted and processed data relating to all transactions and cryptocurrency balance movements associated with a specific user.
- the information relating to the identity of the user or entity 22 may be prescribed by a governing authority tasked with regulating information aimed at preventing corruption (for instance, in South Africa, the required information is prescribed by the Financial Intelligence Centre Act (FICA)).
- FICA Financial Intelligence Centre Act
- a user 22 creates a user profile 34 on the ecosystem by creating login details (such as a username and a password) (shown at 82). In this way the user may obtain access to the ecosystem 10 through various modules 24. Two-factor authentication is however required when a user 22 logs into the ecosystem 10. The user 22 then submits relevant information (shown at 84), such as data items 36 to 44 mentioned above which is stored in the smart contract (shown at 86) associated with the user profile 34. Provision is made for the authentication (shown at 87) of some of the information as may be required (such as by way of one-time pins to authenticate a cell phone number, confirmatory emails and the like).
- the wallet address(es) 46, public key(s) 48 and private key(s) 50 are generated on behalf of the client (through API keys associated with the administrator or governing entity 12) and stored in the smart contract on the private blockchain 14 (at 90).
- This data (backend data) is never displayed on the user interface 16, and the user 22 can never gain access thereto.
- the user 22 is notified of successful registration on the system 10 (at 92).
- the user 22 has no amount of cryptocurrency within the ecosystem 10, and the user’s crypto balance 52 will therefore be zero.
- the only way in which amounts of cryptocurrency is allowed to enter the ecosystem 10 is through the crypto ATM 20 (the process of cryptocurrencies entering or leaving the ecosystem through the crypto ATM 20 is discussed more fully below).
- the crypto ATM 20 has inherent security features which enables it to authenticate the origin of amounts of cryptocurrencies. Since there is only a single point of entry or exit for cryptocurrencies into or from the ecosystem 10, and since this entry point enables the authentication of the sources of these amounts, all cryptocurrencies within the ecosystem 10 at any point in time may be well regulated and monitored by the governing or regulatory body 12.
- the transfer process 100 is initiated by the first user 22.1 by logging in (at 102) to the ecosystem 10 through its module 24.1 , by utilising its login credentials. As mentioned, two-factor authentication is utilised to verify the credentials and identity of the first user 22.1.
- the user interface 16 will therefore now be displayed in the module 24.1.
- the user interface comprises a search function of the known kind.
- the first user 22.1 searches (at 104) for the second user 22.2.
- the first user 22.1 therefore provides input data relating to the identity of the second user 22.2.
- the input data relating to the identity of the second user 22.2 will not relate to a receive address or a wallet address of the second user 22.2. Instead, the input data relates to the name 36.2 and/or surname 38.2 (or the name of an entity in the case of a business or other entity).
- the ecosystem comprises a search function of the known kind.
- the first user 22.1 searches (at 104) for the second user 22.2.
- the first user 22.1 therefore provides input data
- the first user 22.1 may now opt to end the process (at 1 12) or refine its search query by providing different input data (at 104). In this way, the ecosystem 10 prevents the transfer of amounts of cryptocurrency to parties outside of the ecosystem 10.
- a list of relevant user profiles is compiled and displayed (at 1 14) to the first user 22.1 via the user interface 16. Only relevant information (frontend information) (excluding wallet addresses 46, public keys 48, private keys 50, crypto balances 52 and transaction records 54) relating to the various identified user profiles 34 is displayed.
- the first user 22.1 evaluates the list (at 1 16) to ascertain whether the correct second user 22.2 appears on the list. If not, the first user 22.1 may opt to end the transfer process (at 1 12) or return to the search function (at 104) to refine the search by providing alternative inputs.
- the first user 22.1 selects the second user 22.2 and selects an option to pay (at 1 18) the second user 22.2.
- backend data (including at least some of the wallet address 46.2, public key 48.2 and private key 50.2) is retrieved (at 120) from the smart contract associated with the second user profile 34.2.
- the backend data is utilised to generate a receive address (at 122) on behalf of the second user 22.2.
- the receive address is not displayed at any point to the first user 22.1.
- the first user 22.1 enters an amount of cryptocurrency (at 124) (and may enter a reference for identification purposes) and relevant fees or taxes (as elaborated on more fully below) is added to the amount (at 126) to arrive at a total amount of cryptocurrency required to complete the transaction.
- the first user’s 22.1 crypto balance 52.1 is retrieved (at 128) and evaluated (at
- the first user is prompted to re- enter an amount to be transferred (at 124), directed to the crypto ATM to acquire more cryptocurrency (at 132) or the process is ended (at 1 12).
- the transaction is processed (at 134).
- the transaction is conducted in a first cryptocurrency, associated with the first public blockchain 28.1.
- the processing of the transaction (134) is conducted in known fashion, by making use of the backend data (such as the wallet addresses 46, public keys 48 and private keys 50) of the first and second users (22.1 , 22.2) and the receive address generated on behalf of the second user 22.2.
- the transaction is recorded on the first public blockchain 28.1 in known fashion.
- the ecosystem 10 queries whether the transaction was successful (at 136)
- the query 136 is conducted by utilising the “receive address” to query (shown at 137) the public blockchain 28 to receive a balance (at 139).
- This balance received at 139 is compared (at 141 ) to the amount entered by the first user 22.1 to be transferred to the second user 22.2. If these amounts are not equal, the first user 22.1 is provided with a notification (shown at 143) indicating a failed transaction, and again prompted to commence with the process by entering (at 124) a suitable amount of cryptocurrency to transfer to the second user 22.2.
- the amount in cryptocurrency is transferred (at 138) to the second user 22.2, the crypto balances (52.1 , 52.2) of the first and second users (22.1 , 22.2) are updated (at 140), the private blockchain 14 is updated (at 142) (all the nodes of the private blockchain 14 are notified) and the first and second users (22.1 , 22.2) are notified of the successful transfer (at 144).
- the transaction is recorded, and a record of the transfer is encrypted and processed (typically through a hash algorithm) and stored in the first and second users’ (22.1 , 22.2) transaction records (54.1 , 54.2) on their respective smart contracts.
- a user 22 might need to transfer an amount of cryptocurrency to a third party that does not form part of the ecosystem 10
- the smart contract associated with each user profile 34 contains an allowance 56, which is a predetermined amount of cryptocurrency that may be transferred from the ecosystem 10, to third parties outside of the ecosystem 10.
- the allowance 56 is defined for a specific, predetermined period, and is typically regulated by the governing body 12. The period may typically be an annual period, but other periods, such as daily, weekly and monthly allowances may also be provided for.
- the transfer process 160 is again initiated by the first user 22.1 by logging in (at 102) to the ecosystem 10 through its module 24.1 , by utilising its login credentials. From the user interface 16 the first user 22.1 submits a request
- the first user enters as an input to the system an amount 163 that it wishes to transfer 160 from the ecosystem 10.
- the first user s 22.1 allowance 56.1 and crypto balance 52.1 are retrieved (at 164) from the smart contract associated with the user profile 34.1 , which is stored on the private blockchain 14.
- the system firstly (at 166) determines whether the allowance is positive. If the allowance 56.1 is positive, the system secondly (at 168) determines whether the allowance exceeds the requested amount 163 to be transferred 160 from the ecosystem 10. If the allowance 56 is not positive (at 166), or does not exceed the requested amount 163 (at 168), the request is rejected
- the first user 22.1 may now submit a special clearance request (at 174) to the governing body 12 to allow the transfer of the funds 160 from the ecosystem 10.
- the governing body 12 may consider this request in terms of a predetermined regulation, and may stipulate certain conditions in terms of which the transfer 160 may be allowed (such as special tax provisions, central bank approval, etc.).
- the amount 163 is compared (at 175) with the crypto balance 52.1. If the crypto balance 52.1 exceeds the amount 163, the transaction is allowed (at 176), and executed (at 178) in known fashion.
- the third party 58 will have a wallet address 60, public key 62 and private key 64 (none of which are in any way connected with the ecosystem 10).
- a receive address will be generated by the third party 58 in known fashion and the amount 163 will be transferred in known fashion from the first user 22.1 to the third party 58.
- the transfer 160 will be recorded (at 180) on the public blockchain 28.1 associated with the specific cryptocurrency (in this case the first cryptocurrency) in known fashion.
- the first user 22.1 will be notified (at 182) of the successful transfer 160, and the first user’s 22.1 crypto balance 52.1 and allowance 56.1 will be adjusted (at 184) and a record of the transaction will be encrypted, processed and stored (at 186) as described above.
- the first user 22.1 is directed (at 177) to the crypto ATM 20 to increase its crypto balance
- the first user may opt to end (at 179) the transfer 160.
- the system 10 will be able to authorise transactions undertaken by a user 22, by utilising the private key 50 as a signature. Even though the user 22 cannot access the private key 50 personally through the user interface 16, the system 10 will only be able to extract and utilise the private key 50 to authorise transactions during a session initiated by the user 22 having validly logged into its account 34. It will also be understood that each transfer of an amount of cryptocurrency to a user 22 is associated with a“receive address” that was generated for the transfer. All of the“receive addresses” relevant to a specific user 22 of the system 10 is stored on the smart contract associated with the user profile 34. The receive addresses stored on the smart contract may be used to query the relevant public blockchain 28 to confirm the balances of the user 22. All transactions undertaken by the system 10 are immutable. A reconciliation of a user’s 22 crypto balances 52 may periodically (such as weekly, monthly, quarterly, biannually or annually) be completed.
- the ecosystem 10 facilitates easy transfers of cryptocurrency between known users of the system 10.
- the governing body 12 is provided with access to the transaction records 54 of all the users 22, and can monitor fluctuations in the crypto balances 52 of the users 22.
- the ecosystem 10 furthermore provides a means of ensuring the legitimacy of all the cryptocurrencies within the ecosystem (as the origin of the cryptocurrencies are known).
- the ecosystem 10 furthermore regulates the transfer of cryptocurrencies out of the ecosystem. In this way, the governing body 12 may be able to levy taxes on transactions, or even income received by the users 22 within the ecosystem 10 (similar to the way in which conventional revenue services (such as the South African Revenue Service (SARS)) levies taxes on income).
- SARS South African Revenue Service
- users 22 of the ecosystem 10 will still enjoy inherent benefits of transacting in cryptocurrency, instead of in fiat currency. It will be appreciated that the ecosystem 10 may have a vast number of users 22, and may ultimately constitute an economy on its own, in which amounts of cryptocurrencies are transferred between users in exchange for goods or services. The bounds of the ecosystem 10 may for instance coincide with the borders of a country, and wherein it is required that users
- the governing body 12 may be a government. Even though the governing body 12 has access to information stored on the private blockchain 14, and may use the information for regulatory purposes, the governing body 12 does not have the power to change any information relating to past transactions stored on the private blockchain 14. All of this information is furthermore encrypted. A consensus mechanism may furthermore be used to verify past transactions. Since a complete record of transactions is available, fraudulent activities can much easier be identified and traced.
- the transaction records comprise hashes used for identification, and show addresses as aforementioned.
- the ecosystem 10 may be scaled down to a much smaller scale, wherein the governing body 12 may for instance, be an employer, a medical or conventional insurance scheme, a loyalty rewards program (wherein the cryptocurrency may be a loyalty point based stable cryptocurrency) etc.
- the governing body 12 may dictate where amounts of the cryptocurrency are spent (for instance with preselected loyalty partners etc.).
- the ecosystem may furthermore be associated with its own cryptocurrency, which may be associated with a public blockchain 28, or a private blockchain that may form part of the ecosystem 10.
- Taxation may be based on the user’s 22 account balance. Tax may be added onto each incoming transaction to the user’s 22 account. Tax may be added on top of the transaction fees, and may be payable to the governing body 12. A party paying the user 22 will not be affected directly by the tax but will be directly affected by transaction fees which will be included in every transaction. Transaction fees may be predetermined as a minimal percentage of a total transaction amount. The recipient will not receive the full amount as tax will be deducted from the transaction amount before it enters the recipient’s account. Alternative means of levying tax (as provided for by legislation or regulations) may be employed by the governing body
- the crypto ATM 20 is now discussed in more detail with reference to figures 7 to 12. It will be understood that the crypto ATM 20 is used as a part of the ecosystem 10 as discussed above, but that the crypto ATM 20 could also function as a system on its own, and does not require the closed ecosystem 10 to function.
- the crypto ATM 20 comprises hardware in the form of a processing module 200 and a memory arrangement 202.
- a server of the known kind may be used to provide the necessary processing module 200 and memory arrangement 202.
- the crypto ATM 20 is operated by an administrator 206.
- the administrator 206 exercises control over the server.
- the administrator 206 has an associated fiat-based business account 208 at the commercial bank 18.
- the administrator 206 furthermore has a profile 210 on the exchange 30.
- the profile 210 is associated with a crypto wallet 212 (or a plurality of crypto wallets associated with different types of cryptocurrencies or a single multi- currency wallet) which has an associated wallet address(es) 214, public key(s) 216, private key(s) 218, crypto balance(s) 220 and fiat balance 222. It will be appreciated that the administrator 206 and the governing body 12, may in some cases be the same entity.
- the process of logging in to the user interface 204 is designated by numeral 250 in figure 8.
- the user 22 enters its username (at 252) and password (at 254).
- the user completes a verification step (at 256) to distinguish its input from that of a machine (typically by completing a CAPTCHA or the like).
- the processor 202 generates a random key (at 258) and sends the key (at 260) to a known communication address or number (such as an email address or cell phone number which is stored in the user’s profile on the crypto ATM 20).
- the user 22 enters the key (at 262) received, the system verifies the key entered, and if correct, the user 22 will be logged into its profile.
- the user 22 When logged into the crypto ATM 20, the user 22 will have to opportunity to trade an amount in fiat currency for an amount in cryptocurrency, an amount in a cryptocurrency for an amount in a different cryptocurrency, or an amount of cryptocurrency for an amount in fiat currency, without having to interact with the exchange 30 directly.
- the user 22 furthermore does not have to be registered as a user on the exchange 30.
- the user 22 logs in (as shown at 250 in figure 8).
- the user 22 specifies a cryptocurrency that it wishes to receive (at 272), specifies an amount of fiat currency (at 274) that it wants to trade for the specified cryptocurrency, and provides a“receive address” (at 276) to which the cryptocurrency must be transferred.
- the receive address is generated from wallet information of the user 22 (such as a public key associated with the user 22).
- the crypto ATM 20 verifies (at 278) that all required information is received. If not, the user 22 is redirected back to the required field to enter the required information.
- each type of cryptocurrency requires an address in a specific format.
- the crypto ATM 20 therefore checks the format of the address (at 280) to confirm that it matches the required format for the type of cryptocurrency selected by the user 22. If the formats do not match, the transfer of the required amount of cryptocurrency will fail, and the amount may be lost.
- a message is displayed (at 282) and the user is redirected back to the field where the receive address is entered, to correct the receive address.
- the crypto ATM prompts (at 284) the exchange 30 to determine, based on a prevailing exchange rate, the amount of cryptocurrency that can be traded for the fiat amount entered by the user 22. This amount is received by the crypto ATM 20 (at 286).
- the administrator 206 maintains a balance of cryptocurrency in its wallet(s) 212. If the balance reaches a threshold value, the administrator 206 is notified. The crypto ATM 20 therefore checks if the balance 212 exceeds the threshold (at 288). If the threshold has been reached, the administrator 206 is notified (at 290) to correct this. The crypto ATM 20 compares (at 292) the available balance 220 with the amount received from the exchange 30. If the available balance does not exceed the amount received from the exchange 30, the user 22 is notified (at 294) and the user 22 is provided with an option (at 296) to request a lower amount (in fiat currency) to be traded. If the user 22 enters a new amount, the exchange 30 is again prompted (at 284) to determine the amount of cryptocurrency, and the process is repeated as explained above. If the user 22 does not enter a lower amount, the process 270 is ended.
- the crypto ATM 20 is in a position to complete the transaction.
- the user 22 is redirected (at 300) to a third-party payment processor of the known kind, and the user 22 makes an electronic payment (at 302) of fiat currency into the administrator’s 206 bank account 208 (in known fashion).
- the user 22 is redirected (at 304) to the crypto ATM 20.
- the crypto ATM 20 monitors (at 306) whether the payment was successful and redirects the user 22 to the third-party payment processor if not. If the payment was successful, the amount of crypto received from the exchange 30 (minus a small transaction fee which may be levied in cryptocurrency) is transferred from the wallet 212 to the receive address (at 308).
- the user 22 therefore immediately receives his cryptocurrency, instead of having to wait for the exchange to process the transaction.
- the user 22 is notified of the successful transaction 270 (at 310) (this can occur by way of an email notification).
- a trade request is submitted (at 312) to the exchange 30 to trade the amount received in fiat currency for cryptocurrency.
- the cryptocurrency traded by the exchange is received in the wallet 212 and the crypto balance 220 is restored.
- the fee that is levied makes provision for exchange rate fluctuations occurring between the time that the exchange determines the amount (at 286) of crypto currency that can be traded for the desired fiat amount, and the time that the trade request is submitted to the exchange (at 312).
- the simplified process of trading an amount in a cryptocurrency for an amount in different cryptocurrency is shown by numeral 840 in figure 10.
- the user 22 logs in at the crypto ATM 20 as above.
- the user 22 selects a first wallet, associated with a first cryptocurrency, to transfer from.
- the user 22 then transfers 844 an amount of the first cryptocurrency from the“transfer from” first wallet to a third party holding a second cryptocurrency.
- the third party then converts 846 the amount of the first cryptocurrency to a corresponding amount of a second cryptocurrency (amount determined via an exchange), which amount of the second cryptocurrency is then sent 848 from the third party to the user’s 22 elected second wallet as a“transfer to” wallet.
- the crypto ATM 20 is the only means by which amounts of cryptocurrency can enter the closed ecosystem 10.
- the process by which an amount of cryptocurrency is introduced into the ecosystem 10, through the crypto ATM 20, is indicated by reference numeral 320 in figure
- the user 22 indicates (at 322) that it wishes to add an amount of cryptocurrency to its crypto balance directed (at 324) from the user interface 16 of the ecosystem 10, to the user interface 204 of the crypto ATM 20.
- the process of transferring fiat for crypto currency 270 as outlined above will roughly be followed, with the exception that the user 22 will already be logged in to the crypto ATM 20 (as the user 22 had already successfully logged into the ecosystem 10) and the user 22 will not specify a“receive address”.
- the user 22 specifies the type of crypto currency desired (at 272) and specifies a fiat currency amount (at 274) to be traded.
- the crypto ATM 20 now prompts (at 326) the ecosystem 10 to retrieve (at 328) backend data of the user 22 (such as the user’s public key 48) which is used to generate a receive address (at 330) on the user’s 22 behalf (as previously discussed).
- the crypto ATM 20 connects to the ecosystem 10 using a web3 connection.
- the crypto ATM 20 may execute a function to retrieve the address from the blockchain 16.
- the user login details may be passed as parameters in the function, to search through the smart contract for the required data.
- This receive address is sent to the crypto ATM 20 (at 332).
- the trading process 270 now resumes from step 284 as outlined in figure 9.
- the crypto ATM 20 notifies the ecosystem 10 (at 334).
- the ecosystem 10 updates the user’s 22 crypto balance 52 (at 336), updates the private blockchain 14 (at 338), notifies the user 22 of its increased crypto balance 52 (at 340) and encrypts, processes and records the transaction in the smart contract associated with the user profile 34 (at 342).
- the crypto ATM 20 can also be used for trading amounts of cryptocurrency for amounts of fiat currency. This process is indicated by reference numeral 350 in figure 12.
- the user 22 logs into the crypto ATM 20 (at 250) as previously discussed with reference to figure 8.
- the user 22 now requests to trade an amount of cryptocurrency for an amount of fiat currency (at 352).
- the user 22 enters the currency (so that a receive address in the correct format can be generated) (at 254) and an amount of that currency (at 356) that the user 22 would like to trade.
- the ATM 20 retrieves the user’s 22 fiat banking details (at 358).
- the user 22 confirms the correctness of the banking details (at 360). If the details are not correct, the user 22 is prompted to enter or correct the details (at 362).
- a receive address is generated (at 364) (as previously discussed, by using API keys linked to the administrator’s 206 account on the exchange 30) and provided to the user 22.
- the user 22 uses the receive address to transfer (at 366) the indicated amount of crypto currency to a wallet 212 of the administrator 206.
- the crypto ATM 20 verifies (at 368) whether the transfer of the amount of crypto currency was successful. If not, a new receive address is created (at 364) and the process repeats. If the transfer was successful, the crypto ATM 20 submits (at 370) a“sell request” to the exchange 30 of the requested amount of cryptocurrency.
- the crypto ATM 20 receives a notification (at 372) and receives an amount of fiat currency (at 374) in the business bank account 208 of the administrator 206.
- a transaction fee is levied (at 376) and the remaining amount of fiat currency is transferred to the business banking account of the user 22 (at 378).
- the transaction detail is recorded and stored as previously discussed (and indicated at 380).
- the process by which an amount of cryptocurrency is withdrawn from the ecosystem 10, through the crypto ATM 20, is indicated by reference numeral 400 in figure 13.
- the user 22 (of the ecosystem) indicates (at 402) that it wishes to withdraw an amount of cryptocurrency from a crypto balance.
- the user 22 is directed (at 404) from the user interface 16 of the ecosystem 10, to the user interface 204 of the crypto ATM 20.
- the process of trading crypto currency for fiat 350 as outlined above will roughly be followed, with the exception that the user 22 will already be logged in to the crypto ATM 20 (as the user 22 had already successfully logged into the ecosystem 10).
- the crypto ATM retrieves (at 406) the crypto balance 52 and banking details from the smart contract associated with the user profile 34 stored on the private blockchain 14 (as previously discussed).
- the crypto ATM 20 confirms (at 408) whether the balance 52 is larger than zero. If not, the request is rejected (at 410) and the user 22 is informed (at 412). If the retrieved balance 52 is larger than zero, the user 22 is prompted to enter (at 414) an amount in cryptocurrency that it wishes to withdraw. Even though only withdrawals of amounts of cryptocurrency is described, it will be understood that the user 22 may alternatively select to withdraw an amount in fiat currency.
- the user interface 200 of the crypto ATM 20 displays the user’s 22 crypto balance, and a corresponding value in fiat currency based on a prevailing or live exchange rate (which is obtained from the exchange 30 in real-time). The ATM 20 verifies whether the balance exceeds the amount entered (at 416).
- the user 22 is prompted to enter a new amount (at 418), and the process repeats from step 414. If the user 22 opts not to enter a new amount, the request is rejected (at 410). If the balance 52 does exceed the requested amount, the banking details retrieved is displayed (at 420) to the user 22, to confirm (at 422) the correctness thereof. If incorrect, the user 22 enters or updates (at 424) the banking details. Next, a“receive address” is generated (at 426) from the wallet 212 on the exchange 30, and the stated amount of cryptocurrency is transferred from the ecosystem 10 to the wallet 212 (at 428). The transfer is monitored (at 430) and if not successful, a new address is generated as previously stated.
- a“sell request” is submitted (such as illustrated from step 370 to 380 in figure 12).
- the crypto ATM 20 notifies the ecosystem 10 (at 432) of the successful transfer, the user’s 22 crypto balance 52 is updated (at 434) the private blockchain 14 is updated (at 436), the user 22 is informed (at 438) and the transaction is recorded, encrypted and stored on the transaction record 54 on the smart contract associated with the user profile 34 (at 440).
- the user 22 does not require a profile on the exchange 30.
- the administrator 12 can easily change permissions on the exchange 30, change to a different exchange 30 and the like without influencing the user’s interaction with the system 10 or the crypto ATM 20.
- more than one exchange may be utilised, and consequently, that the crypto ATM 20 may provide users 22 with access to a wide variety of cryptocurrencies.
- the crypto ATM 20 enables a user 22 to receive its traded cryptocurrency amount much more expediently than when dealing directly with an exchange 30.
- the user 22 provides input and instructions to the crypto
- the crypto ATM 20 through the input module 506, the crypto ATM 20 can conveniently be accessed and utilised from any location, provided the input module 506 is connected to the internet (typically through a known wired or wireless connection). This means that the crypto ATM 20 can be administrated without the need of providing or maintaining distributed hardware in the form of physical input machines or the like.
- the crypto ATM 20 firstly determines an initial crypto amount, based on a current exchange rate, then transfers a subsequent amount, which is determined by deducting from the initial amount, a predetermined fee.
- the actual amount of cryptocurrency received from the exchange (a final amount) may differ from the initial amount, since the exchange rate may have changed between the time when the initial amount was determined, and the time the exchange is effected.
- a cryptocurrency payment system is generally indicated by reference numeral 500 in figure 14.
- the payment system 500 is managed or operated by an administrator 502.
- the payment system 500 is associated with a number of users 504 (such as a first user 504.1 and a second user 504.2).
- the users 504 are typically vendors, purveyors, providers of goods or services and the like. Each user 504 is associated with an input module 506.
- the users 504 provide goods or services to customers 508 (such as a first customer 508.1 and a second customer 508.2).
- the payment system 500 allows the customers 508 to pay for goods or services provided to them by the users 504, by utilising cryptocurrencies. As will be discussed in more detail below, the payment system 500 furthermore provides the users 504 with the option to receive payment in either fiat currency or cryptocurrency.
- Each of the customers 508 is associated with an input module 510.
- the payment system 500 comprises a user interface 512, a processing module 514, and a memory arrangement 516.
- the processing module 514 and memory arrangement 516 may take the form of a server hosted by the administrator 502.
- the users 504 communicate with the user interface 512 through known communication means 517.
- Each user 504 of the system 500 is associated with a user profile 518 which is stored in a database of user profiles 520.
- the system 500 is furthermore associated with a fiat banking account 522 at a fiat bank 524, and with a fiat to cryptocurrency exchange 526 of the known kind.
- the exchange communicates with public blockchains 528, associated with cryptocurrencies 530, in known fashion.
- the administrator 502 has a profile 532 on the exchange 526, which links to the administrator’s 502 crypto wallet(s) 534, and contains information on the administrator’s 502 wallet address(es) 536, public key(s) 538, private key(s) 540, crypto balance(s) 542, fiat balance 544 and the like.
- the administrator 504 may communicate with the exchange 526 via an API and may utilise API keys as previously discussed.
- the modules (506 and 510) may for instance comprise laptop or personal computers, smart devices such as smart phones and the like, while the communication means may comprise wireless communication networks, wired communication media and the like.
- the payment system 500 communicates, through communication means which will be apparent for those skilled in the art, with the various public blockchains 528.
- the known cryptocurrencies 530 may for instance be Bitcoin, Litecoin and the like.
- the data stored in the respective user profiles 518 varies depending on the type of user (such as a natural person, companies with varying degrees of liability, partnerships and the like.) Some of the information stored in the user profile 518 may include at least some of the following:
- an identification number 548 (such as an ID or social security number, a passport number, or other identification number used in a particular country, or a business registration number);
- tax number 550 (such as a personal income tax number, or a value added tax (VAT) number if the entity is registered as a VAT vendor) and other information required by the revenue service;
- VAT value added tax
- contact information 552 (such as a cellphone number, email address, office phone number, fax number and the like);
- address information 554 (such as a physical address) (which address information 44 may in some cases need to be verified by an independent third party);
- fiat banking details 556 a wallet or plurality of wallets address(es) 558 (which wallet, or plurality of wallets, are used for storing amounts of cryptocurrencies, and which will be discussed in more detail below);
- the user profile 518 is populated by information provided to the system 500 by the user 504 during registration.
- the process of registration will not be outlined in detail. Suffice to say, the process of registration comprises authentication of information provided to the system 500, the creation of login credentials and further security measures of the known kind.
- the system 500 enables the customer 508 to pay for goods and services with cryptocurrencies, whilst allowing the user 504 the option to receive payment in either cryptocurrency or fiat currency. Yet, this is handled by the system 500 instead of the user 504.
- the user 504 therefore does not require special infrastructure, or special software. Instead, the input module 506 of the user 504 becomes a point of sale, that provides access to the system 500 through the user interface 512.
- the process of a first customer 510.1 using cryptocurrency to pay for goods at a first user 504.1 is generally shown at 580 in figure 15.
- the first user 504.1 may be a retailer selling goods to the first customer 510.1.
- the retailer may list the price of the goods in its store in either cryptocurrency or fiat currency.
- the goods will be assumed to be listed in fiat currency.
- the first customer 510.1 selects the goods it wishes to purchase (at 582) and presents same at the checkout (at 584).
- the first user 504.1 logs in to the system (at 586) and enters the amount of the goods (in fiat) (at 588). In this way, the input module provides a“mobile” point of sale.
- the type of cryptocurrency that the customer would like to use to make the payment is indicated (at 590) and the system 500 obtains a prevailing exchange rate of the selected cryptocurrency from the exchange 526 (at 592).
- the system 500 therefore calculates the outstanding amount in cryptocurrency (at 594) and generates a“receive address” (at 596) (utilising API keys as was discussed more fully above).
- the converted amount is stored in the web session, to prevent tampering with the amount or the payment by the user 504.1.
- the amount and receive address are presented to the customer 510.1 (at 598) (typically by representing both in the form of a QR code (of the known kind, and in accordance with known methods)).
- the customer 510.1 enters the address and amount (typically by scanning the QR code) into its module 510.1 (at 600) and makes the payment (at 602) by transferring cryptocurrency from its wallet to the system 500.
- the system now utilises the receive address to query the blockchain (at 604) (as was discussed more fully above) to compare (at 606) the balance of the receive address to the amount calculated at 594. If not equal, a new amount is determined and the process from 594 is repeated.
- the transfer of cryptocurrency was successful. Now the transaction is recorded (at 608) in the first user’s 504.1 transaction record 564.1 , the first user’s 504.1 crypto balance 560.1 is adjusted (at 610), and the first user 504.1 is notified (at 612). If the user 504.1 requires to receive amounts in fiat currency, the cryptocurrency in the client’s 510.1 crypto balance 560.1 needs to be converted to an amount fiat currency. This process is indicated by reference numeral 620 in figure 16. This process is typically repeated each time a payment (as outlined at 580) is made. It will be appreciated that time delays are generally associated with trading cryptocurrencies for amounts in fiat currency. During these time delays, the exchange rate of the relevant cryptocurrency may change. The administrator therefore charges a predetermined handling fee to offset losses that may be incurred because of these fluctuations. The users 504 will typically account for these handling fees by increasing their asking prices for goods or services when trading in cryptocurrencies.
- the process 620 is initiated by the system 500 determining the amount of cryptocurrency from the user’s 504.1 crypto balance 560.1 (shown at 622). This amount is transferred to the wallet 534 (at 624). The abovementioned service fee is deducted from the amount to be traded (at 626). The fee remains in cryptocurrency within the wallet 534, to act as a buffer for all future transfers 620.
- the relevant amount of cryptocurrency is traded on the exchange (at 628) and an amount of fiat currency is received (at 630).
- the fiat balance 544 therefore increases by the amount received from the exchange 526.
- the system 500 queries (at 632) whether the fiat amount received is correct. As stated above, the fiat amount may be higher or lower than initially anticipated, due to exchange rate fluctuations. If the fiat amount is lower than required, a further amount to be traded on the exchange is calculated (at 634) the amount is taken from the buffer stored in the wallet, and traded (the process from 628 is repeated). If the fiat amount received is equal to, or higher than the required amount, the client’s 504.1 fiat balance 562.1 is updated (at 636) and the trade is complete.
- Any surplus amounts of fiat are kept to act as a buffer, similar to the buffer kept in cryptocurrency, as discussed above. It will be appreciated that a larger buffer amount in fiat currency can be maintained and that the system can be adopted (albeit not indicated) to first query the exchange rate from the exchange 526, to determine whether it would be better to trade more cryptocurrency, or alternatively, to use fiat currency, to make up for a deficit.
- the system 500 transfers the amounts of fiat currency held on behalf of the clients 504 to their respective fiat banking accounts. This is shown by reference numeral 640 in figure 17.
- the fiat balances 562 of each user is retrieved (at 642) from the database of user profiles 520 stored on the memory arrangement 516.
- a total amount of fiat to be traded for the month is calculated (at 644) from all of the fiat balances.
- the total amount is retrieved (at 646) from the exchange 526 to the business account 522.
- the banking details of each user 504 is retrieved (at 648) from the database of user profiles 520 stored on the memory arrangement 516.
- the relevant amount (in fiat currency) is transferred electronically (at 650) from the business account 522 to the accounts of the users 504, the users 504 are notified (at 652) of the successful transfer, and the fiat balances 562 of the users 504 are adjusted (654).
- the amount may at any time be transferred to a wallet 558 stored in the user account 518.
- system 500 enables easy and seamless trading between vendors, purveyors, providers of goods and services and the like, and their customers who wish to pay for goods or services utilising cryptocurrencies, and provides the users 504 of the system with the opportunity to receive payment in either cryptocurrency, or fiat currency. It will be readily ascertained that the payment system 500 could easily be incorporated into the closed ecosystem 10 discussed previously, to enable the monitoring and regulation of transactions facilitated by the system 500.
- the payment system 500 communicates directly with the exchange 30, the user 504 does not have to provide any more payment facilities to enable its customers to make cryptocurrency payments to it in exchange for goods or services. The payments are therefore received from the customer (or third party) directly by the payment system 500, on behalf of the user 504. Since the input module 506 communicates through the user interface, a point of sale is created on any input module 506 through which the user 504 logs into the system 500. Therefore, the user 504 does not have to provide any functionality on its website, or provide a facility for utilising so- called“crypto-credit cards”. Also, the system 500 enables the user to decide whether to receive payment in cryptocurrency or fiat currency.
- a user 504 that has not yet adapted capability of handling or receiving cryptocurrencies, may yet enable its customers to make payment in cryptocurrencies. Also, since only the administrator 502 needs to be registered with the exchange, the administrator 502 may easily adapt the system 500 to be compatible with a large number of cryptocurrencies, to suit the needs of the customers 508 of the users 504. In cases where the user 504 opts to receive payment in cryptocurrency rather than fiat currency, the service fee charged may be reduced, since delayed transaction times and changes in exchange rates, as aforementioned, may not play a role. It will be understood that a user 504 could also specify a specific type of cryptocurrency (such as Bitcoin) in which it wants to receive payment. If the third party used another cryptocurrency, such as Litecoin, the system can handle the exchange thereof, and again, a service charge will be levied. It will also be understood that the service fees will be required to process the transactions, update the blockchain etc.
- An electronic-commerce (e-commerce) gateway is generally indicated by reference numeral 700 in figure 18.
- the gateway 700 comprises a background script 702 which is stored on a memory arrangement (not shown) and receives input data from an extension module 704.
- a user interface 706 comprises a cart table 708.
- the cart table 708 displays information received from the background script 702.
- the information is processed by a processing module 710 before being displayed in the cart table 708.
- the user interface 706 enables a user 712 to edit information contained in the user interface 706.
- the processing module 710 updates data stored in the background script 702.
- the user 712 gains access to the user interface 706 through an input module 714 such as a smart device of the known kind, personal computer or laptop computer of the known kind.
- the data stored in the background script 702 may include uniform resource locators (URLs) of websites accessed by the user 712 through its module 714.
- the extension module 704 takes the form of an application running on the module 714, and in particular, takes the form of a web extension installed on a web browser associated with the module 714.
- the cart table 708 comprises at least some of the following columns:
- the gateway 700 is operated by an administrator 722.
- the gateway 700 is provided in communication with a cryptocurrency payment processor 500 as discussed previously.
- the payment processor 500 is adapted to operate with the gateway 700, the administrator 722 of the gateway 700 is the user 506 (of the payment processor 500) and the user 712 of the gateway 700, is the customer or third party 508 of the payment processor
- the payment processor 500 could form part of the architecture of the gateway, and that the user interfaces of the gateway 700 and the payment processor (512 and 706 respectively) could be merged into the user interface 706 of the gateway 700. It will therefore be apparent that the user 712 of the gateway 700, will be registered with the gateway
- the payment processor 500 may be operated independently from the gateway 700.
- the processing module 710 comprises a plurality of bots 724 that execute certain functions based on inputs received via the processing module 710 from the background script 702.
- the user interface 706 may comprise various buttons (such as checkout button 726, add or subtract buttons 728 with which the quantity may be adjusted, or remove button 730 with which a row from the cart table 708 may be removed) with which the user 712 may provide input that the processing module 710 may use to adjust or edit the data in the background script 702.
- the gateway 700 enables the user 712 to make online purchases utilising a cryptocurrency, on currently available electronic commerce sites, even when these sites do not support the use of cryptocurrencies. Furthermore, the user 712 (being registered on the gateway 700) does not have to be a registered user of these currently available electronic commerce sites. This adds convenience to the experience of online shopping. The registration of the user 712 on the gateway 700 is largely similar to processes as disclosed herein previously, and will not be repeated.
- the user will at the very least provide detail pertaining to its identity, contact details, and a shipping address to the gateway 700 upon registering as a user 712. It will be clear that the user interface 706 is specific to the user 712, and only displayed once the user 712 has successfully logged in to the gateway 700.
- the user 712 opens a web browser application (not shown) (on which the extension is installed) on its module 714, and starts browsing (at 752) through e-commerce websites. Throughout this process, the extension module 704 monitors and observes (at 754) the activity in the background
- the extension therefore continuously awaits (at 756) inputs from the user 712.
- the user 712 identifies an item from the e-commerce website that it would like to purchase, it clicks on the extension in the web browser application, and the extension module 704 retrieves the URL of the active session (at 758), and stores the URL (at 760) in the background script 702 associated with the user 712.
- the extension of the web browser application is therefore directly linked to the user profile of the user 712 on the gateway 700. However, by clicking on the extension, the URL is merely copied to the background script. This does not result in a purchase order being generated, nor does it commit the user 712 to the purchase of the item on the active session.
- the extension continues monitoring (at 762) whether the user continues browsing, in which case the process from step 756 will be repeated. This whole process will continuously be repeated each time the user 712 opens its web browsing application.
- the user 712 After the user 712 has identified one or more items (potentially from various e-commerce websites, none of which the user 712 had to log in to as a user) and the user 712 is ready to proceed with the purchasing of the items, the user 712 proceeds with the process of confirming its purchases and placing orders for the various items. This process is shown by reference numeral 770 in figure 20.
- the user 712 logs in to the user interface 706 (at 772).
- the processing module 710 accesses the background script 702 associated with the user
- the processor module 710 acting as a web scraping module, utilises each URL to scrape and retrieve data from the websites associated with the URL (at 778). The data is filtered based on the specific website from which the data was scraped, and used to populate the cart table 708 (at 780). The processor automatically picks up is a specific URL appears more than once on the background script 702. In such a case, only one entity on the cart table will be generated, but the quantity (in column 720) will show the number of instances the URL appeared on the background script 702. It will be understood that each row on the cart table 708 will represent an independent item.
- each URL scrapes and retrieves data from the websites associated with the URL is indicated by reference numeral 850 in figure 21.
- the URLs are sent 852 to the API which will retrieve the information of items to be purchased.
- a process of looping 854 through the list of URLs commences wherein for each URL, the associated website domain is determined and an appropriate and proprietary (of the system 10) scraping function is selected 854.2 after which the necessary information, including the price and title of the item(s) to be purchased, is scraped and saved 854.3, and then a check 854.4 is implemented to see whether there are any further URLs in the list of URLs remaining. If there are, then the looping 854 commences, however if there are no more URLs in the list, then the saved information as scraped for each URL and each independent item to be purchased is presented 856 on the cart table as described above.
- the user 712 now reviews the cart table 708 (at 782) and adjusts the cart table 708 (at 782).
- the adjusting of the cart table may comprise the user removing certain items from the cart table (by selecting the remove button 730 associated with a specific row of the cart table 708) or adjusting the quantity of a specific item (by utilising the add or subtract buttons 728).
- the processor module 710 processes the inputs, and updates the background script 702 (at 788). It will be clear that the cart table 708 is a visual representation of the background script 702.
- the user 712 confirms and places the order (at 790), by clicking on the checkout button 726.
- the user 712 is now directed to the user interface of the cryptocurrency payment processor 500 (at 792), and the process of making a payment at 794 which is provided in more detail in figure 22.
- the process of making payment 794 in figure 20 is indicated by reference numeral 860 as shown in figure 22.
- the user 712 may choose 864 whether the user 712 wishes to pay in either a stable cryptocurrency (or a fiat currency) 864.1 or a non-stable cryptocurrency 864.2. If the user 712 elects to pay in a non-stable cryptocurrency, the purchase price is converted 866 to the user 712 elected non-stable cryptocurrency. Once the purchase price has been established based on the user choice (at 864), then the purchase price (or converted purchase price) is presented 868 to the payment processor 500 via the gateway 700 and the user 712 can submit for payment.
- the payment address is queried 870 by the gateway 700, and the payment can be verified 872 (as at 796 in figure 20). Should the payment not be verified in that there is an outstanding amount on the purchase price noted from the payment address, the outstanding amount is queried 874, and the outstanding amount is presented 868 to the payment processor 500.
- the total amount (in fiat currency) of items purchased will automatically be provided to the payment processor 500 as an input from the gateway 700.
- the payment is verified (at 796) (as discussed above), and the payment processor 500 confirms receipt of payment to the gateway 700 (at 798).
- the user interface 706 displays a message to the user 712 that the order has successfully been placed.
- An orders database 802 is stored on a memory arrangement 804 (the background script is also stored on the memory arrangement 804). Once an order is successfully placed (at 800) the order is stored to a“pending orders” list 806 (shown at 808). The process of confirming and placing an order 770 is now complete, and the user logs out of the user interface 706.
- the gateway 700 now has to manage and process orders that were placed by the various users 712 and that are stored in the“pending orders” list. This process is indicated by reference numeral 810 in figure 23.
- the processing module 710 awaits the availability of the bots 724.
- a bot 724 finishes the processing and placing of a previous order, it indicates its availability to process a new order (at 812).
- An order is retrieved from the pending orders list (at 814) and allocated to the specific bot 724 (at 816).
- Orders may be retrieved (according to step 814) from the pending orders list 806 based on the age of the orders, or the urgency of the orders.
- the urgency may be determined by an input received from the user 712 when placing the order.
- the gateway may levy an additional fee for increasing the urgency of the order.
- the bot 724 retrieves (at 818) the necessary information of the user from the gateway, that will be required to place orders at the various e-commerce service providers.
- the bot 724 utilises the information of the order and the client to physically place orders at the websites of the various e-commerce service providers 820.
- the information of the user 712 rather than information pertaining the gateway 700, is used to complete the orders at the various e-commerce sites. These sites can therefore communicate detail of the respective orders, such as delivery addresses and delivery times, directly to the client 712 without further intervention from the gateway 700. Shipping of orders may be directly to an address specified by the user.
- the gateway 700 pays for the orders placed at the various e-commerce service providers by transferring amounts in fiat currency from its business bank account, or by utilising online payment coupons, if available.
- gateway 700 acts as a middleman between retailers and e-commerce service providers.
- FIGS 24 and 25 present flow diagrams setting out processes with which either: a first user of the ecosystem may elect the type of currency in which to make a payment or funds transfer to a second user (including an electronic commerce service provider) in or from the ecosystem 10; or a second user (including an electronic commerce service provider) may elect the type of currency in which to receive payment or funds transfer from a first user in or from the ecosystem 10.
- a payment or funds transfer (referred to as the transaction in figures 24 and 25) is effected from a first user (referred to as the user in figures 24 and 25) to a second user (referred to as the recipient in figures 24 and 25), but specifically may be employed in the transfer process within the ecosystem 10 as shown in figure 4, specifically when the transaction is processed (at 134), in the transfer process from the ecosystem 10 as shown in figure 6, specifically when the request is executed (at 178), or when a user confirms and places an order via the gateway 700 as shown in figure 20, specifically when the user makes payment (at 794).
- Figure 24 shows the process wherein the user of the ecosystem 10 elects the type of currency (which may be any of a stable cryptocurrency, a non stable cryptocurrency and a fiat currency) in which to transact with the recipient, and thereby the user may be required to pay a conversion fee.
- This process is indicated by reference numeral 880.
- the user receives 882 the payment address from the recipient in the transaction, and may then opt 884 to either convert the transaction amount to a recipient-elected currency or not. Should the user then opt to convert to the elected currency, the user is prompted to accept responsibility to pay an associated conversion fee 886, should they not accept the responsibility, the user is redirected to the start of the process 882. However, should the user accept the responsibility, then the conversion fee is added 888 to the transaction amount and the user then makes the necessary payment 890, which payment is sent to a third party for conversion 892. The currency is then sent 894 from the third party to the recipient.
- the conversion fee is added 888 to the transaction amount and the user then makes the necessary payment 890
- the process from where the currency is sent 894 from the third party to the recipient is the same as that following on where the user has not opted 884 to convert to the elected currency and rather the user has sent payment in the unconverted currency to the recipient. Accordingly, the recipient is notified 896 of the incoming payment (and may then opt to follow the process of figure 25 indicated by reference numeral 910) and the user is notified of the successful payment 898 and the transaction record is updated
- Figure 25 shows the process wherein the recipient of the ecosystem 10 elects the type of currency (which may be any of a stable cryptocurrency, a non-stable cryptocurrency and a fiat currency) in which to transact with the user, and thereby the recipient may be required to pay a conversion fee.
- This process is indicated by reference numeral 880.
- the recipient is notified of an incoming payment and is prompted 912 to elect whether they wish to transfer the incoming transaction payment into a different wallet (or a fiat currency account where relevant). Should the recipient elect a different wallet (or fiat currency account), then the recipient is prompted 914 to accept responsibility to pay an associated conversion fee. Should the recipient not accept the responsibility, the recipient is redirected to the start of the process 912.
- the associated conversion fee is added 916 to the transaction amount (i.e. incoming payment amount).
- the process from where the conversion fee is added to the transaction amount is the same as where the recipient did not elect a different wallet 912, in that the receive address and the transaction amount is presented 918 to the recipient, and the receive address is then sent 920 to the user and the user is notified 922 and may issue payment.
- the governing body in the case of the ecosystem 10) and administrator (206 in the case of the crypto ATM, 502 in the case of the payment system 500 and 722 in the case of the e- commerce gateway 700) performs the task of a third-party intermediary with very limited control and monitoring.
- the governing body or administrator lends legitimacy to the systems and transactions concluded therewith, from the general public’s point of view. This, to a large degree, solves the problem of distrust from the general public’s point of view.
- the limited control of the governing body or administrator ensures that the potential benefits of blockchain technology are not jeopardised by its presence or control.
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- General Business, Economics & Management (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Description
Claims
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
ZA2018/07910 | 2018-11-23 | ||
ZA201807910 | 2018-11-23 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2020104961A1 true WO2020104961A1 (en) | 2020-05-28 |
Family
ID=70773571
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IB2019/059970 WO2020104961A1 (en) | 2018-11-23 | 2019-11-20 | Systems and methods relating to cryptocurrencies |
Country Status (2)
Country | Link |
---|---|
WO (1) | WO2020104961A1 (en) |
ZA (1) | ZA201907671B (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20210118052A1 (en) * | 2019-10-21 | 2021-04-22 | Joachim Paul Walser | Cryptocurrency cash gateway |
WO2022213061A1 (en) * | 2021-03-31 | 2022-10-06 | Paypal, Inc. | Using an internal ledger with blockchain transactions |
US20230177507A1 (en) * | 2021-12-08 | 2023-06-08 | Paypal, Inc. | User activity detection for locking cryptocurrency conversions |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150294425A1 (en) * | 2014-04-14 | 2015-10-15 | Libra Services, Inc. | Methods, systems, and tools for providing tax related services for virtual currency holdings |
US20150324789A1 (en) * | 2014-05-06 | 2015-11-12 | Case Wallet, Inc. | Cryptocurrency Virtual Wallet System and Method |
US20170046652A1 (en) * | 2015-08-13 | 2017-02-16 | The Toronto-Dominion Bank | Systems and method for tracking behavior of networked devices using hybrid public-private blockchain ledgers |
US20170232300A1 (en) * | 2016-02-02 | 2017-08-17 | Bao Tran | Smart device |
-
2019
- 2019-11-20 WO PCT/IB2019/059970 patent/WO2020104961A1/en active Application Filing
- 2019-11-20 ZA ZA201907671A patent/ZA201907671B/en unknown
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150294425A1 (en) * | 2014-04-14 | 2015-10-15 | Libra Services, Inc. | Methods, systems, and tools for providing tax related services for virtual currency holdings |
US20150324789A1 (en) * | 2014-05-06 | 2015-11-12 | Case Wallet, Inc. | Cryptocurrency Virtual Wallet System and Method |
US20170046652A1 (en) * | 2015-08-13 | 2017-02-16 | The Toronto-Dominion Bank | Systems and method for tracking behavior of networked devices using hybrid public-private blockchain ledgers |
US20170232300A1 (en) * | 2016-02-02 | 2017-08-17 | Bao Tran | Smart device |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20210118052A1 (en) * | 2019-10-21 | 2021-04-22 | Joachim Paul Walser | Cryptocurrency cash gateway |
WO2022213061A1 (en) * | 2021-03-31 | 2022-10-06 | Paypal, Inc. | Using an internal ledger with blockchain transactions |
US20220318788A1 (en) * | 2021-03-31 | 2022-10-06 | Paypal, Inc. | Using an internal ledger with blockchain transactions |
US11922403B2 (en) | 2021-03-31 | 2024-03-05 | Paypal, Inc. | Using an internal ledger with blockchain transactions |
US20230177507A1 (en) * | 2021-12-08 | 2023-06-08 | Paypal, Inc. | User activity detection for locking cryptocurrency conversions |
Also Published As
Publication number | Publication date |
---|---|
ZA201907671B (en) | 2020-11-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10915898B2 (en) | Demand deposit account payment system | |
US11694243B2 (en) | Injecting exchange items into an exchange item marketplace network | |
US11887077B2 (en) | Generating exchange item utilization solutions in an exchange item marketplace network | |
US11062366B2 (en) | Securely processing exchange items in a data communication system | |
US11164228B2 (en) | Method and medium for determining exchange item compliance in an exchange item marketplace network | |
US10679215B2 (en) | System for control of device identity and usage in a process data network | |
US20100191622A1 (en) | Distributed Transaction layer | |
US11238444B2 (en) | Secure and trusted cryptocurrency acceptance system | |
US20220245624A1 (en) | Show to pay payment mode of a digital asset payment network | |
WO2020104961A1 (en) | Systems and methods relating to cryptocurrencies | |
US20210334794A1 (en) | Resolving a parameter error associated with a primary blockchain | |
US20220309511A1 (en) | Determining a fraud abatement approach for a potentially fraudulent exchange item | |
US20230169553A1 (en) | Determining an automatic acquisition approach for an exchange item request | |
KR20200130558A (en) | Method for operating a crypto-currency exchange | |
US20230095679A1 (en) | Pre-authorization hold digital asset-based interaction | |
US20230376944A1 (en) | Smart contract digital asset management unit | |
US20220327591A1 (en) | Automatically determining an acquisition threshold for an exchange item | |
US20230100777A1 (en) | Bi-directional digital asset point of sale computing device |
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: 19887130 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: 19887130 Country of ref document: EP Kind code of ref document: A1 |
|
32PN | Ep: public notification in the ep bulletin as address of the adressee cannot be established |
Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 13/01/2022) |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 19887130 Country of ref document: EP Kind code of ref document: A1 |