WO2022047582A1 - Technologies utilisant une chaîne de blocs pour un traitement de transaction hors ligne sécurisé - Google Patents

Technologies utilisant une chaîne de blocs pour un traitement de transaction hors ligne sécurisé Download PDF

Info

Publication number
WO2022047582A1
WO2022047582A1 PCT/CA2021/051213 CA2021051213W WO2022047582A1 WO 2022047582 A1 WO2022047582 A1 WO 2022047582A1 CA 2021051213 W CA2021051213 W CA 2021051213W WO 2022047582 A1 WO2022047582 A1 WO 2022047582A1
Authority
WO
WIPO (PCT)
Prior art keywords
sms message
phone number
user
registered user
requesting
Prior art date
Application number
PCT/CA2021/051213
Other languages
English (en)
Inventor
Sameem Monzaviyan
Original Assignee
Centigram International, Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Centigram International, Ltd filed Critical Centigram International, Ltd
Publication of WO2022047582A1 publication Critical patent/WO2022047582A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3676—Balancing accounts
    • 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/385—Payment protocols; Details thereof using an alias or single-use codes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]

Definitions

  • This disclosure relates generally to a blockchain-based ecosystem for authenticating users and facilitating payments therebetween; in particular, this disclosure relates to a system that provides ownership validation and transfer of virtual assets with offline transactions.
  • this disclosure provides a system and method of tamper resistant transfer of virtual assets via SMS.
  • This technical feature overcomes existing security concerns using SMS communications for financial transactions, allow such messages to be secured and temper-resistant, and removes the requirement that the users have an internet connection to perform such financial transactions.
  • the disclosure provides a payment platform that facilitates instant transactions via SMS, locally and/or cross-border, which allows users to perform transactions even when they are disconnected from the internet.
  • each user is registered as a unique user with a unique global user identifier (GID) and their device as a unique registered device with a device identifier during a user onboarding process.
  • GID global user identifier
  • the SMS messages may include one-time keys (OTKs) stored in offline storage that can be verified by the platform in some embodiments.
  • OTKs one-time keys
  • this disclosure provides a system and method of instant ownership validation and verification of virtual assets during offline transactions.
  • a technical feature of this disclosure is the ability to continue transacting with a digital wallet that could potentially remain disconnected from the internet for a long period of time while having the confidence that it is correctly consolidating and being validated against a centralized verifiable ledger to eliminate the possibility of malicious activities, such as double spending, fake transactions, spoofing or tampering while disconnected from the main system of records.
  • this disclosure ensures that all transactions are generated from valid and verifiable accounts and sent to valid receivers. This gives end users the confidence that they are not going to be scammed or manipulated with fake promises of payment while giving them the ability to transact regardless of internet connectivity.
  • the platform requires each user to own a unique smartphone and dedicated phone number for each account that must pass KYC and AML validation at the point of purchase or cash out of their assets.
  • this disclosure provides a hybrid ledger to record transactions and asset ownerships using a blockchain network.
  • a feature of this system is to overcome current regulatory issues in each jurisdiction with use of blockchain records and ensure true ownership of assets is not impacted by company’s operational risks.
  • the system uses two different ledgers, a public ledger and a private ledger.
  • Each ledger has its unique capabilities that serve different purposes. The goal is to remain compliant with record keeping (e.g., AML, KYC, ATF, and other policies), while ensuring the ownership of the assets will not be compromised by closure of company operations.
  • the public ledger is to give the asset owners a public hashed record of their ownership without giving away any PII or other details about content while keeping such details safely within the private ledger in line with industry standard level of privacy and compliance.
  • FIG. 1 is a simplified block diagram of at least one embodiment of a blockchain-based system for facilitating authentication and payment transactions of virtual assets;
  • FIG. 2 is a simplified block diagram of at least one embodiment of various environments of the system of FIG. 1;
  • FIG. 3 is a simplified flow diagram of at least one embodiment of a method for recording transactions using a hybrid ledger system
  • FIGS. 4A-4B is a simplified flow diagram of at least one embodiment of a method for facilitating transfer of virtual assets in which both the sending user and the receiving user are online;
  • FIGS. 5A-5B is a simplified flow diagram of at least one embodiment of a method for facilitating transfer of virtual assets in which the sending user is online, but the receiving user is offline during the transaction;
  • FIGS. 6A-6F is a simplified flow diagram of at least one embodiment of a method for facilitating transfer of virtual assets in which the sending user is offline during the transaction, but the receiving user is online;
  • FIGS. 7A-7G is a simplified flow diagram of at least one embodiment of a method for facilitating transfer of virtual assets in which both the sending user and the receiving user are offline during the transaction; and [0017] FIGS. 8A-8E is a simplified flow diagram of at least one embodiment of a method for onboarding a new user.
  • references in the specification to “one embodiment,” “an embodiment,” “an illustrative embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may or may not necessarily include that particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
  • items included in a list in the form of “at least one A, B, and C” can mean (A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C).
  • items listed in the form of “at least one of A, B, or C” can mean (A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C).
  • the disclosed embodiments may be implemented, in some cases, in hardware, firmware, software, or any combination thereof.
  • the disclosed embodiments may also be implemented as instructions carried by or stored on a transitory or non-transitory machine- readable (e.g., computer-readable) storage medium, which may be read and executed by one or more processors.
  • a machine-readable storage medium may be embodied as any storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (e.g., a volatile or non-volatile memory, a media disc, or other media device).
  • this disclosure relates to a cloud-based platform in which users can make financial transactions with virtual assets - without needing internet connectivity.
  • the platform could establish a digital commodity money exchange (e.g., based on bullion gold at micro amounts or other commodities or items, such as gift cards), which allows the platform to conduct transactions at negligible cost to the end user.
  • a digital commodity money exchange e.g., based on bullion gold at micro amounts or other commodities or items, such as gift cards
  • the platform allows underserved and financially underprivileged citizens to conduct small digital transactions.
  • they are penalized and discriminated against by financial institutions’ “umbrella” approach in applying a risk-based approach to comply with regulatory policies.
  • Such approaches are technically preventing individuals from conducting small yet critical transactions on a regulated and licensed payment platform.
  • the platform can be used to serve the unbanked and offline users while remaining within the boundaries of legal and regulatory guidelines by jurisdiction. This means serving the underserved communities and users via a legal, simple, convenient, secure, and very accessible platform.
  • such users will be able to transact directly with others in exchange for goods, services and/or to receive remittances or aid directly to their registered smartphone devices even without internet access.
  • Such capability has the potential to greatly improve lives, and eventually enhance and expand the local economy by welcoming a previously excluded population and allowing them to participate in the financial market in an unprecedented manner.
  • the platform overcomes certain technical hurdles to offer authentication and payment transactions to those without internet connectivity.
  • the platform overcomes security concerns using SMS messaging for financial transactions.
  • sending sensitive information, including financial transaction details, via an SMS message is rightly confirmed as risky and insecure. This is due to the fact that SMS messaging service is not designed to be utilized for such type of sensitive communications given the possibility of live interception and/or spoofing.
  • users without internet connectivity i.e., offline users
  • the platform may perform a verification process before the generation of an SMS message, during the transmission process, and at the receiving end to collectively act as validation and security features mitigating the potential risks inherent with using SMS messaging for secure transactions. This allows users to make transactions on the platform whether their smart devices are connected to the internet or not. Additionally, virtual asset ownership validation and verification at the point of sale is provided without the user requiring internet connection to the server(s).
  • this platform includes a technical feature in which transactions can continue with a digital wallet even if potentially disconnected from the internet for a long period of time while having the confidence that it is correctly consolidating and being validated against a centralized verifiable ledger to eliminate the possibility of malicious activities, such as double spending, fake transactions, spoofing or tampering while disconnected from the main system of records.
  • the platform includes one or more features that ensures all transactions are generated from valid and verifiable accounts and sent to valid receivers. This gives end users the confidence that they are not going to be scammed or manipulated with fake promises of payment while giving them the ability to transact regardless of internet connectivity.
  • Another technical hurdle overcome by the platform is the ability to conduct instant transactions at high volumes with validation and verification at the same time - even when one or both parties do not have an internet connection. If the transactions are happening via the internet, as long as all parties are connected, it is possible to achieve consolidation almost instantaneously. Unfortunately, if either party is not connected to the internet, it becomes very difficult, and in most current systems, impossible to transact. The risk amplifies when such transactions involve currencies or virtual assets.
  • VASPs Virtual Assets Service Providers
  • mobile wallet solution providers are not able to provide offline users the same level of services and accessibility they provide to those with internet access.
  • the system allows users to conduct such transactions even without being connected to the internet at the moment of transaction.
  • the platform includes a One Time Key (OTK) in combination with multiple other possible key user specific details that are centrally verified and encrypted to ensure the transaction generated and sent via an SMS message is always secure, validated and verified prior to finalization of the transaction, while giving the user a simple, frictionless and seamless experience.
  • OTK One Time Key
  • the users are able to conduct transactions (e.g., micro-payments) with other registered users at very low cost and seamlessly regardless of their internet connectivity.
  • users merely can use active cellular connectivity (using the same cellphone on the number they used to register their User ID) on the smartphone where platform is installed and registered with.
  • This also allows the ability to combat spam and fake accounts by making it challenging for the same user to create multiple accounts or fake accounts.
  • the platform system requires each user to own unique smartphone and dedicated phone number for each account that must pass a KYC and AML validation at the point of purchase or cash out of their assets.
  • this disclosure provides a hybrid dual ledger.
  • a hybrid dual ledger To ensure true ownership of assets is not impacted by the platform’s operational risks and alignment with regulatory policies in each jurisdiction, embodiments of the platform separates the record keeping mechanism into two different ledgers.
  • Each ledger has its unique capabilities that serve different purposes. The goal is to remain compliant with record keeping, AML, KYC, ATF, and other policies, while ensuring the ownership of the assets will not be compromised by closure of platform operations.
  • the hybrid dual ledger technology (HDLT) is designed to give the asset owners a public hashed record of their ownership without giving away any personal identifiable information (PII) or other details about content while keeping such details safely within the private ledger in line with industry standard level of privacy and compliance.
  • PII personal identifiable information
  • a blockchain-based system 100 for facilitating user authentication and payment transactions includes one or more servers 102 in communication with one or more remote computing devices 104.
  • a portion of the remote computing devices 104 which are represented as online users 105, communicate with the server 102 via a network 106 (e.g., the internet) and another portion of the remote computing devices 104, which are represented as offline users 107, communicate with the server 102 via a SMS gateway 109.
  • an app on the remote computing devices 104 could use APIs of the SMS gateway 109 to communicate with the server 102 via SMS messaging.
  • An example SMS gateway service could be provided by Twilio Inc. of San Francisco, California.
  • online users 105 may use remote computing devices 104 that are embodied as mobile computing devices, such as smart phones and/or tablets, with a data plan that are able to connect to server 102 through the network 106, which could include the internet.
  • the offline users 107 may use remote computing devices 104 that are embodied as a mobile computing device, such as a smartphone or tablet, with a cellular plan and phone number, but without a data plan or are in a location outside of the range of their data plan. Due to not having a data plan or being outside coverage, the offline users 107 are unable to communicate through the network 106. Instead, the offline users 107 communicate with the server 102 via the SMS gateway 109.
  • offline users 107 can become online users 105.
  • an offline user 107 with a data plan that is currently outside data coverage may move to a location with coverage and then be able to communicate with the server 102 via the network 106.
  • an offline user 107 without a data plan may connect to the network 106 by connecting their remote computing device 104 to the network 106, which could include the internet, using Wi-Fi or Ethernet, or with other communication devices.
  • a portion of the remote computing devices 104 may be able to communicate with the server 102 via both the network 106 and the SMS gateway 109.
  • the server 102 could be a cloud-based platform with a plurality of servers accessible through the network 106 and/or SMS gateway 109.
  • the embodiment shown in FIG. 1 includes a plurality of remote computing devices 104 that are capable of accessing one or more functions of the server 102 over the network 106 or the SMS gateway 109, but more or less remote computing devices 104 could be provided depending on the circumstances.
  • at least a portion of the functions of the server 102 may be provided, at least in part, with third party services using third party API(s) 111.
  • the server 102 includes an authentication and payment system 108 and a distributed ledger 110 with a plurality of nodes 112.
  • the authentication and payment system 108 includes features for, among other things, authenticating users and facilitating payment transactions, whether or not one or both parties to a transaction may be offline as described herein.
  • the distributed ledger 110 includes blockchain-based technologies to synchronize transaction data across multiple nodes 112 that can be used to verify integrity of the data, such as for purposes of auditing.
  • At least a portion of the distributed ledger 110 would be provided on a private blockchain network; however, embodiments are contemplated in which at least a portion of the distributed ledger 110 (or portions of data in the distributed ledger 110) could be publically available if the data were de-identified (e.g., cleaned of personal-identifiable data).
  • the server 102 and remote computing devices 104 may be embodied as any type of computation or computer device capable of performing the functions described herein, including, without limitation, a computer, a server, a workstation, a desktop computer, a laptop computer, a notebook computer, a tablet computer, a mobile computing device, a wearable computing device, a network appliance, a web appliance, a distributed computing system, a processor-based system, and/or a consumer electronic device. Additionally or alternatively, the server 102 may be embodied as a one or more compute sleds, memory sleds, or other racks, sleds, computing chassis, or other components of a physically disaggregated computing device.
  • the server 102 and computing devices 104 could include a processor, an input/output subsystem, a memory, a data storage device, and/or other components and devices commonly found in a server or similar computing device.
  • the server 102 may include other or additional components, such as those commonly found in a server computer (e.g., various input/output devices), in other embodiments.
  • one or more of the illustrative components may be incorporated in, or otherwise form a portion of, another component.
  • the memory, or portions thereof may be incorporated in the processor in some embodiments.
  • the server 102 and computing devices 104 include a communication subsystem, which may be embodied as any communication circuit, device, or collection thereof, capable of enabling communications between the server 102 and remote computing devices 104 over the computer network 106 and/or SMS gateway 109.
  • the communication subsystem may be embodied as or otherwise include a network interface controller (NIC) or other network controller for sending and/or receiving network data and/or SMS messages with remote devices.
  • NIC network interface controller
  • the NIC may be embodied as any network interface card, network adapter, host fabric interface, network coprocessor, or other component that connects the server 102 and remote computing devices 104 to the network 106 and/or SMS gateway 109.
  • the communication subsystem may be configured to use any one or more communication technology (e.g., wired or wireless communications) and associated protocols (e.g., Ethernet, InfiniBand®, Bluetooth®, Wi-Fi®, WiMAX, 3G, 4G LTE, etc.) to effect such communication.
  • communication technology e.g., wired or wireless communications
  • associated protocols e.g., Ethernet, InfiniBand®, Bluetooth®, Wi-Fi®, WiMAX, 3G, 4G LTE, etc.
  • the remote computing devices 104 are configured to access one or more features of the server 102 over the network 106 and/or via the SMS gateway 109.
  • the remote computing devices 104 may be mobile devices running the AndroidTM operating system by Google, Inc. of Mountain View, California and/or mobile devices running iOSTM operating system by Apple Inc. of Cupertino, California on which software has been installed to perform one or more actions according to an embodiment of the present disclosure.
  • the computing devices 104 may have an app installed that allows a user to perform one or more actions described herein.
  • the system 100 is described as being a cloud-based platform accessible by the remote computing devices 104, in some embodiments one or more features of the server 102 could be performed locally on the remote computing devices 104 depending on the circumstances.
  • the server 102 establishes an environment 200 during operation for the authentication and payment system 108.
  • the illustrative environment 200 includes a new user on-boarding manager 202, a SMS authentication engine 204, a virtual asset exchange manager 206, a hybrid ledger manager 208, a transaction manager 210, a notification manager 212, an ownership verification manager 214, a token manager 216, and a transaction and user repository 218.
  • the various components of the environment 200 may be embodied as hardware, firmware, software, or a combination thereof.
  • one or more of the components of the environment 200 may be embodied as circuitry or collection of electrical devices (e.g., new user on-boarding circuitry, SMS authentication engine circuitry, virtual asset exchange manager circuitry, hybrid ledger manager circuitry, transaction manager circuitry, notification manager circuitry, ownership verification manager circuitry, token manager circuitry).
  • the new user on-boarding manager 202, a SMS authentication engine 204, a virtual asset exchange manager 206, a hybrid ledger manager 208, a transaction manager 210, a notification manager 212, an ownership verification manager 214, a token manager 216, and a transaction and user repository 218 are embodied as hardware, firmware, or other resources of the server 102.
  • those components may be embodied as hardware, firmware, or other resources of the computing device 104. Additionally, in some embodiments, one or more of the illustrative components may form a portion of another component and/or one or more of the illustrative components may be independent of one another.
  • the new user on-boarding manager 202 is configured to gather certain information from a new user and register the user’s phone number and computing device 104 with the system 100.
  • the new user on-boarding manager 202 may be configured to gather the phone number and/or other identifying information about the user, such as username, email address.
  • the on-boarding manager 202 may send a confirmation code to the phone number entered by the user, which links the computing device 104 with that phone number.
  • the system 100 limits use of the phone number linked to the computing device 104 to be registered with the system 100 only a single time.
  • the computing device 104 could be assigned a unique device ID (UDID), which could be based on the device’s serial number, MAC ID, or other unique identifier.
  • UDID unique device ID
  • the user can only be linked to a single phone number in the system 100 for purposes of security.
  • the new user on-boarding manager 202 may also request the user to enter a global identifier (GID); embodiments are also contemplated in which the new user on-boarding manager 202 could auto-assign a GID to the user.
  • GID global identifier
  • the new user on-boarding manager 202 links the GID to the phone number that has been verified, which increases security.
  • the new user on-boarding manager could store a password, pin code, or biometric information of the user to unlock certain features of the server 102; in addition (or alternatively), the remote computing device 104 could store such information locally to unlock the application that accesses the server 102.
  • the new user on-boarding manager 202 could request a photograph (or auto-assign an avatar) that would be added to the user’s profile.
  • FIGS. 8 A - 8E illustrate an example method of onboarding a new user.
  • the SMS authentication engine 204 is configured to authenticate SMS messages to/from users requesting transactions within the system 100.
  • the SMS authentication engine 204 uses a One Time Key (OTK) in combination with other possible user-specific details to ensure the transaction generated and sent to the server 102 via an SMS message is secure, validated and verified prior to finalization of the transaction, while giving the user a simple, frictionless and seamless experience.
  • OTK One Time Key
  • the OTK keys are added to the user’s profile on the server 102 and passed to the remote computing device 104 to be stored in the device’s offline storage (redux persist data store).
  • the app on the remote computing device 104 is configured to request a synch function from the server 102 (e.g., contacts, data, transaction history, balance, price, user profile, etc.).
  • the SMS authentication engine 204 validates the device, such as using one or more of the UDID, phone number associated with the device, and/or GID.
  • the SMS authentication engine 204 removes all existing OTKs associated with the user’s profile, and generates new OTKs.
  • the new OTKs are stored in the user’s profile on the server 102 and sent to the device 104 for offline, local storage on the device 104, along with the response to the synch request with updated the user’s transaction history, balance, current digital asset exchange price.
  • the digital asset exchange price may be tied to the price of one or more commodity exchanges; for example, one digital asset unit could be valued at an amount or fraction of an amount at which a commodity typically trades on established commodity exchanges. For example, one digital asset unit could be a centigram of gold (i.e., hundredth of a gram of gold) or some other unit of measure of gold or another commodity. Accordingly, in this example, the value of the digital assets will vary based on the value of gold.
  • the OTKs are only used for authentication of offline transactions, and the SMS authentication engine 204 limits the number of times the OTKs can be used to perform transactions (i.e., send or receive digital assets) and/or request an update to the current digital asset exchange price.
  • the SMS authentication engine 204 limits the number of times the OTKs can be used to perform transactions (i.e., send or receive digital assets) and/or request an update to the current digital asset exchange price.
  • SMS authentication engine 204 authenticates a an offline transaction request received from a user via SMS, which is a request to transfer virtual assets (e.g., virtual money, gift card value, etc.) to another user, a request to receive virtual assets from another user, and/or a request to obtain the current digital asset exchange price.
  • virtual assets e.g., virtual money, gift card value, etc.
  • the app on the user’s device 104 may allow them to request certain transactions, such as send digital assets to another user. For example, the user may select another user to whom they want to send the digital assets and enter the amount of digital assets to transfer.
  • the app will collect the current balance (pre-transaction), the order amount, the user’s GID and transaction type (sending, receiving or virtual asset exchange price check) for the receiver and, in some embodiments, use base64 encoding to code the data.
  • the app then attaches a predefined key phrase, such as ‘Sending Centigrams’ followed by a system generated transaction syntax which includes the OTK for the transaction type (UserSentKey).
  • the app will then send the above content out via the default SMS app on the device 104 to a pre-designated phone number of the SMS gateway 109.
  • the app on the user’s device 104 deducts the sent amount from the current balance, and deletes the OTK key used for that transaction (regardless of the outcome).
  • the transaction is noted as an offline transaction sent to the server 102.
  • the SMS gateway 109 Upon receiving the SMS message, the SMS gateway 109 triggers a WebHook URL, which sends the content to the SMS message and the sender’s phone number to the URL address of the server 102.
  • the SMS authentication engine 204 receives the data from the SMS message and performs authentication. For example, the SMS authentication engine 204 could identify the transaction type (e.g., send, receive or obtain current digital asset exchange price). The SMS authentication engine 204 could look for the user’s GID in the transaction and user repository 218, and if no match, could trigger an error message indicating that the user is not recognized 401 and send an SMS back to the sender indicating the error message. Also, for security purposes, the SMS authentication engine 204 could prevent the user from doing another transaction until the user connects to the internet and a profile refresh is done.
  • the SMS authentication engine 204 could identify the transaction type (e.g., send, receive or obtain current digital asset exchange price).
  • the SMS authentication engine 204 could look for the user’s GID in the transaction and user repository 218, and if no match, could trigger an error message indicating that the user is not recognized 401 and send an SMS back to the sender indicating the error message.
  • the SMS authentication engine 204 could prevent the user from doing another transaction until the
  • the SMS authentication engine 204 finds the user’s GID in the transaction and user repository 218, the engine 204 will check the OTK to see if a match could be found associated with the user’s GID. If a match for the OTK cannot be found, then the SMS authentication engine 204 will reject the transaction and send back SMS with error message indicating the OTK was not recognized. The user’s balance will not reset until the user goes back online and the user will not be able to do another transaction until the user connects to the internet and a profile refresh is done. If the SMS authentication engine 204 finds the OTK associated with the user’s GID, the engine 204 will decode the syntax data in the SMS message and extract the transaction details.
  • the SMS authentication engine 204 will then remove the OTK associated with the user’s GID from the transaction and user repository 218. Next, the SMS authentication engine 204 will search for the GID for the receiver of the virtual assets in the transaction and user repository 218. The SMS authentication engine 204 will check the sender user’s current balance on the server 102 to determine if there is a match with the balance received in the SMS message. If there is not a match, the SMS authentication engine 204 will send the user trying to send virtual assets an error message indicating that the transaction is being rejected. The user will not be able to do another transaction until the user connects to the internet and a profile refresh is done for purpose of security.
  • the SMS authentication engine 204 determines whether the user trying to send virtual assets has enough balance to cover the sending amount. If not, the SMS authentication engine 204 will send a SMS message to the user indicating there are insufficient funds and prevent the user from doing another transaction until the user connects to the internet and a profile refresh is done. However, if the balance is enough to cover the transaction, the SMS authentication engine 204 will work with the transaction manager 210 to perform the transaction request as an online transaction on behalf of the sending user by adding all of the other user data from the user profile on the transaction and user repository 218.
  • the transaction manger 210 After performing potential internal checks to meet all requirements by the transaction manager 210, a calculation of fees for the transaction is calculated.
  • the transaction manger 210 then fetches the current server balance of the sender and receiver from the transaction and user repository 218, and creates a new transfer record in the transaction and user repository 218 that moves amounts between the send and receiver’s accounts.
  • the transaction manager then creates a transaction record which will update the sender’s transaction history in the transaction 210 and user repository 218, and update the sender’s balance post-deduction of the transaction, including transaction fees.
  • the transaction manager 210 creates a transaction record to update the receiver user’s transaction history in the transaction and user repository 218.
  • the transaction manager 210 may then fetch the current virtual asset exchange price, and insert a new transaction fee record.
  • the transaction manager 210 would then send a notification to the user receiving the virtual assets. For example, if the receiving user is online, the transaction manager 210 could use the notification manager 212 to send a notification through the network 106, which would allow the app on the receiver’s device 104 to populate a new balance and update the transaction history. The transaction manager 210 could also send a SMS to the receiving user with a send OTK included. If the receiving user is offline, the app will use the OTK security check, and if passed, it will update the receiving user’s balance and transaction history with the offline transaction.
  • the user interface on the app could indicate that the transaction is offline until the receiving user goes online, which will synch with the server 102, and update the app to remove the offline indicator associated with the transaction.
  • the app will remove the OTK from the device’s 104 local storage, and reduce the number of remaining OTK keys left to receive offline payments until the next time the device is online, which will replenish the OTKs keys on the receiving user’s device 104. Accordingly, the new balance for the receiving user is reflected even though the device 104 may be offline.
  • the virtual asset exchange manager 206 is configured to determine a current price for a virtual asset unit.
  • a virtual asset unit may be based on a price of an existing commodity market.
  • the virtual asset unit may be based on the gold commodity price in some embodiments.
  • a virtual asset unit may be a fraction of a typical mass in which the commodity is traded to keep transactional prices lower for users.
  • the virtual asset unit instead of setting the virtual asset unit as the price of a gold per ounce or gram, the virtual asset unit could be any fraction of that amount to keep transactional prices lower for users.
  • the virtual asset unit is set at 0.01 the price that gold is trading in grams.
  • each virtual asset unit would be worth $0.65; thus, in this example, a user could purchase 150 units of virtual assets for $97.50, excluding any transaction fees.
  • gold commodity prices are discussed herein for purposes of example, any commodity market could be used to determine the price for virtual asset units, including but not limited to precious metals commodity markets, energy commodity markets, industrial metal markets, agriculture markets, etc.
  • the virtual asset exchange manager 206 is configured to search for a current price in the selected commodity market and convert that price to the price of virtual asset units based on the selected factor.
  • the virtual asset exchange manager 206 determines the current trading price for gold is $68.00/gram
  • the virtual asset exchange manager 206 would calculate the price to buy a unit of virtual assets at $0.68 (i.e., $68 x 0.01). If a user would like to cash out virtual asset units, the virtual asset exchange manager 206 would likewise be able to determine the value in the appropriate currency based on the current market price of gold.
  • the hybrid ledger manager 208 is configured to record ownership of virtual assets in the platform in a manner that is not impacted by operational risks and aligns with regulatory policies in each jurisdiction.
  • the hybrid ledger manager 208 includes a private ledger 207 and a public ledger 209.
  • Each ledger has its unique capabilities that serve different purposes. The goal is to remain compliant with record keeping, AML, KYC, ATF, and other policies, while ensuring the ownership of the assets will not be compromised by closure of company operations.
  • the hybrid ledger manager 208 is designed to give the asset owners a public hashed record of their ownership without giving away any PII or other details about content while keeping such details safely within the private ledger 207 in line with industry standard level of privacy and compliance.
  • the hybrid ledger manager 208 overcomes these technical issues with distributed ledgers and blockchain technologies by providing both a level of privacy and compliance with regulations.
  • the ledgers 207, 209 manage audit and tracking of the virtual assets while a trusted custodian holds the physical assets backing them. This process is designed to ensure transparency, integrity and true individual ownership and claim over the assets at all times.
  • the purpose of the private ledger 207 is to store PII information about customers and every transaction on the server 102. That facilitates compliance with many laws and regulations such as, but not limited to, AML, KYC, CTF, Sanctions, GDPR, etc.; this additionally meets internal and external audits as they become required. This allows accounts to be removed in compliance with privacy policies and GDPR, without impacting the integrity of records, in relation to global network assets and ownerships of such assets.
  • the public ledger 209 keeps records of all transactions on the server 102 with the purpose to provide transparency, and gain trust of all stakeholders. In case the company operating server shuts down, the public ledger 209 will be the source of facts for all past transactions. This means users will be able to validate and prove their accounts’ existence and its balance via this public ledger 209 through private and public keys (hashed to ensure privacy) using the ownership verification manager 214. The data being saved into the public ledger 209 will hold all the needed details to prove ownership of the assets except any Personal Identifier Information.
  • All hard assets, such as gold or other commodities, used to generate the virtual assets managed by the server 102 are held by a globally trusted entity (custodian).
  • a globally trusted entity custodian
  • users have an independent record of ownership located on a public, immutable blockchain ledger 209 completely separate from the company operating the server 102.
  • the public ledger 209 remains valid and available regardless of the company continuing operations or not, as an immutable record and proof of ownership for token holders representing the assets held by the custodian.
  • owners of the virtual assets can claim the value of physical assets directly from the custodian who is instructed to follow instructions outlined in the terms and conditions on how to release assets to true owners if a right-to-claim-event is triggered.
  • the hybrid ledger manager 208 cooperates with the token manager to keep track of tokens that represent assets in a virtual format.
  • the public ledger 209 keep tracks of tokens generated by the token manager 216, which represent assets in a virtual format and are being transacted within the platform.
  • the tokens In order to access the server, the tokens must be issued and available for registered users to purchase directly on the platform (mobile app).
  • the hybrid ledger manager 208 cooperates with the SMS authentication engine 204 to synch transactions even with users that are not connected to the internet to the ledgers 207, 209.
  • FIG. 3 illustrates a method 300 for recording transactions in the hybrid ledgers
  • the operations of the method 300 may be performed by one or more components of the environment 200 of the authentication and payment system 108 as shown in FIG. 2, such as the hybrid ledger manager 208.
  • the order of steps for the method 300 shown in FIG. 3 are for purposes of example, and could be in a different order; likewise, depending on the circumstances, some steps shown in the method 300 may be optional, or may not always be performed by the hybrid ledger manager
  • the method 300 begins in block 302 in which a transaction request has been authenticated. The method advances to block 304 in which transaction details are converted to internal formats. Next, the method 300 proceeds to block 306 in which the data pack in the transaction request is sent to the risk rules, which could include all the regulatory and compliance rules based on user demographics, local regulations and internal risk models. An evaluation is made to determine compliance with the risk rules (block 308). If the data pack fails the risk rules, the transaction is declined (block 310), and an email notification and SMS is sent to the user (block 312). The method 300 also activates risk modeling models for the sender and receiver profiles and automatic result is triggered, if applicable (block 314).
  • the risk rules could include all the regulatory and compliance rules based on user demographics, local regulations and internal risk models.
  • An evaluation is made to determine compliance with the risk rules (block 308). If the data pack fails the risk rules, the transaction is declined (block 310), and an email notification and SMS is sent to the user (block 312).
  • the method 300 also activates risk modeling models
  • the method 300 proceeds to block 316 to prepare data to be passed to both ledgers 207, 209.
  • a block in the blockchain is generated that includes the user’s GID, associated PII, and a hash of the transaction.
  • the public ledger 209 a block in the blockchain is created with a hash of the transaction, but without PII of the parties of the transaction.
  • the remote computing device 104 establishes an environment 219 during operation for connecting to services provided by the server 102.
  • the illustrative environment 219 includes a virtual asset ordering manager 220, notification engine 222, a connection manager 224, and a transaction manager 226.
  • the various components of the environment 219 may be embodied as hardware, firmware, software, or a combination thereof.
  • one or more of the components of the environment 219 may be embodied as circuitry or collection of electrical devices (e.g., virtual asset ordering manager circuitry, notification engine circuitry, connection manager circuitry, transaction manager circuitry).
  • the virtual asset ordering manager 220, notification engine 222, connection manager 224, and transaction manager 226 are embodied as hardware, firmware, or other resources of the remote computing device 104. Additionally or alternatively, in some embodiments, those components may be embodied as hardware, firmware, or other resources of the server 102. Additionally, in some embodiments, one or more of the illustrative components may form a portion of another component and/or one or more of the illustrative components may be independent of one another.
  • the virtual asset ordering manager 220 is configured to purchase virtual assets from the server 102.
  • the server 102 provides a virtual asset exchange that allows users to purchase micro-amounts of commodities, such as centigrams of gold, etc.
  • the virtual asset ordering manager 220 is configured to present a user interface from which the user can select an amount of virtual assets to purchase, and see the amount of such virtual assets based on a current price of commodities on which the virtual asset is based.
  • the remote computing device 104 may connect with the payment gateway to purchase virtual assets with a credit card, debit card, or other digital wallet, etc.
  • the notification engine 222 is configured to present the user with an alert to receive of messages from the server 102.
  • the notification could be sent through the network 106 or via SMS message to the remote computing device 104.
  • connection manager 224 is configured to detect whether the remote computing device 104 is currently online or offline. As described herein, transactions can be performed even when the user is offline, but could be limited in some ways, such as a number of OTKs available.
  • the transaction manager 226 is configured to initiate transactions with the server 102, such as a payment transaction, refund transaction and/or a current price for a virtual asset unit.
  • the remote computing device includes storage 228 on which the user profile and OTKs are stored for use when the remote computing device 104 is offline.
  • the payment gateway 226 may be provided by stripeTM of Stripe, Inc. of San Francisco, California and the SMS gateway 228 could be provided by TrulioTM of Trulio, Inc. of San Francisco, California.
  • the notification manager 212 of the server 102 and/or notification engine 222 of the remote computing device could use third party notification services, such as FirebaseTM by Google Inc. of Mountain View, California.
  • FIGS. 4A - 4B illustrate a method 400 for performing a transaction where virtual assets are being sent from a sending user 402 to a receiving user 404 in which both the sending user 402 and the receiving user 404 are both online and can communicate over the network 106 with the server 102 over the internet.
  • the operations of the method 400 may be performed by one or more components of the environment 200 established by the server 102 and environment 219 established by the remote computing devices 104 of the sending user 402 and the receiving user 404.
  • the method 400 begins in block 406 in which the sending user 402 would use the app on the remote computing device to select a receiver user 404 and an amount of virtual assets to send.
  • the app on the remote computing device 104 could allow the sending user 402 to search for registered users and select a registered user to whom to send virtual assets.
  • the receiver user 404 and amount of virtual assets entered by the sending user 402 on the remote computing device 104 would be sent as a payment request to the server 102 through the network 106 since both users are connected to the internet in this example. This is noted as “Send CentigramTM Request” on FIG. 4A.
  • the server 102 In response to the payment request (block 408), the server 102 would use the OTK of the receiver user 404 and generate a SMS to send to the receiver user 404 (block 410).
  • the method 400 proceeds to block 412 in which the server 102 sends the SMS message with OTK to the SMS gateway, which could be performed using a third party API 111 (block 414).
  • the SMS gateway is provided by TwilioTM.
  • the server 102 would also send a push notification request to a third party API 111 (block 416), which could be provided by FirebaseTM, which is noted as FCM in FIGS 4A and 4B.
  • the method 400 proceeds to block 418 in which the server 102 sends a response to the sending user 402 as to whether the transaction was successful or failed. As discussed herein, the transaction may fail after checking the user’s balance and/or other regulatory tests. An acknowledgement regarding success or failure of the transaction may also be sent to the sending user 402 by the push notification service 111 (block 420). As shown, the sender user 402’ s remote computing device sends a request for transaction history (block 422). This example continues to FIG.
  • the method 400 continues to block 425 in which a push notification is sent to the receiving user 404’ s remote computing device 104, which is received by the receiving user’s remote computing device (block 426).
  • the receiving user 404 ’s remote computing device 104 also receives the SMS message (block 428), but because the receiving user’s 404 device is online, the app’s SMS listener is not working.
  • the receiving user 404 will request an update to the transaction history (block 430), which will be received by the server 102 (block 432).
  • the server 102 will send an updated transaction history to the receiving user 404’s device 104 (block 434), which will complete the transaction in this example (block 436).
  • FIGS. 5A - 5B illustrate a method 500 for performing a transaction where virtual assets are being sent from a sending user 502 to a receiving user 504 in which the sending user 502 is connected to the internet, but the receiving user 504 is offline without access to the internet.
  • the operations of the method 500 may be performed by one or more components of the environment 200 established by the server 102 and environment 219 established by the remote computing devices 104 of the sending user 502 and the receiving user 504. Also, it should be appreciated that the order of steps for the method 500 shown in FIG.
  • the method 500 begins in block 506 in which the sending user 502 would select a receiver user 504 and an amount of virtual assets to send.
  • the app on the remote computing device 104 could allow the sending user 502 to search for registered users and select a registered user to whom to send virtual assets.
  • the receiver user 504 and amount of virtual assets entered by the sending user 502 on the remote computing device 104 would be sent as a payment request to the server 102 through the network 106 since the sending user 502 is connected to the internet in this example.
  • the server 102 In response to the payment request (block 508), the server 102 would use the OTK of the receiver user 504 and generate a SMS to send to the receiver user 504 (block 510). As shown, the method 500 proceeds to block 512 in which the server 102 sends the SMS message with OTK to the SMS gateway, which could be performed using a third party API 111 (block 514), which as TwilioTM. The server 102 would also send a push notification request to a third party API 111 (block 516), which could be provided by FirebaseTM, which is noted as FCM in FIGS 5 A and 5B.
  • the method 500 proceeds to block 518 in which the server 102 sends a response to the sending user 502 as to whether the transaction was successful or failed.
  • the transaction may fail after checking the user’s balance and/or other regulatory tests.
  • An acknowledgement regarding success or failure of the transaction may also be sent to the sending user 502 by the push notification service 111 (block 520).
  • the sender user 502’s remote computing device sends a request for transaction history (block 522).
  • the server 102 sends a response to the sender’s 502 remote computing device 104 with the updated transaction history data (block 524).
  • the method 400 continues to block 525 in which a push notification is sent to the receiving user 504’s remote computing device 104, which is not received because the receiving user’s remote computing device is offline (block 526).
  • the receiving user 504’s remote computing device 104 receives the SMS message (block 528), and a determination is made whether the OTK in the SMS message matches with a OTK stored in offline storage of the receiving user’s 504 device 104.
  • the receiving user 504’s digital wallet and transaction history will be updated upon decrypting the SMS data (block 530), which will complete the transaction in this example (block 532).
  • FIGS. 6A - 6F illustrate a method 600 for performing a transaction where virtual assets are being sent from a sending user 602, which is offline without a connection to the internet, to a receiving user 604, which is online with access to the internet.
  • the operations of the method 600 may be performed by one or more components of the environment 200 established by the server 102 and environment 219 established by the remote computing devices 104 of the sending user 602 and the receiving user 604. Also, it should be appreciated that the order of steps for the method 600 shown in FIG.
  • the method 600 begins in block 606 in which the sending user 602 is offline without access to the internet.
  • the method proceeds to block 608 in which the sending user 602 would select a receiver user 604 and an amount of virtual assets to send.
  • a plurality of potential receiving users could be stored in local storage of the sending user’s device 104.
  • the method advances to block 610 in which the sending user would select “send” on the device 104, and the app on the sending user 602’s device 104 will deduct the selected amount from the local digital wallet, send an SMS message to the phone number associated with the SMS gateway with the sending user 602’ s current balance, total amount to of virtual assets to send, the GID of the receiving user 604 and OTK, along with other possible information in the SMS message.
  • the SMS gateway Upon receiving the SMS message from the sending user 602, the SMS gateway will make a call to the URL of the server 102 and send the data from the SMS message to the server (block 612).
  • the server 102 will receive the data from the SMS gateway (block 614) and evaluate the user data using the sending user 602’s phone number to determine whether the user is registered (block 616). The method 600 proceeds to block 618, in which the server 102 determines whether the user is found based on, for example, the phone number of the sending user 602.
  • the method 600 continues on in FIG. 6B. If the sending user 602 is not found based on the mobile number, an error message is sent via SMS request to the SMS gateway (block 620).
  • the SMS gateway receives the SMS request (block 622) and sends a SMS message to the user (block 624). However, if the user is found (e.g., based on an authorized phone number) (block 626), the server 102 extracts the OTK and SMS data to determine whether a match can be made with an existing user profile (block 628).
  • the server 102 will determine that something went wrong with the sending user 602’s app and will need to be online again to generate a new OTK keys, and an error message will be sent to the SMS gateway (block 632), which will send a SMS message to the sending user 602’s device 104 (block 634).
  • the method 600 continues on in FIG. 6C.
  • the SMS error message is received by the sender user’s 602 device 104 (block 636). If the server 102 determines the OTK received in the SMS message matches an OTK associated with the sending user’s 602 profile that means the user is authorized (block 638).
  • the method 600 proceeds to block 640 in which the server 102 evaluates the GID of the receiving user in the SMS message to determine if the GID is found as an authorized user. If the GID of the receiving user 604 is not found (block 642), the server 102 determines that something went wrong, and sends a SMS request to the SMS gateway requesting an error message be sent to the sending user 602 (block 644).
  • the SMS gateway will then send a SMS message with the error message to the sender user 602 (block 646), which is received by the sender user 602 (block 648).
  • the method 600 continues on FIG. 6D at block 650 in which the server 102 compares the user’s balance on the server 102 with the user balance received in the SMS data. If the balance on the server 102 and that in the SMS message are not the same (block 652), this means something went wrong and an error message needs to be sent (block 654) by the SMS gateway, which is received by the sending user 602’s device (block 656).
  • the server 102 also checks whether the sending user’s balance, plus any transaction charges, exceeds the amount of virtual assets in the sending user’s balance (block 660).
  • the server 102 sends a SMS message request with an error message to the SMS gateway (block 664).
  • the SMS gateway receives the SMS request from the server (block 666), and sends the requested SMS message to the sender user’s 602 device 104, which is received (block 668).
  • the method 600 continues on FIG. 6E at block 670 in which the server 102 determines that the transaction is authorized, a process of transferring the requested virtual assets should begin.
  • the method proceeds to block 672 in which the server 102 inserts several records in the ledgers, such as a new transfer record, inserts a new transaction record, inserts a transaction fee record, and updates the wallet of the receiving user 604.
  • the server 102 sends a push notification request to the notification gateway (block 674) and a SMS message with a OTK to the SMS gateway (block 676).
  • the notification gateway sends the data through a push notification to the receiving user 604 (block 678), which is received because the receiving user is online (block 680).
  • the method 600 continues on FIG. 6F at block 682 in which the receiving user 604’s device 104 receives the SMS message, but since the user is online, the SMS listener is not working.
  • the method 600 proceeds to block 684 in which the receiving user 604’s device receives the push notification, which will cause the app to request an update to the transaction history.
  • the method advances to block 686 in which the server 102 receives the transaction history request, which responds with an updated transaction history with a transaction identifier.
  • the receiving user 604’s device receives the new transaction history with the new transaction data received from the server (block 688), and the transaction in this example is completed (block 690).
  • FIGS. 7A - 7G illustrate a method 700 for performing a transaction where virtual assets are being sent from a sending user 702, which is offline without access to the internet, to a receiving user 704, which is also offline without access to the internet.
  • the operations of the method 700 may be performed by one or more components of the environment 200 established by the server 102 and environment 219 established by the remote computing devices 104 of the sending user 702 and the receiving user 704. Also, it should be appreciated that the order of steps for the method 700 shown in FIG.
  • the method 700 begins in block 706 in which the device 104 of the sender user 702 is offline without a connection to the internet.
  • the method proceeds to block 708 in which the sending user 602 would select the receiver user 704 and an amount of virtual assets to send. For example, a plurality of potential receiving users could be stored in local storage of the sending user’s 704 device 104.
  • the method advances to block 710 in which the sending user would select “send” on the device 104, and the app on the sending user 702’s device 104 will deduct the selected amount from the local digital wallet, send an SMS message to the phone number associated with the SMS gateway with the sending user 702’s current balance, total amount of virtual assets to send, the GID of the receiving user 604 and OTK, along with other possible information in the SMS message.
  • the SMS gateway Upon receiving the SMS message from the sending user 702, the SMS gateway will make a call to the URL of the server 102 and send the data from the SMS message to the server (block 712).
  • the server 102 will receive the data from the SMS gateway (block 714) and evaluate the user data using the sending user 702’s phone number to determine whether the user is registered (block 716).
  • the method 700 continues on FIG. 7B at block 720, determines whether the user is found based on, for example, the phone number of the sending user 702. If the sending user 702 is not found based on the mobile number, an error message is sent via SMS request to the SMS gateway, which is received by the SMS gateway (block 722) and sends a SMS message to the user (block 724). However, if the user is found (e.g., based on an authorized phone number) (block 726), the server 102 extracts the OTK and SMS data to determine whether a match can be made with an existing user profile (block 728).
  • the server 102 will determine that something went wrong with the sending user 702’s app and will need to be online again to generate new OTK keys, and an error message will be sent to the SMS gateway (block 732).
  • the method 700 continues on FIG. 7C at block 734 in which the SMS request is received from the SMS gateway, and the SMS error message is sent to the sending user 702’s device 104 (block 736). If the server 102 determines the OTK received in the SMS message matches an OTK associated with the sending user’s 702 profile that means the user is authorized (block 738).
  • the method 700 proceeds to block 740 in which the server 102 evaluates the GID of the receiving user 704 in the SMS message to determine if the GID is found as an authorized user. If the GID of the receiving user 704 is not found (block 742), the server 102 determines that something went wrong, and sends a SMS request to the SMS gateway requesting an error message be sent to the sending user 702 (block 744). The SMS gateway will then send a SMS message with the error message to the sender user 702 (block 746).
  • the method 700 continues on FIG. 7D at block 748 in which the sender user 702’s device 104 receives the SMS message.
  • the method 700 proceeds to block 750 in which the server 102 compares the user’s balance on the server 102 with the user balance received in the SMS data. If the balance on the server 102 and that in the SMS message are not the same (block 752), this means something went wrong and an error message request needs to be sent (block 754), which is send via SMS message by the SMS gateway (block 756), which is received by the sending user 702’s device (block 758).
  • the method 700 continues on FIG. 7E at block 760 in which the server 102 determines whether the sending user’s balance, plus any transaction charges, exceeds the amount of virtual assets in the sending user’s balance. If the amount of virtual assets in the balance of the sending user is insufficient to cover the amount requested to be sent to the receiving user 704, plus transaction charges, this means that something went wrong (block 762) and the server 102 sends a SMS message request with an error message to the SMS gateway (block 764).
  • the SMS gateway receives the SMS request from the server (block 766), and sends the requested SMS message to the sender user’s 702 device 104, which is received (block 768).
  • the method 700 continues on FIG. 7F at block 770 in which the server 102 determines that the transaction is authorized, a process of transferring the requested virtual assets should begin.
  • the method proceeds to block 772 in which the server 102 inserts several records in the ledgers, such as a new transfer record, inserts a new transaction record, inserts a transaction fee record, and updates the wallet of the receiving user 704.
  • the server 102 sends a push notification request to the notification gateway (block 774) and a SMS message with an OTK to the SMS gateway (block 776).
  • the method 700 proceeds with the notification gateway sending a push notification to the receiving user 704’s device 104 (block 778), but the receiving user 704’s device 104 is offline (block 780).
  • the method 700 continues on FIG. 7G at block 782 in which the push notification is not received because the receiving user’s remote computing device is offline.
  • the receiving user 704’s remote computing device 104 receives the SMS message (block 784), and a determination is made whether the OTK in the SMS message matches with a OTK stored in offline storage of the receiving user’s 704 device 104.
  • the receiving user’s digital wallet and transaction history will be updated upon decrypting the SMS data (block 786), which will complete the transaction in this example (block 788).
  • Figures 8A - 8E illustrate an example method of onboarding a new user.

Abstract

Plateforme infonuagique dans laquelle des utilisateurs peuvent effectuer des transactions financières avec des actifs virtuels (par exemple des cartes cadeaux, des microquantités de marchandises, etc.) sans connexion internet. Selon certains modes de réalisation, des utilisateurs hors ligne peuvent effectuer des transactions de paiement d'une manière sécurisée par SMS à l'aide d'un processus de vérification avant la génération d'un message SMS, pendant le processus de transmission, et au niveau de l'extrémité de réception pour agir collectivement comme des éléments de validation et de sécurité atténuant les risques potentiels inhérents à l'utilisation d'une messagerie SMS pour des transactions sécurisées. De plus, la validation et la vérification de la propriété d'un actif virtuel au niveau du point de vente peuvent être fournies sans que l'utilisateur ait besoin d'une connexion internet à un ou plusieurs serveurs.
PCT/CA2021/051213 2020-09-02 2021-09-02 Technologies utilisant une chaîne de blocs pour un traitement de transaction hors ligne sécurisé WO2022047582A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202063073501P 2020-09-02 2020-09-02
US63/073,501 2020-09-02

Publications (1)

Publication Number Publication Date
WO2022047582A1 true WO2022047582A1 (fr) 2022-03-10

Family

ID=80492286

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2021/051213 WO2022047582A1 (fr) 2020-09-02 2021-09-02 Technologies utilisant une chaîne de blocs pour un traitement de transaction hors ligne sécurisé

Country Status (1)

Country Link
WO (1) WO2022047582A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115037484A (zh) * 2022-08-10 2022-09-09 捷德(中国)科技有限公司 数字藏品的领用方法、装置及电子设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070255652A1 (en) * 2006-03-30 2007-11-01 Obopay Inc. Mobile Person-to-Person Payment System

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070255652A1 (en) * 2006-03-30 2007-11-01 Obopay Inc. Mobile Person-to-Person Payment System

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FLORENCIO, D. ET AL.: "One-Time Password Access to Any Server without Changing the Server", INTERNATIONAL CONFERENCE ON INFORMATION SECURITY, 2008, pages 401 - 420, XP019104456, Retrieved from the Internet <URL:https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.630.7726&rep=repl&tvpe=pdf> [retrieved on 20211020] *
NITIKA RAI, ET AL: "M-Wallet: An SMS based payment system", INTERNATIONAL JOURNAL OF ENGINEERING RESEARCH AND APPLICATIONS (IJERA, 30 March 2012 (2012-03-30), pages 258 - 263, XP055697256, Retrieved from the Internet <URL:https://www.ijera.com/special_issue/VNCET_Mar_2012/48.pdf> [retrieved on 20200520] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115037484A (zh) * 2022-08-10 2022-09-09 捷德(中国)科技有限公司 数字藏品的领用方法、装置及电子设备

Similar Documents

Publication Publication Date Title
US11861610B2 (en) Public ledger authentication system
US11030593B2 (en) Processing authorization request using seasoned data
CN109328445B (zh) 唯一令牌认证验证值
US11615408B2 (en) Multi-signature verification network
US8099368B2 (en) Intermediary service and method for processing financial transaction data with mobile device confirmation
US20180330342A1 (en) Digital asset account management
RU2708947C2 (ru) Устройство с несколькими идентификаторами
US20160253663A1 (en) Transaction signing utilizing asymmetric cryptography
US11636479B2 (en) Computer-implemented system and method for performing social network secure transactions
US20150120559A1 (en) Enhancements to transaction processing in a secure environment
RU2699409C1 (ru) Системы и способы для использования в аутентификации пользователей применительно к сетевым транзакциям
US20070063017A1 (en) System and method for securely making payments and deposits
WO2020132635A1 (fr) Vérification et enregistrement d&#39;une activité suspecte sur la base d&#39;une chaîne de blocs
US20210049614A1 (en) Digital access code
US20240073022A1 (en) Virtual access credential interaction system and method
WO2022047582A1 (fr) Technologies utilisant une chaîne de blocs pour un traitement de transaction hors ligne sécurisé
US20190279196A1 (en) Systems and methods for digitizing payment card accounts
US20210241255A1 (en) Method, apparatus and system to access secure linked account information
WO2010054259A1 (fr) Service d’intermédiaire et procédé pour traiter des données de transaction financière avec confirmation par dispositif mobile
Alsadi et al. Challenges and Risks of Developing a Payment Facilitator Model
GHOSH et al. DEVICE AND METHOD FOR ACCEPTING CENTRAL BANK DIGITAL CURRENCY (CBDC) IN PAYMENT NETWORKS
CN114928448A (zh) 交互账户令牌化系统和方法
Wafula Muliaro et al. Enhancing Personal Identification Number (Pin) Mechanism To Provide Non-Repudiation Through Use Of Timestamps In Mobile Payment Systems.

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: 21863153

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: 21863153

Country of ref document: EP

Kind code of ref document: A1