WO2023230456A1 - Digital value exchanges linked to locations - Google Patents

Abstract

Electronic transfers of value may be secured via verification of locations of parties, and/or progressive trust building, while maintaining privacy of sensitive personal information of parties via separate communications by parties with a payment network server. Locations may be fixed geolocations, proximities, and/or positions relative to markers/beacons that are in motion. Transfers may be made from party to party, party to place and place to party, and/or party to a virtual point-of-sale at a place. Transferred items may be electronic funds in fiat and/or crypto currencies, Non-Fungible Tokens (NFTs) / data associated NFTs, electronic data, and/or securities / financial instruments, for example. Transactions may be multiparty and may comprise multiple exchanges of value.

Description

DIGITAL VALUE EXCHANGES LINKED TO LOCATIONS

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Pat. App. SN 63/365,170 titled “Digital Payments With Resolved Proximity,” U.S. Provisional Pat. App. SN 63/344,768, titled “Digital Payments With Offline Blockchain Support,” and U.S. Provisional Pat. App. SN 63/344,751, titled “Digital Payments With Distributed Web Security,” all filed May 23, 2022, the content of which are hereby incorporated by reference. BACKGROUND

[0002] This disclosure pertains to mobile commerce including payments made from and to mobile devices that are secured in view of the geographic location of devices, relative location of devices, and/or proximity of two or more devices.

SUMMARY

[0003] Transfers of electronic funds, data, and/or electronic currencies may be secured using location information such as absolute geographic location, relative geographic location, history of travel, and/or proximity of users to each other, beacons, markers, or intermediary devices. Security policies may be dynamically applied based on location, availability of funds, transaction histories, applicable regulations, and security information previously provided by users. Required security information may be obtained progressively from users as needed for particular transactions. For example, more information may be required regarding the identities of parties depending on local requirements for each party, and/or required due to varying detected levels of risk in view of location information.

[0004] Transfers of electronic funds, data, and/or electronic currencies may be made among two or more parties. Alternatively, transfers may be made to and from a designated location in transactions involving single users. Further, transfers may be achieved by users in a combination of single-sided transactions involving one or more locations. A user may register ownership of a location for purposes of receiving payments or otherwise making transfers to and from the owned location.

[0005] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings of example scenarios and processes.

[0007] Figure 1 is a block diagram of a payment network system operating in an environment of location information sources.

[0008] Figure 2 is a flow chart of a process for progressive trust building.

[0009] Figure 3 is a flow chart of a process for progressive location determination.

[0010] Figure 4 is a flow chart of a process for identifying transaction targets.

[0011] Figure 5 is a flow chart of a process for determining a transaction amount.

[0012] Figure 6 is a flow chart of a process for transferring a payment.

[0013] Figure 7 is a block diagram of a transfer between users of a payment network.

[0014] Figure 8 is a block diagram of a “money drop,” where a location serves as a holder of value.

[0015] Figure 9 is a block diagram of a “virtual point-of-sale,” where a location is registered to a user for a business purpose.

[0016] Figure 10 is a block diagram of an example system with multiple ledgers. DETAILED DESCRIPTION

[0017] SYSTEM OVERVIEW

[0018] Parties to Transactions

[0019] Figure 1 illustrates an example system in which transfers may be secured using location and/or proximity information. In the example of Figure 1, there are two users, User A and User B, who wish to conduct a transaction. In practice, there could be more parties to the transaction. Alternatively, a transaction may be one sided initially, with one party making a transfer to a place or an object, with or without knowledge of who eventually will become the beneficiary of the transfer, for example.

[0020] User Devices

[0021] In Figure I, each user has a computing device. Each device may be a mobile computing device, such as a smart phone, tablet, or laptop computer, for example. Alternatively, one or of the devices may a non-mobile device such as a desktop computer or digital kiosk. [0022] Payment Network

[0023] Each user device is connected via one or more communications network links to a server of a payment network. The payment network server manages an electronic wallet for each user. Each wallet contains information necessary completing a transaction on behalf of each user when properly authorized by said user. The payment network server serves as an arbiter to ensure that exchanges are made into and out of each wallet when properly authorized and verified.

[0024] Architecture of Payment Network

[0025] It will be appreciated that in practice the functionality of the payment network server may be distributed in any number of physical devices and/or processes operating on computing devices. That is, the payment network is a virtual network of devices that may be interconnect via any communications network technology.

[0026] Distribution of Payment Network in Devices

[0027] Further, functionality of the payment network server may be partly distributed to user devices and/or intermediary devices. For example, a user device’s device may be configured with a software application and/or a web connection whereby the user’s device is able to monitor the user’s wallet, arrange for external transfers replenish or withdraw from the wallet, prompt the user for information needed to accomplish transactions, and apply rules about whether transactions are permissible.

[0028] External Gateways

[0029] The payment network server may be connected to any number of external systems gateways. In the example of Figure 1, the payment network server is connected to a bank, a market gateway, other external payment system gateways, and a verification entity. In the case of managing monetary transfers, for example, such connection may be used to send funds from customer wallets to external accounts, and from which transferred items funds can be pulled from external payment system accounts into customer wallets. The server can move funds between wallets, out a payment system gateway, and in from a payment system gatew ay. The server can move electronic value in and out the market gateway in many forms, securities, cry pto, crypto with associated data (e g., NFTs), and domain-specific information, such as items of value in a particular computer game or other electronic market

[0030] A third-party entity' may be called upon to verily information provided by users and/or present status of accounts. The payment network server may use links to a stock market gateway, a cryptocurrency gateway, and/or a data repository, for example, in the management of various types of electronic transfers. [0031] Intermediary devices

[0032] Figure 1 also shows an optional intermediary device. This may be an NFC or local network communicating device, or even a Wi-Fi network, that user A’s device and user B’s device can both see. The intermediary device may be provided by a third party to facilitate transactions between users, e.g., without the third party having any access to transactional information.

[0033] NATURE OF TRANSACTIONS

[0034] Cash Transactions

[0035] Transfers may involve electronic funds of standard currency, data, crypto currencies, stocks, instruments, etc., or combinations thereof. For example, to exchange local fiat currency the payment network may make credits and debits to user wallets, then settle to the exchange via communications with user banks and/or other financial institutions.

[0036] Crypto Transactions

[0037] Similarly, to exchange crypto currencies such as Bitcoin and the like, the payment network server may first record exchanges marked with cryptographic signatures in the user’s wallets, and then communicate the transfers to an external crypto coin exchange for registration on the public. Alternatively, the payment network may act as the crypto currency exchange. Where the payment network is not acting directly as the crypto currency exchange, crypto currency transactions may be initially logged within the payment network system using its own crypto coin, off of the public blockchain, prior to settling through an external exchange on the public blockchain.

[0038] Data Transactions

[0039] Users may also use a payment network to move various pieces of data, such as a ticket to attend an event, a coupon, or a token, e.g., setting a token in particular place. For example, movie tickets may be placed by a first user at a certain location for retneval later by a second user, or the tickets may be sent from one wallet to another. Similarly, the necessary credentials to claim title to a financial instrument may be place at a location or transferred wallet-to-wallet.

[0040] Use of Currency in Examples

[0041] Herein, exchanges are generally described in terms of currency. However, it will be appreciated that different details apply to different electronic items being transferred. For example, in the case of fiat currency (e.g., U.S. dollars,) crypto currency (e.g., Bitcoin,) Non-fungible Token (NFT,) marketable financial instrument (e.g., stock share or bond,) and the like, one may speak of moving the item from one wallet to another on the payment network server. However, the same may not apply to, for example, the distribution of software code (e.g., source, object, or FPGA instructions, etc.), coupons, or the like, where the payment network may be used for secure transfer of the item, but secure transfer may not necessarily require removal of the item from the sender’s wallet. For simplicity in explaining the examples, cash or its equivalent is assumed, but the reader will appreciate that variations to example processes would apply to different forms of electronic goods being exchanged.

[0042] The payment network server can perform currency conversion or other value conversion For example, each party may prefer to use a different currency. For example, user A could fund the transfer of a crypto currency coin (e.g., an amount of Bitcoin) to a user B via the payment system gateway transaction in fiat (e.g., US Dollars) currency. This conversion of value may be suggested by user A, accepted by user B, and enforced by the payment network server.

[0043] Positive, Negative, and Zero Values of Items Exchanged

[0044] Items exchanged need not have a positive cash value. For example, a receiving party may agree to take on a debt or other negative cash value. This may be done, for example, to give a refund, or to request a payment.

[0045] Items may be exchanged which have no value or not certain value. For example, coupons, non-cash rewards, and the like, may be exchanged via the payment network server.

[0046] Requirements and Conditions

[0047] The payment network server may enforce requirements and conditions set by the parties to a transaction and/or by regulatory bodies. That is, each party and/or the government may set requirements as to the form, documentation, and/or timing of the exchange and the identity and/or character of the parties, such as their role, business status, age, residency, home address, age, current location, bank, billing address, credit card type, account number, etc.

[0048] Information required for a transaction involving a particular merchant or other entity, for example, may involve Personally Identifiable Information (PII) (e.g., a customer account number) or contextual information that is specific to that merchant or other entity . Such information may be kept private by the system, including in communications with any third party. For example, a vendor at or near a sporting even may need to know about the season ticket holder status of a customer. The status may be verified by the payment management network and the resulted to the vendor without sharing any PII with the vendor. Similarly, the vendor may require an age check for alcohol sales and receive a binary response from the payment network server - old enough / not old enough under local regulations - without the vendor being permitted to see any identification of the customer or leam the age of the customer, any regulatory reporting requirements related to the sale may be managed by the payment network server such that proof of age checking is provided to authorities as required, without jeopardizing the privacy of the information by passing through the vendor’s staff or computing equipment. In general, while a great deal of PII may be exchanged with the payment network server to accomplish progressive trust building and/or secure transactions, the PII is exchanged only on an as-needed basis between the payment network server and other parties, rather than requiring parties to exchange sensitive personal information - or even public information which parties prefer to keep confidential - to accomplish an exchange.

[0049] Further, transactions may be conditioned on behaviors of the parties. Just as legal and institutional requirements and conditions may be considered in progressive trust building, similar mechanism may be employed to enforce requirements and conditions established by parties to a transaction.

[0050] For example, a vendor may have a policy of not extending credit to parties exhibiting risky behavior. Such a condition may exceed the normal conditions applied by the progressive trust building policies of the system in requiring, e.g., additional information to secure transaction based on a transaction risk score computed by the system. A transaction between a vendor and a consumer 18 years of age may be legal in the state where the transaction is conducted but fail to meet a policy of the vendor not to sell to persons under 21 , for instance.

[0051] Similarly, transactions may be conditioned on user behavior, e.g., such as agreeing to a reciprocal exchange. That is, exchanges may be unidirectional (e.g., a tip,) bidirectional (e.g., electronic payment for an electronic asset,) or multifaceted, (e.g., purchase of a vehicle to be delivered after agreeing to payment through the network and proffer of proof of insurance.)

[0052] LOCATION

[0053] Geographic Location, Relative Location, and Proximity

[0054] Each device can determine its location. Herein, the term “location” is used to refer to several kinds of information. Location may be an absolute geographical location, e.g., as defined by latitude and longitude or street address, for example. Location may be a relative location, e.g., within a distance of another object. Location may be proximity, e.g., where a device is known to be within a threshold of closeness to another object, or person, whether or not the exact distance is known. A location, for purposes of securing a transaction, may be any one of these, or any combination thereof. For example, a location may be within a radio network cell, at the intersection of Baker Street and Madison Avenue, 30 feet from a marking beacon, next to User B’s mobile device. Location may also refer to a history of travel, e.g., a sequence of relative or absolute geolocations, and/or proximities recorded over a period of time.

[0055] The payment network server may be able to determine the location of any and/or all devices, e.g., via data obtained from the devices and/or data obtained from other equipment sensing and/or communication with the devices.

[0056] Relative locations may be determined in a number of ways. For example, relative location may be determined based on an ascertainable position relative to a verifiable marker, where the absolute position of the marker is not known. For example, a QR marker on a service counter in the dining car of a train may have an uncertain current geolocation, e.g., in route between stops. However, the association between the QR marker and a certain train, certain train car, and even a certain position at the service counter may be derivable either from meta data without the QR code and/or online lookup. Similarly, a special purpose wireless beacon, be it an optical, audio, or radio beacon, for example, may be used to mark a mobile location. For example, a Wi-Fi base station on a vehicle, be it a train, boat, car, bus, etc., may serve as a mobile beacon that may be used by a user device or other equipment to identify a relative location.

[0057] Determining Location

[0058] Determining location may be done in a variety of ways. In the example of Figure 1, user A’s device receives signals from a Wi-Fi network and a cellular network. User A’s device can also use a local optical marker, such as a QR code. Alternatively, not shown, a marker may be a Near Field Communication (NFC) tag, an NFC standalone tag reader, or an NFC subsystem operating on another user’s device, for example. Instead of reading the optical marker, for instance, user A’s device might sense an RFID tag, an RFID reader, and RFID field of another device like user B’s device, or a personal network such a Bluetooth network of the user B’s device.

[0059] Sources of Location and Other Information

[0060] Like user devices, in addition to providing location information, beacons, markers, and intennediary devices, may convey identity, currency, and transfer amount information. For example, a QR code may convey, either directly or by reference to an index, identity information about a potential party to a transfer, amounts and currencies requested, conditions on transfers, and goods being exchanged. An NFC device on a vending cart may provide information on whom to make payment to, prices for different sizes of ice cream treats, and whether the merchant accepts payment in crypto currencies.

[0061] Proximity

[0062] NFC operations may be said to often provide proximity information, rather than geolocation information, inasmuch as they may only a binary data point: either a user device is within range, or it is not. Multiple cell towers, for example, may be used to triangulate a geolocation of a user who is within a mile of each tower, for example. A low- frequency near-field RFID tag may only provide information when the user’s device is within inches of the tag and provide no information about the exact distance. The payment network server may address such ambiguity in location while in the user experience, so that users are not puzzled by the myriad details that may be involved in the payment network server resolving the locations of the parties. Further, some ambiguity in location may be advantageous in keeping from user A the exact location of user B, for example. In practice this helps to inhibit stalkers and other bad actors, for example, from using the payment network for misdeeds.

[0063] Signing for Packages

[0064] Similarly, a first NFC tag may be used by a person receiving a package to “sign” for the delivery, and a second NFC tag may be presented by a delivery agent to confirm their presence at the delivery. This is in stark contrast to, for example, asking a delivery recipient to sign an LCD display of a mobile computer of a delivery person, where the mobile computer may have no way of verifying the identity of the delivery recipient, or conversely, no way to verify the presence of the correct recipient. This is also distinct from the use of an NFC tag to mark a location.

[0065] Sharing Information Sources

[0066] In the example of Figure 1, User B’s device receives signals from the same cellular network and from a local RF beacon. User’s B’s device also has a GPS receiver which is picking up signals from an orbital GPS satellite. Both user devices can see an intermediary device, which may be another mobile device, kiosk, etc., emitting a recognizable radio or optical signal.

[0067] Location Information Derived from Networks

[0068] Location information may be obtained from networks in a variety of ways. For example, a device connected to a network, whether wirelessly or by a wire or fiber connection, may receive specific information about the location of network hardware and/or a position of the device that has been computer / triangulated by the network. Similarly, a device may be able to infer the identity and location of a network transmitter or an RF beacon, e.g., through one or more of triangulation, lookup, and codes broadcast by the network.

[0069] Progressive Location Determination in Progressive Trust Building

[0070] As discussed in reference to Figure 1, there may be many ways to determine the locations of parties to a transaction. How location is determined can have an impact on the perceived security risk of a given transaction, and progressive trust building may adjust the requirements and/or prompting of users accordingly. Figure 3 illustrates an example process by which a location is determined - or found to be indeterminant. At the start of Figure 3, if the user is using a personal mobile device, the payment network may be able to determine that the user is at least proximate to the device, e.g., by being able to login. The payment network system - including the user devices, intermediary devices, and payment network server, for example - may then seek other sources of information, such as an onboard GPS receiver and navigation capability. The system may consider different sources of location to be in different tiers of reliability for security purposes, e.g., with descending prefer for GPS, beacon, Wi-Fi with known geolocation, Wi-Fi without known geolocation, near-field communication (NFC) in the area, marker (such as a QR code) with a known geolocation, and a marker without a known geolocation.

[0071] The quality and number of location information sources may be observed and considered in identifying location and/or determining a risk factor associated with the certainty of location. GPS satellite may provide the best information outdoors, and indoors if signal strength is high enough. Radio transmitters, including special purpose beacon and network transmitters, such as Bluetooth, Wi-Fi, and cellular transmitters, may be used to triangulate position. For example, the relative strengths of multiple Bluetooth signals may be considered. The strength of transmitter signals of different technologies may be compared, e.g., using two cell towers, a Wi-Fi signal, and a Bluetooth signal. Note, this triangulation can happen three dimensionally, in addition to two dimensionally. The payment network server may consider relative height difference between two users for example. The payment network server may consider the radio signal characteristics of various technologies used. For example, Wi-Fi is often deployed with signals in two frequency ranges which have different capacities for penetrating walls, resulting in different signal strengths and perfonnance characteristics. Bluetooth has a third set of performance characteristics. For example, a user of the payment network staying in a 50-story hotel, the payment netw ork server may compare the relative performance characteristics of the two Wi-Fi signal bands from a single base station, via readings taken at the user device and/or base station, allowing an inference of the number of walls between the user the Wi-Fi base station. Bluetooth does not propagate well through steel-reinforced concrete floors, because may penetrate plaster walls. So, with knowledge of signals available on a particular floor, the system may be able to accurately infer on which floor of the hotel the user is standing with their mobile device.

[0072] The example of Figure 3 nearly spans the terrestrial location identification gamut, with everything from signals from outer space to NFC devices, e.g., within a foot, to direct line of sight with a QR code. Note shown, but also available, is direct electrical or physical contact with an object. That is, progressive trust building can take advantage of progressive location determination, availing itself of information from as far away as space to as close as a QR code on a point-of-sale terminal. Significantly, it can take advantage of several or all of them to verify location, rather than relying on a single source. This make location information much harder to spoof and allows the system to make a well-informed decision about what supplemental security measures may be warranted based on the nature, reliability', and corroboration of location information.

[0073] This multi-technology approach enables various anti-spoofing technologies. For example, an ordinary' NFC or QR tag may can contain metadata including encoded information regarding the location of the tag and/or an ID value which may be used to lookup the location via a registry on the payment network server. The registry may further contain information about hidden anti -counterfeiting measures applied to the tag, such as hidden ink (security indicia not visible to the naked eye), secondary signals (e.g., and NFC tag hidden by a QR code sticker), or a radio signal to check for (e.g., a broadcast Wi-Fi network name in the vicinity that validates the presence of the QR code.)

[0074] The payment network system may take advantage of all situational information available via the user’s device or from other sources. For example, if the payment network system cannot directly determine the location of a user, it may, based on the radio, audio, and optical environment of the user’s device, and may do so in view of inertial readings of the user’s device since the last known position of the user. Depending on chemical sensors of a mobile device, smells may be considered. A person claiming to be standing at carnival in Rio may be distrusted because the phone’s microphone detects no street noise, and the infrared camera sensor suggests that the street is frozen. A person supposedly standing before a casting of Rodin’s Gates of Hell may be asked to provide a depth-image photo of the sculpture. If available, the payment network may seek confirmation of user's location via facial recognition features of the user’s device or other devices in the area, such as surveillance video.

[0075] Notably, the location information, through the lens of progressive trust building, can reveal suspicious behavior, e.g., in patterns of transactions and/or disparities between claimed and detected locations.

[0076] PROGRESSIVE TRUST BUILDING

[0077] The Need for Better Trust Management

[0078] Transaction security requirements, including legal requirements such as U.S. Anti-Money Laundering (AML) and Know Y our Customer (KY C) regulations, vary depending on such factors as the identities of the parties to a transaction, their current locations, the payment instrument being used, and what actions they have taken in the past. Further, legal requirements are themselves in flux. A user who might have been able to perform an action yesterday may be blocked tomorrow because of a new legal requirement or institutional policy.

[0079] Traditionally, this has been addressed in the online payment space by exhaustive user data collection during the onboarding of new users of an app and/or payment network. Data is sought for every scenario user might be able to enter with the app. Typically, this onboarding flow is implemented once, and is not variant per user or situation.

[0080] User privacy, the security of personal information, and the user experience of providing personal information may be enhanced in a number of ways. First is to only ask users to provide information that is needed to secure the transactions they actually perform. Second is transparency in letting users know when information is being gathered and doing so in language that consumers can easily understand. Third is the integration of data collection with specific transaction and regulatory requirements. Together, these approaches avoid the collection of unnecessary information upfront when a user joins the payment network and allow dynamic generation of dialogues with users to implement the latest antifraud solutions in a timely way. The result goes far beyond traditional “card not present” and online credit card transaction practices.

[0081] Upfront questionnaires used in traditional onboarding of users in payment systems are often ineffective in preventing online fraud. Further, users often abandon onboarding due to frustration, the lack of a clear rationale for the information collected, or lack of requested information being immediately available. [0082] Progressive Approach

[0083] Transactions may be secured using location information, other information, and verification techniques. To address changing situational requirements of changing locations and circumstances, and to simplify the user onboarding experience, a progressive approach may be used whereby security policies are dynamically applied based on the circumstances of a proposed transaction. Thus, factors such as location, availability of funds, transaction histories, applicable regulations, and security information previously provided by users may be considered Required security information may be obtained progressively from users as needed for particular transactions.

[0084] Different security requirements may apply to different actions that a user may request to be performed by the payment network. For example, each action may have a different associated data, location, and/or user status requirements, such that each action may require different information and/or a different verification requirement. Security requirements may be relative, absolute, and/or combinatorial. For example, a relative security requirement may be a requirement that depends on an overall risk assessment score for a proposed transaction. An absolute requirement may be, for instance, a minimum age of a user to perform a certain type of transaction. Combinations of requirements may include, for instance, that both user A and user B must meet a set of absolute or relative requirements in certain ways before allowing user A to perform a transaction with user B.

[0085] Information requirements may be presented to the user in a continuous process, as opposed to, or in addition to, a one-time gate procedure before using the application. For example, information requirements may be presented as required, rather than upfront. The payment network server may enforce these rules on a per user basis. Further, requirements may be updated at the payment network server dynamically, in near real time, e.g., in response to aggregate user behavior, administrator controls, we can update these rules in real-time.

[0086] The integration of data collection with specific transaction and regulatory requirements may be achieved, for example, using an extensible software-implemented Finite State Machine (FSM).

[0087] An FSM, acting on information provided to populate “states,” may provide either deterministic or non-deterministic assessments. For example, a deterministic assessment may be that a person is not authorized to conduct a particular transaction due to their age. A non-deterministic example is a risk score for a given user. In practice, non- deterministic assessment may then feed into a deterministic assessment, e.g., when a loan at a certain level is denied due to a risk score exceeding a certain threshold.

[0088] Notably, such assessments, whether rendered by an FSM or other automated means, can be used not only to render final transaction decisions, but also to coordinate progressive trust building dialogues with users of the payment network. Different user attempting to perform identical transactions, for example, may be asked different additional security or personal data questions - or no questions - depending on such variables as location, history of historical transactions, payment instruments, system usage thresholds, and timing issues, etc., in view of the current proposed transaction, identities of the parties, and applicable regulations.

[0089] Notably, the state of each party may be considered, both separately and in combination. Thus, for example, a user who was able to perform a certain transaction with a first vendor on the basis of information previously provided, may be challenged to provide additional information before conducting a nearly identical transaction with a second vendor. Hence, the personal information and history of each party may be weighed separately or jointly when checking what requirements pertain in a particular situation.

[0090] Mobile electronic devices, such as cell phones, tablets, laptops, and special purpose devices, can provide accurate dynamic location information which can then be used to secure transactions. Traditional location tracking for credit cards, in contrast, was limited to inferring a change in general location over time by inference from card data, based on often inaccurate or outdated database of locations of merchant POS terminals, or registration by user, e.g., of their vacation plans. The lack of automatic (or automatically verifiable) location information, however, rendered traditional solutions highly error prone. Progressive trust building can accommodate changes in your present location by initiating new procedures and/or new dialogues as required.

[0091] Similarly, progressive trust building may be adapted relative locations of parties to a transaction. For example, in a transaction between two users using cell phones, the closeness - or distance - of the users can be used as factor in determining risks associated with the transaction and remediation of the risk via progressive trust building. Similarly, the proximity of a cell phone of a first user to a point-of-sale device, marker, or intermediary device, and/or the geographic location of the cell phone, point-of-sale device, marker, or intermediary device, may be taken into account for purposes of progressive trust building.

[0092] The payment instrument may, in combination with location factors such as proximity, for example, play a part in determining the progressive trust building steps required for a particular transaction. For some transactions, close proximity between users may be required for the transaction to proceed. For example, if a crypto coin is to be passed from the mobile device of a payer to the mobile device of a receiver using Bluetooth, as opposed to using the Internet via cellular data or Wi-Fi, the short range (e.g., ~10m) Bluetooth link may be used for progressive trust building, e.g., by having the sender’s device issue a challenge via Bluetooth to the receiver and receive a response from the receiver, verifying proximity prior to completing the transaction. This case may require a different dialogue with the users than is used in other circumstances. Further, the mechanism for moving the crypto coin into and out of their phone may vary by user, and different approaches to registering the transaction on the public blockchain, if desired, may require different security protocols and different dialogues with the users.

[0093] Example Progressive Trust Building Flow

[0094] Figure 2 is a flow chart of an example set of operations for reducing fraud in digital payments through progressive trust building. The operations may be performed on a payment network server and/or devices such as those described in reference to Figure 1. In addition to the user wallets, the payment network server may have a user database which stores user activity, transactions, and user profiles. A user profile may include both verified and unverified information about a specific user. Unverified information, for example, may be accepted for a transaction with lower security requirements, whereas the same information may need to be verified for use in a transaction with higher security requirements.

[0095] In step 1 of Figure 2, a user attempts to initiate a payment network operation from their user device. In step 2, the payment network system compares information which has been collected about the user with requirements of the payment network for the operation.

[0096] Payment network system functions may be distributed in a number of ways. For example, the comparison of user information to the information requirements for a particular operation may be performed in the user device, in the payment server, or by the user device acting in concert with the payment network.

[0097] The sufficiency of the user information available for the operation may be determined using a set of tiers to identify sets of equivalent security requirements. For example, in Tier 1, the lowest tier, the user may be required to enter an email address. Tier 2 may require verification of the email address. The use of tiers may facilitate the use of alternative means to achieve a level of verification. For example, providing a phone number may be accepted as the equivalent of providing an email address for purposes of meeting a Tier 1 requirement.

[0098] Thus here, “tiers” is meant in the sense of equivalent levels of security for purposes of different kinds of transactions. Each user may achieve approval by the system for transactions of a certain kind via different combinations of information, for example. A particular set of user profile information required, at a minimum, for a user at one tier may have nothing to do with what is required for other users at a higher tier.

[0099] In the example of Figure 2, at step 2a an initial determination of the sufficiency of information is conducted in the user device, and at set 5. a a further determination is made at the payment network server. If in step 2a, if the device determines that sufficient information is not available to secure the transaction, then in step 2b the device determines what level of information is required.

[00100] The required information may be tiered, whereby transactions are divided into different security tiers, and the data collected is collected to meet the requirements of a tier. In practice, individual types of transactions may have unique requirements, and individual transactions may raise unique requirements. Nonetheless, the use of tiers provides the opportunity to accept alternative equivalent information. For example, a verified telephone number may be accepted in lieu of a verified email address at one tier, both may be required at a higher tier, and an unverified phone number or unverified email address may be accepted at a lower tier.

[00101] In step 3, the user’s device prompts the user for any additional information needed for the transaction, Alternatively or additionally, depending on the nature of the information to be collected, the user device may contact a third party for verification and/or additional data.

[00102] In step 4, once device believes the user has sufficient information on-file, it communicates the request for the operation to the payment network server.

[00103] Then in step 5a, the payment network server further verifies that the user has sufficient information on-file for the action requested based on the rules stored there. If sufficient information is not available, then in step 5b the payment network server may determine what information, or tier of information, is required, and in step 5c instruct the user’s device to collect additional information.

[00104] In step 5d, if sufficient information is available, the payment network server completes the action requested by the user’s device. This may involve making adjustments to a user’s wallets and/or conveying information to external financial system gateways, crypto currency exchanges, data storage locations, and the like.

[00105] In step 6, based on the behavior of the user, the payment network system may update rules associated with that individual user, or a class of users that includes the individual user, and may propagate such rules to one or more user devices.

[00106] No Onboarding Per Se

[00107] Notably, the user experience with the payment network system depicted in Figure 1 and Figure 2 need not involve any traditional onboarding process, e g., involving the entry of credit card, banking, financial, or other sensitive personal information upfront. Rather, during progressive trust building, the payment network server may require the entry of such information, but only as required for specific transactions that the user wishes to conduct, in the context of the transaction. Similarly, security authorization may be achieved at various tiers or for various purposes through, for example, multi-factor authentication, the delivery of nonces, password protection, proof of receipt of delivery of postal service at a given address, etc., yet such precautions may be invoked as required, rather than at the time of first usage of the payment network server or a related web site or user device software application.

[00108] The same information may be collected in different orders in different situations, as may be required for a transaction. For example, in a routine purchase scenario, a buyer may be asked to provide a verified email after they completed their payment to optionally send them a receipt. However, in a large value person to person transaction, a verified email may be required before the transaction as a security measure. In either case, using progressive trust building, if the verified email were already available to the payment network server, the user experience for the transaction would not require, and therefore not include, asking for the email address.

[00109] IDENTIFYING TARGETS

[00110] A user’s device, acting alone or in combination with the payment network server, may identify likely targets for a transaction. How this is done may depend on how the location of the user device was determined, as illustrated in Figure 4. For example, if a user’s device has access to a GPS or Wi-Fi location information, and the user device has Internet access, the user’s device may retrieve a list of nearby targets from the payment network server. This may reduce user device battery usage and provide the payment network server with real-time information about user activities. If the user device does not have Internet connectivity, the user device may use Bluetooth to scan for nearby targets. [00111] The search may start when the user has identified a target that she has in mind. Alternatively, the user’s device may search for potential targets generally available in the vicinity of the user. In either case, the user’s device may we present the user with a list of potential targets, when there is more than one, and ask the user to pick the target with which the user wishes to perform a transaction.

[00112] Determination of proximity and target may be combined. For example, a first user’s device may leam to transfer funds or other items based on scanning a QR code or other indicia displayed or broadcast by another user’s device. For instance, the first user may know nothing about the second user other than the fact that, obviously, the QR code displayed is displayed on the phone of the person they intend to pay. If the payment network server accepts the displayed QR code as legitimate, the transaction can be completed with the speed, convenience, anonymity, and privacy of a cash exchange, with the added advantage of an automatic record for the first user and the second user of the time, place, currency of exchange, and amount.

[00113] SETTING TRANSACTION AMOUNTS

[00114] The exact transfer may be set by one user or negotiated by the parties to the transaction. Again, the details of the interaction may affect perceived security risks and thereby trigger progressive trust building responses by the system. In the example of Figure 5, a user who intends to send funds has selected target to receive the funds. The sender’s user device and/or the payment network server may first check whether the target, who will receive the funds, has restrictions on the amounts they will accept, e.g., a minimum, a maximum, or a fixed amount. If not, e.g., for a gratuitous transfer or where the sender knows the amount to be paid, the sender may enter the desired amount of the transaction on their user device.

[00115] Alternatively, the sender may not know the exact amount that the recipient expects. For example, a diner in a restaurant may request a total bill or an item charge in a number of ways. The diner may receive a printed bill or an electronic notice of a bill amount. The diner’s device may be able to use an Internet connection, e.g., via a cellular or Wi-Fi connection, to receive an electronic tally from the restaurant. The diner’s device may be able to form a short-range connection, e.g., via Bluetooth, to a device controlled by the restaurant. The diner may also find the price by reading a QR code or NFC tag or device. In the latter case, the amount may be gotten either from data within the QR code of NFC tag or device directly, or by referencing an identity of the QR code of NFC tag or device online, for example. [00116] As in the restaurant example, the sender may be able to add a gratuity to a base amount requested by the receiver. In the example of Figure 5, the user has the option of adding a tip before completing the purchase.

[00117] Splitting the Bill

[00118] The example of TC5 assumes that two parties are involved - one sender and one receiver. But even in the simple case of a restaurant bill, this may not be the case. For example, assume that a group of people have decided to split the bill evening, and one diner in the group, acting as host, has agreed to coordinate paying the restaurant. The host announces to each other diner what their share would be, and the other diners each makes a payment to the host. The host is spared exchanging personal information with the other diners - in fact may strongly prefer not to exchanges personal information such as phone numbers, emails, or even their real name with fellow diners whom the host has just eaten. Instead, in a collection of side transactions, the host can collect funds from each of the other diners, through the payment network system on the basis of location, e.g., co-location in the restaurant / proximity of the host and the other diners. Once funds are received, the host may then pay the bill. The payment network system may manage this as a collection of unrelated transactions or, for convenience, provide an interface on the hosts device to track the number and number of payments received toward ultimate payment of the bill.

[00119] Specificity in Tipping

[00120] User control of payments allows addressing complex payment scenarios with ease and flexibility. For example, a group dining together may agree to level of tipping suggested by a host. However, an individual diner may separately leave an additional tip through the payment network system.

[00121] Similarly, in the case of home delivery, where traditionally a single tip is given to the delivery service, users may tip the delivery service separately from the restaurant. For example, a well-prepared meal may deserve a high tip, and sloppy delivery may merit a low tip. Rather than trusting the delivery service to share a gratuity equitably with restaurant staff, the person receiving the delivery can create separate transactions, potentially, for payments to the restaurant and the delivery staff and tips to the restaurant staff and delivery staff. By decoupling traditionally bundled transactions, the payment netw ork described herein may generally provide more efficient ways to reward good work and good products more directly than primary mechanisms allowed.

[00122] Tips may be directly routed to the server via the payment network server. For example, a single transaction may involve multiple parties, e.g., a diner, a restaurant, and wait staff. The restaurant and the wait staff may each receive funds directly from the diner independently via the payment network server. The payment of the bill to the restaurant would not depend on the wait staff entering payment from the diner, and the tip payment of the tip would not require approval from the restaurant, or even the restaurant knowing the amount of the tip. Each is paid independent of information about the other’s information, and without their consent. This ensures that the restaurant gets proper funds for the bill, and the diner can rest assured that the tip that they send goes entirely to the server without interference by the restaurant. Tips can be directed to pooled and divided in a number of ways, e.g., being directed to all restaurant staff and/or to kitchen staff, table staff, and/or individual servers.

[00123] Security Checks

[00124] Progressive trust building provides for dynamic checking of location, identity , and circumstances of parties before permitting a transaction to be executed. In a restaurant example, an underage user of the sy stem may be permitted to check a price by scanning a QR code with her personal mobile device, but the underage user, under local law, may be prohibited from acting as host or otherwise effecting an electronic funds transfer to pay the bill.

[00125] Similarly, checks may be performed dynamically on the basis of information known to the payment network sy stem, e.g., in a sender’s user device or in the payment network server, or in information provided by the receiver. For example, it may be required that a user be at least 18 years of age to conduct any electronic funds transfer but may need to be 21 to purchase liquor. The payment network server may be aware both that the user is 19 years of age and that the point-of-sale (POS) system targeted for payment resides in a liquor store and disqualify the transaction accordingly.

[00126] Alternatively, the payment network server may know that the POS resides in a liquor store, but not know the age of the user. Using progressive trust building, the payment network system may then prompt the user for their age and any other information necessary' to verify the user’s age.

[00127] Further, the payment network system may know neither the age of the user nor the nature of the exchange until prompted by the receiver that the transaction requires proof that the user is over a certain age, whereby the system then prompts for an age check.

[00128] Similarly, the payment network system may dynamically prompt for any information necessary to perfect transaction, e.g., as to class of identity (retailer, non-profit, registered broker, etc.), legal residency, citizenship, class of merchandise (alcohol, tobacco, firearms, pharmaceuticals, explosives, dangerous materials).

[00129] Alternative Pathways for Executing Transfers

[00130] Figure 6 illustrates alternative paths for completing a transaction depending on whether user devices have connectivity to the payment network server. Normally, transactions are recorded at the time of agreement of any needed parties to the transaction. The parties indicate their intention to the payment network server, which then may make any necessary' adjustments to user wallets and records, update any needed details for future actions and/or details of the transaction.

[00131] However, if an Internet connection to the payment network server is not available, the transaction may occur in two parts. First, a record of the transaction may be created cryptographically on one or both of the user devices. For example, user devices maybe able to use NFC and/or personal network technology' such as Bluetooth to exchange sufficient information to form a signed cry ptographic record / ledger entry of the transaction. Later, when connections to the payment network server are restored, the cryptographic record may be used to verify the interaction between the users and execute the exchange on the payment network server.

[00132] The recording of a transaction offline does not guarantee that the transaction will be approved by the payment network server. For example, details of the transaction may require, under progressive trust building, further interaction with the users to secure the transaction. Alternatively, it may be found that the proposed transaction cannot be permitted under law / local regulations, for example.

[00133] Transaction Fees

[00134] For simplicity, herein examples are given wherein the transfers of value are at par. That is, a receiver receives the amount sent by the sender, and a merchant receives the amount paid by a shopper, etc. However, in practice it will be understood that the amount received by one party may be adjusted by the system in a number of ways. For example, the payment network server may deduct transaction fees on a fixed and/or percentile basis. Further currency conversion rates, and associated fees, as well as other fees and service charges may apply

[00135] LOCATION BASED TRANSACTIONS

[00136] As described in connection with Figures 1-6, a payment network may be used to securely transfer money, data, crypto currency, and other electronic items between people, businesses, and other organizations. The payment network may be used, for example, for payments, donations, tipping, bill-spliting, in lieu of cash, while providing the convenience, privacy, and anonymity of a cash. Using progressive trust building and/or progressive location determination, for example, the routing of funds or other electronic items may be secured without the sender or receiver being aware of personal information about each other, such as account numbers, identity, online persona or handle, email address, or telephone number, etc., while fully complying with applicable commercial, financial, or other regulatory requirements.

[00137] The elements of Figure 7 are similar to those described in connection with Figure 1. Figure 7 illustrates an example set of interactions between two users - a sender and a receiver. Each has a computing device that may be a mobile device, such as a smart phone, tablet, or laptop computer, for example, or another device such as a desktop computer. Each device is able determine its location.

[00138] In the example of Figure 7, each device has access to different location information source. Each location information source may be a GPS signal, a beacon, Wi-Fi network signal, or a connection to another device or system.

[00139] Each user device is linked via one or more network connections to a server of a payment network. The server has an electronic wallet for each user. Each wallet contains information necessary for determining the availability of funds or other items for completing a transaction on behalf of the user, and for completing the transaction when properly authorized by the user. The server provides arbitration and management of each user wallet

[00140] Not shown in Figure 7, users may begin use of the payment network in a number of ways. For example, they may enroll via a website, by downloading a software application to their mobile device, in person, over the phone, or some combination therefore, e.g., via the use of multi-factor authentication. In lieu of traditional onboarding, a user may simply start using the system and, following progressive trust building procedures such as those described in connection with Figure 2, provide any information required for a particular transaction as required.

[00141] Also not shown in Figure 7 are gateways external to the payment network through which funds or other items may be sent from customer wallets to external accounts, and from which funds or other items can be pulled from external accounts into customer wallets. The server can move funds between wallets, out to an external system gateway, and in from an external system gateway. [00142] Each user device is equipped to facilitate location-based transaction, e.g., via downloading software and/or website instructions for accessing various subsystems of the user device. Location-based transactions may be based on the proximity of two user devices to each other, and/or the proximity of at least one of the devices to a physical location, e.g., as determined via progressive location determination operations such as those described in connection to Figure 3.

[00143] As discussed in reference to Figure 4, user devices may detect and identify in a number of ways. A device may detect the presence of another device directly via radio or optical sensing or signaling, e.g., via personal radio networks such as Bluetooth. A device may detect the presence of another indirectly, e.g., via information received from a network about the presence of another device.

[00144] The presence of other devices may be qualified by the participation of devices on a certain payment network, e.g., a PayTile network, whereby each device registered on the payment network is arranged to confirm to certain location-based transaction, security, privacy, and/or anonymity protocol. For example, a device may determine whether a qualified device is in its proximity either via direct communications with the device, communications with a local intermediary device, or via a network connection.

[00145] As discussed in reference to Figure 5, the details of an exchange may be determined and/or negotiated in a number of ways, e.g., by requesting information on an asked price and/or adding a tip.

[00146] As discussed in reference to Figure 2, location-based transactions may be qualified by the association of one or more devices with a physical location. For example, prior to performing a transaction, a first device may determine its location and then determine which other devices on the payment network are associated with the location.

[00147] As discussed in reference to Figure 3, a user device may determine its physical location in a number of w ays. The location may be an absolute geographic location, whereby the device may learn of its position via GPS signals or similar navigational tools, detection of a marker, beacon, and/or network signal associated with a fixed location. For example, a QR code may mark a location. An intermediary device, e.g., a device that is associated with the payment network but not with a specific user of the payment network, may also serve to mark a fixed location.

[00148] The location may be a relative location, whereby the device may learn of its location relative to a beacon, network signal, marker, or intermediary device that may be in motion and/or not associated with a fixed location. In this manner, for example, without known its geographic position, a device may still become aware of its relative location as aboard a vehicle, for example, or in the presence of a transient item.

[00149] QR codes and/or other signals or indicia presented by user and/or intermediary devices may be used to convey transaction details, identify parties for purposes of a transaction, and/or prove proximity of users to a location or to each other.

[00150] Example Location-Based Transaction Flow

[00151] Note that while the operations in Figures 7-9 are numbered, in practice the operations described may take a wide variety of sequences. Further, depending on circumstances and the nature of a transfer, some steps may be omitted while others, not depicted may be required, e.g., to accomplish progressive trust building, progressive location determination, perfect transfers internal to the payment network (e.g., obtain signatures), and/or perfect transfers to entities / institutions outside of the payment network (e.g., fully execute stock trades.)

[00152] In the example of Figure 1A, in a location-based transaction, money is sent directly from the wallet of a sender to the wallet of a receiver via the payment network. Here it is assumed that both users have mobile user devices adapted for communications with the payment network server.

[00153] In operation 1 of Figure 1A, the sender’s device determines its location and/or proximity to other devices. In the example of Figure 1A this is done via a sensing and/or connection to a location information source, such as a GPS signal, beacon, Wi-Fi signal, etc. Alternatively, the sender’s device may determine its location via communications with a network, such as the network that connects the sender’s device to the network. Further, the sender’s device may learn of its proximity to another device via communications with a network and/or via sensing or direct communications with the other device, e.g., via a short-range radio and/or optical sensing or networks. In operation 2, the receiver’s device determines its location via similar means.

[00154] In operation 3, each device reports its location and to the payment network server. Each device may also report other proximate user device and/or intermediary devices that it has discovered at its location.

[00155] In operation 4, the payment network server informs each device about the other. Alternatively, the devices may already have been in communication, and not need confirmation from the payment network server. However, it may be advantageous, for security, privacy, and anonymity , for example, for each device to receive confirmation from the payment network server regarding the membership and/or standing of the other device on the payment network, and/or confirmation of the association of the other device with the location.

[00156] In operation 5, the sender selects the receiver on their device, and in operation 6 selects how much to send to the receiver. The sender’s device may have a record of the sender’s available balance and/or be adapted to permit the sender to arrange for sufficient funds to become available on the payment network server in the sender’s wallet.

[00157] In operation 7, the sender’s device communicates, to the payment network server, the intention to make a payment to the recipient. Again, if sufficient funds are not available to support the transaction, the sender’s wallet may be replenished via operations not shown in Figure 7.

[00158] In operation 8, the payment network server removes the intended amount from the sender’s wallet and adds that amount to the receiver’s wallet. In operation 9, the receiver’s device is notified by the payment network server that receiver’s wallet has additional funds, and in operation 10, the receiver is notified by the receiver’s device that the receiver has received additional funds in their wallet.

[00159] Many variations in the details and/or sequence of operations depicted in Figure 7 will be understood in view of the discussions of Figures 1-6.

[00160] MONEY DROP

[00161] As discussed in reference to Figure 7, transfers between user wallets may be secured using progressive trust building and location information. Alternatively, transfers may be made to and from locations. That is, a transfer may be made into or out of a wallet maintained by the payment network server for a place, as opposed to a legal person, and conditions for further transactions with the location wallet can be associated with the location wallet.

[00162] Such transactions may take several forms. For example, a “money drop” may be made by a first user to a location with no conditions on whom may retrieve funds dropped at the location. Consider the example of diners splitting the bill at a restaurant. Imagine that one of the diners has not used the payment network does not have a mobile device on them. They promise verbally to repay the host by leaving a payment at an agreed location - a lamppost on the street near the restaurant. The next morning, the promiser returns to the lamppost with her cell phone and drops her share of funds, via the payment network, to a wallet for the lamppost. That afternoon, the dinner host returns to the lamppost and retrieves the dropped funds into host’s wallet. Via progressive trust building, the identities of the parties are determined to the satisfaction of the financial system in accordance with local regulations. Via progressive location determination, the presence of both parties at the lamppost is assured, albeit the parties may be at the location at different times.

[00163] This is just one example. A number of variations are possible, e.g., as to the locations, the time, and earmarking of the funds. For example, especially in the example of Figure 7, mutual presence at a location can be an important factor for trust between two parties. However, location is also an important factor in determining that any party using the payment network is who they say they are. So, for a money drop, where simultaneous presence of parties at a single location is not contemplated per se, the location of the drop may be different from the location of either party at the time of the drop. A person in China may drop funds for a person in England at the observation deck of the Eifel Tower.

[00164] Among the conditions that may be set for retrieving the funds, e.g., any business rules to be applied, are time limits and the presentation of credentials. A money drop may be indefinite in time, or expire rapidly, with funds returned to the sender at expiration.

[00165] A drop may be made to a location with the condition that only the legal owner of the location may retrieve the drop. That is, rather than merely using the location to mark a virtual transaction, the intent of the depositor may be that the deposit be intended for the legal person owning the land on which the drop is signified as located. This allows a form of tipping, for instance, without requiring depositor to know to whom the place belongs, while tying the ultimate transfer to place’s owner.

[00166] The retriever may need to present a credential, or no credential. For example, the drop may be free to anyone who discovers it via the payment network. Or the drop may be locked, to be opened only by the verified owner of a certain public key, for instance. Or a simple keyword may be used. The sender may communicate to the intended recipient that they money is at a location, to be retrieved upon presenting the password, “Joshua21,” for example.

[00167] Alternatively, approval of the collection of a drop may be conditioned on approval, e.g., in real-time or near real-time, by the person who dropped the money. For example, the depositor may decide whether to approve collection of the drop based on public information about the person picking up the money. For example, a camera may provide an image of the person attempting to make the pickup to a depositor who left the scene an hour before. From the image, the depositor can decide whether the person attempting the pickup look like the valet whom the depositor intended to tip. [00168] Thus, the payment network may be used for transactions with locations, whereby exchanges of money, data, crypto currency, or other electronic items may occur asynchronously without requiring all users to currently be on the network, present, or even have access to the network at the time a deposit is made to a drop site. A payment network money drop is a kind of virtual tip jar, whereby a sender places money at a location, be it a specific geolocation, a relative location, or proximity to a marking obj ect, while allowing the depositor, if desired, to retain some control over who retrieves the deposit and/or a time limit for doing so.

[00169] This extends the located-based payments system into the 4th dimension by providing a temporal element, enabling scenarios including future payments, geographically based loyalty programs, and thus a potentially “viral” customer acquisition method. That is, techniques applied to treasure hunt games, for instance, may now be applied to any electronic transfer while meeting the security expectations accorded financial transaction and the privacy and anonymity now sought by consumers.

[00170] Example Money Drop Flow

[00171] Figure 8 illustrates example operations for a money drop. The objects depicted are similar to those described in connection to Figure 1 and Figure 7, and the progressive trust building, progressive location determination, etc., described in connection to Figures 2-6 may be applied here as well. In the example of Figure 8, only one source of location information is depicted. However, as explained in reference to Figure 3, any number of sources of location information may be involved. Further, the sender and the receiver may be at different locations entirely.

[00172] In the example of Figure 8, money is being sent indirectly from a sending user to a receiving user via a “money drop” deposit associated with a location. Again, the money may be ear-marked for a specific receiver by conditions applied to the deposit by the sender, or the drop may be free for retrieval by whoever claims it first. Similarly, the deposit may be made with time restrictions for its retrieval, e.g., by a certain time or during certain hours, and/or according to other business rules.

[00173] In operation 1 of Figure 8, the sender’s device determines its location and/or other proximate devices on the payment network, e g., as described in connection with Figure 3.

[00174] In operation 2, the sender selects how much to money or other electronic items to drop at a location. The drop location may be the same as, or distinct from, the location of the sender at the time of the drop. [00175] In operation 3, the sender’s device sends to the payment network server drop information including, e.g., the nature / amount of the drop, the drop location, and conditions applying to the retrieval of the drop, if any. In operation 4, the payment network server removes the amount from the sender’s wallet and retains information pertinent to the drop in a drop record.

[00176] In operation 5, the receiver comes to the drop location. In operation 6a, if the receiver is not already a member of the payment for purposes of receiving a money drop, the receiver may connect their device to the payment network by installing a software application, e.g., a mobile device app from an online app store. Optionally the receiver may initiate progressive trust building, e.g., for the purposes of eventually receiving funds or other items in the drop into the receiver’s bank account or other repository. Alternatively, the receiver may wait until prompted by progressive trust building for any information necessary to complete a requested action. Note that operation 6a may apply in any situation where a new user wishes to use the payment network, e.g., in any connection with the operations described herein, e.g., in reference to any of Figures of TC1-9.

[00177] In operation 6b of Figure 8, the receiver’s device determines its location, e.g., using progressive location determination as described in connection with Figure 3.

[00178] In operation 7 of Figure 8, the payment network server tells the receiver’s device that there is a money drop nearby. Optionally, not shown in Figure 8, the receiver’s device can also query the payment network server for information regarding any nearby money drops. Again, this may occur prior to the receiver arriving at the drop location, or afterward.

[00179] In operation 8, the receiver selects the money drop to pick up. In operation 9, the receiver’s device sends, to the payment network server, a request to pick up the money drop.

[00180] In operation 10, optionally the payment network server communicates this request to the sender’s device and requests the sender’s approval. The sender can then elect to approve the pickup or deny it. If the sender denies the request, the sender’s device communicates this to the payment network server, and the money drop remains there for another receiver to attempt to pick it up. If the sender approves, the sender’s device communicates the approval to the payment network server, and the receiver is authorized to pick up the money drop.

[00181] In operation 11 , the payment network server adds the drop content to the receiver’s wallet. In operation 12, the payment network server communicates to the sender’s device that the drop items have been collected. In operation 13, the payment network server communicates to the receiver’s device that they have the drop contents, e.g., funds. In operation 14, the receiver is notified by the receiver’s device that they have received the drop contents in their wallet.

[00182] The sender’s and receiver’s geographic proximity is sufficient to send the funds even if the sender and receiver are not present at the same location at the same time. Furthermore, the sender has control over who receives the funds, if they want, or they can just let anyone pick up the funds. Lastly, senders could cancel a money drop before completion, and control over how long a money drop is present before drop contents are returned to the wallet of the sender if no one picks up the drop.

[00183] Conditioning on Route Taken / Locations Visited

[00184] The pickup of a drop may be conditioned on meeting complex criteria, including criteria pertaining to presence at several locations over time. For example, a portion of the drop may be set at each of several locations to be visited. Alternatively, all the drops may be paid upon visiting the last of a list of locations (e.g., a treasure hunt.) Further, the drop may be paid upon visiting a list of locations in a prescribed sequence, (e.g., a dog walker’s route.)

[00185] VIRTUAL POINT-OF-SALE (POS) TERMINAL

[00186] The techniques described herein may be used to operate a virtual point-of- sale (POS) terminal having several advantages over traditional hardware-based POS terminals. Conventional POS terminals are often costly and, owing to Payment Card Industry Data Security Standard (PCI DSS) requirements, for example, may be cumbersome in operation. Further, the use of specialized POS hardware entails expensive software development and/or customization and maintenance.

[00187] Alternatively, a virtual POS terminal for digital transfers may be associated with a location, whereby a business, service, or other entity can register at a location, so that they can exchange money, data, or crypto currencies via the payment network without requiring any physical POS terminal at that location. The processes for progressive trust building and other operations described in reference to Figures 2-6 would apply equally here, where users conducting transactions with the virtual POS have equipment like that described in connection to Figure 1, for instance.

[00188] For example, a merchant may receive a payment to their virtual POS and receive notices of payments on their mobile device, e.g., their cell phone, without needing any special POS hardware. The merchant would not even need to have a cash box or make change. Payments to the virtual POS may be routed to the merchant’s payment network wallet and be withdrawable from the payment network wallet using either a mobile device or a desktop web browser, for example. This eliminates the need for the merchant have any complex or expensive point of sale terminal, while providing equivalent functionality to all parties. Further, patrons of the virtual POS would not have to provide any private information, such as credit card numbers or contact information, to the merchant, nor would the merchant with protecting the security of such personal information of their customers.

[00189] Example Virtual POS Operations

[00190] Figure 9 illustrates operations of a payment network system involving a virtual POS. The elements of Figure 9 are similar to those described in reference to Figure 1 and Figures 6-8. In the example of Figure 9, there are two users of the payment network system - a shopper and a merchant. Each user has a computing device, with the ability to determine its location, e.g., via sensing and/or connecting with a source of location information. Each user has an associated wallet managed by the payment network server which stores their funds and/or other means for exchanging value.

[00191] Here in the example of Figure 9, not shown, the payment network server maintains a virtual POS record with an associated profile. The virtual POS may have a static geolocation or be mobile. The payment network system may maintain rules about when and how the virtual POS may move, for example.

[00192] Each user’s computing device can detect its own location, e.g., either directly, via a location specific intermediary device, or via a satellite-based positioning system, or via arbitration via the payment network server.

[00193] In the example of Figure 9, a number of locations may be involved. First is the location where the merchant is at the time of registering the virtual POS with the payment network. Second is the location where the virtual POS operates in the vicinity of the shopper. Third are future locations where the virtual POS may be moved on another occasion.

[00194] In operations la- Id of Figure 9, the merchant registers their location with the payment network. In operation la, the merchant’s device determines its location, e.g., via sensing and/or communications with a source of location information. In operation lb, the merchant’s device collects any necessary onboarding information from the merchant as may be required for receiving funds from the payment network, such as bank account information.

[00195] In operation 1c, the merchant’s device collects any further necessary onboarding information for the merchant to register as the owner of a virtual POS. For example, under local regulations, a merchant may be required to provide a tax identification number.

[00196] In operation Id, the merchant’s device communicates the device’s location and onboarding information to the payment network server. Not shown in Figure 9, in the course of progressive trust building the payment network may request further information to be provided by the merchant via the merchant’s device.

[00197] Further, the payment network server may undertake a number of operations to register the merchant as owner of a place of business using a virtual POS, as may be required by local regulations. For example, the payment network server may contact third parties for additional information and/or verification of the merchant’s onboarding information prior to registering the merchant as the owner of the virtual POS.

[00198] Notably, the payment network may make use of the physical location of the merchant at the time of registering the virtual POS, which may be different to the location near the shopper where the POS is eventually used, to secure the registration process.

[00199] Not shown in Figure 9, steps lato Id may be repeated in part when the merchant wishes to change the location of the virtual POS. For example, a merchant may operate at one location during the week (e.g., a road-side stand) and at a different location (e.g., a farmer’s market) each Saturday morning.

[00200] Once the virtual POS is registered, the payment network server may make the merchant’s virtual POS visible to members of the payment network. In the example of Figure 9, this is illustrated by operation 2, in which the payment network server sends virtual POS information to the shopper’s device. The virtual POS information may include a notification of the presence of the virtual POS nearby the sender’s device, for example, and optionally include with information regarding the business conducted at the virtual POS. Which members of the payment network receive information regarding the virtual POS may be based on a number business rules, e.g., pertaining to the proximity of the virtual POS to the sender, affiliation of the place of payment, and/or preferences of the sender.

[00201] In operation 3, after registering the virtual POS at the present location, the merchant may turn off their device, removing it from the payment network. The virtual POS registration may, nonetheless, remain in place for use by shoppers. The functionality of the virtual POS, from the shopper’s perspective, resides in the payment network server, not in the merchant’s device.

[00202] For instance, this functionality is useful for non-profit organizations who are receiving donations via the payment network server. Such organizations may want to always be able to receive funds, without limiting or controlling how much they receive in any given transaction. In addition, if desired, a user may leave their device on, so that payment network server can provide them real-time information about funds coming in.

[00203] The shopper’s device determines its location by sensing and/or communicating with a source of location information in operation 4. The source of location information used in operation 4 may be different from the source of location information used by the merchant in the original registration and may further be different from the source of location information used by the merchant in communicating the current location of the virtual POS to the payment network server.

[00204] In operation 5, the shopper’s device shows the merchant’s virtual POS to the shopper. For example, the shopper’s device, which received information about the virtual POS in operation 2, may wait until the device has determined that is has entered the vicinity of the virtual POS, via operation 4, to tell the shopper about the virtual POS. Alternatively, the shopper may learn about the virtual POS, e.g., via a QR code or tag at a booth operated by the merchant.

[00205] In operation 6, the shopper selects an amount of money to send to the merchant’s virtual POS. Either party may control the amount transferred for a particular transaction. For example, the conditions of a transaction may be “pay what you like,” e.g., where a church goer selects their own donation amount, or a museum goer sets their own admission price. At a food truck, however, the shopper may be required to pay the prices listed on the menu by the merchant. Accordingly, the payment network server can tell the shopper how much to send in step 6 or allow the user to send whatever the, e.g., based on a configuration selected by the merchant for use on the payment network server.

[00206] In the example of Figure 9, in operation 7 the shopper’s device communicates the amount to be sent the merchant’s virtual POS to the payment network server. In operation 8, The payment network server transfers funds from the shopper’s wallet to the merchant virtual POS’s wallet. In operation 9, the merchant may periodically connect their device to the payment network to check the status of payments.

[00207] In addition, visual signaling may be used. For example, the shopper’s device may display an indication that payment has been made, which the shopper may show to the merchant to complete the sale. That is, the virtual POS may operate primarily through interactions with the shopper’s device. The merchant’s device may be offline, turned off, or absent while the transactions are executed, without sacrificing the security of the financial exchange for either the shopper or the merchant. [00208] In operation 10, the payment network server may extend a time limit for operation of the virtual POS. For example, a virtual POS may be deregistered, permanently or temporarily, due to a period of shopper inactivity or of the merchant’s device being offline.

[00209] While the example of Figure 9 is presented in the context of a merchant collecting funds from shoppers, it will be appreciated that techniques described may be applied in a wide variety of scenarios, e.g., where data or crypto currency is exchanged instead of money, and/or where the users play different roles, such as the distributor and consumer of digital coupons

[00210] The use of a virtual POS may facilitate customer loyalty programs which respect shoppers’ privacy, e.g., by recording information about the shopper’s purchase history and/or other information, without requiring the issuance of another customer loyalty card or asking for the shopper’s phone number or other Personally Identifiable Information (PH )

[00211] Similarly, shoppers may agree to share information about purchases, preferences, and/or program status for activity of the shopper away from the virtual POS. For example, a merchant may wish to offer a discount to season ticket holders at a nearby sports arena, and the shopper may agree to let the payment network share such information with the merchant or, more specifically, with the virtual POS operations. Through progressive location determination, location may be very precisely determined, such that a shopper at a specific position along a counter may be identified, without requiring the shopper to present identification such as a loyalty card. Preferences may be communicated similarly, such that a shopper entering a tine triggers the preparation of their favorite order, without their having to reach the counter to enter the order. Customer experiences can be tailored and refined over time by recording not just the time of purchases, but specifics of the items bought and where the purchase occurred.

[00212] RESOLVING PROXIMITY

[00213] In many cases, transactions may be secure based primarily or solely on proximity information. For example, GPS signals for determining or verifying location may be unavailable indoors or where satellite signals are otherwise blocked. Herein, the term “indoors” refers generally to scenarios where absolute or relative geolocation information is not necessarily retied for one reason or another. This may be literally indoors, or outdoors or underground where reference signals are similarly unavailable.

[00214] The particular methods used by a system to secure transactions need not be visible to users per se. That is, a user experience may be arranged such that the decisions of whether location and/or proximity information are made in the background without the knowledge of the user, according to the requirements for individual transactions the circumstances of the availability of location and proximity information.

[00215] For example, when precise location information is not available, a user interface may yet display a map layer in the background, e.g., as a decoration to remind users that we the system is interacting with people or places nearby. The map image may be a zoomed-out map based on most recent location data, e.g., a map which shows Cincinnati as a whole. Or the image may be of last known location for the user, if relatively current, or a stylized map object which will be independent of any specific place names or identifiable geography if the system no usable location information for the user is available.

[00216] Similarly, whatever location information is available - e.g., general location, last known location, freshness of location information - may be considered when determining whether a given transaction can be secured, and/or what other information may be required to secure the transaction under the circumstances. Location and proximity information may be primarily collected from one or more parties to a transaction and from their devices, and/or secondarily collected from other devices in the vicinity. For example, other devices such as mobile phones and/or other devices belonging to people who are not parties to the transaction can provide secondary verification of proximity and/or location information, such other devices may belong other users of the payment network or may be otherwise known to payment network server.

[00217] Tn this way, progressive trust building may be implemented without geolocation information, for example, using only proximity data, and/or using proximity data to augment approximate geolocation information. Meeting AML and/or KYC requirements may thus be achieved without requiring parties reveal sensitive personal information to each other. Just as bad actors may be prevented from taking part in transactions by being unable to fake their location, similarly they may be blocked by being unable to fake proximity to the transaction.

[00218] Four example multi-modal methodologies are described herein for the use of mesh Bluetooth, NFC, QR codes, and Foursquare. These techniques bolster defenses against a bad actor (dishonest user) faking proximity to a good actor (honest user). This is because, inter aha, the bad actors interact with technologies outside of their control. For example, if Foursquare says we should see a set of Wi-Fi access points at a location, and we see other Wi-Fi access points instead, then we are probably not where the bad actors say we are. We can then escalate to refine our proximity and/or location information by requiring the bad actors to take additional steps, via progressive trust building, to verify who they are and/or where they are.

[00219] None of this complexity need be visible to the user per. The user display need not be altered based on how a payment network server, for example, is determining or checking location, proximity, or identity of the parties, or the propriety of the transaction under application rules and regulations. However, the user experience may vary somewhat, depending on the proximity and/or location information available, and details of the contemplated transaction, and histories of the users. The payment network server may use rules for alternative sources of confirming information. It may require differing levels of proximity and/or location resolution for differing kinds of transactions, and magnitude. For example, if you want to send $1,000, the system may require that the parties be within 10 meters of each other, if you want to send $10, proximity within one kilometer may be sufficient.

[00220] Such values may be determined dynamically, e g., based on the identity of the sender and/or receiver, the nature of the transaction, and/or other context information. For example, if you want to pay a business at a specific point of sale terminal, the system can tighten down the proximity requirement to one meter, and perhaps operate without other location information, depending on the modality used to determine proximity.

[00221] Mesh Bluetooth

[00222] A user’s device may form a Bluetooth mesh network connection with a nearby device. This solves several problems simultaneously. First, given the limited range of the Bluetooth radio (~30 feet) the system can ensure that the sender and receiver are truly nearby. By quickly scanning for nearby Bluetooth beacons - either devices in the local infrastructure, or devices that happen to be in the area, such as the phones of other users - any given user can securely find nearby people and places of interest in the environment and leverage such proximity information to help secure the transaction.

[00223] A payment network server may differentiate types of devices, such as (a) one-way transmitters of proximity or location, (b) two-way proximity transmitters without a know n location, and (c) two-way proximity transmitters with either a fixed or dynamic location

[00224] Traditionally Bluetooth beacons merely transmit an ID. The location of a beacon may be inferred from information nominally provided about their installation. However, the accuracy and security of such information may be questionable. Simple beacons may be inaccurately reported, hacked, duplicated, and/or moved. [00225] The quality or location information for a Bluetooth beacon may be enhanced in several ways, which then may aid security of a transaction. For example, the mobile device of a payment network user may detect a nearby smart beacon and send a cryptographic identity of the mobile device to the beacon. The beacon may then validate the ID o the mobile device, either cryptographically or via connection to a payment network server. The beacon may then generate a signed version of a public ID of the beacon which only that specific mobile device and/or associated payment network user can verify as correct. Again, this can happen in a standalone way using a hardware-based key, for instance, and/or via interaction with the payment network server. The mobile phone device may then receive the beacon’s ID and verify the cryptographic signature. Further the mobile phone, when interacting with the payment network server, may presents its proximity to the Beacon, which is again verified by the payment network server. In this way, the mobile phone can be assured that it is interacting with a beacon that is known to the payment network, and therefore its proximity can be reliably assumed by the payment network.

[00226] Notably, any Bluetooth-enabled mobile device on the payment network may serve as a Bluetooth beacon for other devices on the network.

[00227] This provides us distinct levels of verification of the user’s proximity to other devices depending on the nature of the communication with the other devices: one-way; two-way mobile app standalone (e.g., offline); two-way hardware standalone (e.g., offline); two-way mobile app with the payment network server (e.g., online); and Two-way hardware with the payment network server (e.g., online).

[00228] Enhanced Beacon information

[00229] Beacons may be adapted to transmit information above and beyond mere ID values. For example, metadata may include: location (horizontal and vertical), a payment network user or location ID, an amount due, a NFT, or payment network money drop information. In each of these cases, the metadata’s security corresponds to the proximity security levels presented above.

[00230] Vertical Information

[00231] Beacons such as Bluetooth beacons can help vertical location indoors. For example, Bluetooth uses low power transmitters and has a difficulty penetrating floors of an office building, due to material density and metallic content. If my phone can see your phone via Bluetooth, odds are that we are close to each other, and on the same floor. This enables distinguishing between a money drop on the 100th floor of a building with near complete certainty that people on other floors would not be able to pick it up. [00232] NFC

[00233] Near Field Communication (NFC) devices often have very short ranges, e.g., on the order of a few inches, as opposed to 10 meters for Bluetooth. Thus, NFC can provide precise proximity information. This may be exploited in several ways.

[00234] For example, physical NFC tags, e.g., RFID tags, may be “statically” placed so that a user can tap their phone on them. These tags may be associated with a person or place, so they identify a receiver precisely, for example, even without the receiver present. This enables asynchronous transactions in the same vein as money drop does, except in the opposite direction. For a money drop, a place or person is dropping value for an unknown, and not present at the time, receiver to pick up. In this case, a place or person is unknown, and not present to the sender (until they initiate the transaction). This preserves the payment network privacy ethos even for originating funds (e.g., paying a bill to a place.)

[00235] NFC tags can be geolocated as part of their configuration. In this model, the payment network uses the sender’s proximity to the NFC tag, combined with the known location of the tag, to infer the sender’s location which the payment network can then verify by other means as contextually necessary. In this model, the sender would tap a sticker which would say something like “To Pay with the payment network -Tap Here!” Tapping there with their phone would identify the exact receiver associated with that NFC tag and the customer w ould send payment the same way they already do.

[00236] Second, a phone can be a “dynamic “NFC tag. This extends the previous use case by enabling dynamic location based on the receiver’s phone, and the ability to dynamically embed an amount due into the NFC tag. In this case, the sender would “tap” the receiver’s phone and the Send screen could be pre-filled with an amount directly. These speeds the transaction and is under consideration as part of our Unified Point of Sale project. The amount may optionally be presented, and this mechanism can support P2P and P2B payments.

[00237] Notably, as with Bluetooth, NFC devices - even RFID tags - may be bidirectional devices, and capable of cryptographic computational operations, and therefore security may be enhanced via two-way dialogues with NFC devices.

[00238] QR Codes, et al.

[00239] Like NFC devices, QR Codes can similarly provide proximity information. Instead of tapping an NFC device, a sender may use the camera app on their phone to initiate the transaction. [00240] Wi-Fi

[00241] Location aware Wi-Fi may be used to resolve the location of user device. That is, a device may be determined to be within a certain proximity of a Wi-Fi base station, e.g., within -200 feet. This may be sufficient for some P2P or money drop transactions, and combined with additional proximity or location information for making a payment to place / virtual POS location. As with Bluetooth, Wi-Fi proximity may be used to resolve vertical location in indoor locations. For example, Wi-Fi preferentially connects to the strongest nearby base station, which would likely be on the same floor as the user, instead of the floor above or below them.

[00242] The payment network could determine whether parties to a transaction are on the same network and/or the same base station, for example, and that information may be sufficient proof of proximity, or be used in combination with other information to secure a transaction.

[00243] Foursquare

[00244] Data from proximity systems, such as Foursquare and Proof of Attendance Protocol (https poap.xyz ), for example, may be employed positively or negatively to enhance the security of transactions. For example, POAP in some cases cryptographically proves that you were at an event. A proof of attendance may be useful to prove eligibility to participate in a transaction. Conversely, conflicting proofs - e.g., electronic records suggestion being in more than one location at a time - may be used to screen bad actors from transactions. Similarly, “missed connections” indications from various systems can be used both affirmatively as proof of proximity for one event, and negatively evidence of not being present at another. Presence at multiple distant events may lead to disqualification of the user from being allowed to conduct certain, or even any, transactions.

[00245] OFFLINE BLOCKCHAIN SUPPORT

[00246] A payment network system may provide offline blockchain support for transactions, allowing users of the system to securely conduct transactions when access to the Internet is not available for final completion transactions at the time of the exchange.

[00247] For example, an offline cryptographic transfer may be implemented using verifiable and unforgeable messaging between two offline mobile devices, a distributed ledger of electronic coins, and a trust system to store and forward information. The coins may be cryptocurrencies pegged to U.S. dollar value. The user experience on a mobile device may be tailored for offline nature of the transaction. The payment network system may be adapted to incorporate, for example, foreign exchange adjusts in completing transactions when an Internet connection is later available.

[00248] Distributed Ledger

[00249] Every user node of a payment network may have a ledger of transactions, and this may be a private blockchain, i.e., cryptographically secure without participation in a public blockchain. For mobile clients, this ledger may contain an immutable list of transactions, for example, which originated with, or were received by, the payment network user associated with a mobile device belonging to the user. The payment network server may have an aggregate list of all transactions, again immutable, across all time. These ledgers do not have to be implemented using “blockchain” per se. However, out of the box, blockchain technology provided immutability, ledgers, and centralized transaction verification (via “mining.”)

[00250] Ledgers may be implemented in a number of ways. For example, nano.org uses a dual transaction model to ensure that the ledgers are consistent. See Figure 10. In addition, Nano requires that at least one end of the transaction (send or receive in their parlance) must be online and in real-time contact with Nano nodes which perform “mining” (cryptographic operations) to verify these transactions.

[00251] It is possible ease the burdens of mining operations by either simplifying the operations, providing incentives for third-party miners, or both. For example, simplification may include restricting off-line transactions to two-parties, so that the system does not need to transit of offline coins between multiple people before validation. Similarly, each endpoint may have their own blockchain, where, e.g., each device does its own mining operations separately. Mining may also be centralized under a single organization, such as the payment network, rather than reaching to outside resource of computational support of mining operations.

[00252] Mining incentives may be provided separately or connected with the currency of a transaction. For example, a miner may be paid for their effort with a fee, stock in a company owning the payment network, or a dividend, where the payment to the miner is associated with transaction itself, e.g., cryptographically.

[00253] The payment network server may manage a central ledger serves as the permanent source of truth for all transactions between all users. Here, the mobile client’s ledgers may contain offline transactions between specific individuals that are only needed and kept until on local devices until all pending offline transactions have been centrally replicated. [00254] Privacy may be maintained easily since no mobile device and no nonpayment network server needs access to transaction data for all users, because the central payment network ledger may be private. By avoiding use of publicly traded cryptocurrencies for securing offline transactions, there is no need to divulge the identities of parties in any way to secure the transactions. Rather, the advantages of cryptocurrency technology may be exploited locally for securing offline transactions, without incurring the risks associated with using traditional public coins.

[00255] Pegged Coins

[00256] For many users, speculative crypto coins are unsuitable daily use. Their values have been known to by 20% in a single day. They have high and variable transaction fees. They are popular targets for manipulation by bad actors.

[00257] “Stable coms” may be no better. Fundamentally, they are similarly vulnerable to attack either using their cross-chain interactions or using financial engineering. Bridges between crypto chains are also hacking targets because the bridges themselves are not “blockchain” which means that there is no “strong math” verifying transactions in the same way an on-chain transactions are.

[00258] Trust System

[00259] There is no way to guarantee the security of purely offline electronic transactions. Mobile phones are often in the hands of bad actors, and history shows that scammer too often succeed.

[00260] The best way to counteract this is to block the completion of transactions unless they meet online verification via a payment network ’s progressive trust building system, which includes lifetime usage tracking and requiring sufficient information to enable off-line transaction recording at the same risk profile as if the mobile clients were online. This may be achieved by linking the allowance and amount of an offline transaction to both the sender’s and receiver’s level of progressive onboarding (and verified KYC information) combined with their previous transaction history using the Distributed Ledger system. This enables both ends of a transaction - not just the sender or receiver to make a risk-based determination if the transaction should proceed, with the concurrence of the central system.

[00261] Store & Forward

[00262] When either the sender or receiver connects to the Internet, the offline ledger entries may be authenticated and complete recorded centrally by a payment network server. To accomplish this, sender and receiver’s mobile clients have enough information so that the transaction can be centrally verified with the information provided by either one of the parties.

[00263] Certain challenges for creating, storing, and forwarding local/offline blockchain ledger transaction records are known. Using a payment network with a central private ledger, instead of a distributed mining, avoids most of the issues of the Bitcoin Lightning, for example, by reducing complexity. Bitcoin Lightning relies on “channels” of people who store and forward a transaction, who must be online the entire time a transaction is pending, and who can cause any given transaction to fail. Instead, payment a network may limit a transaction to a sender and a receiver without any intermediaries. This greatly simplifies the failure cases and eliminates the possibility for bad actors to cause trouble.

[00264] For Bitcoin Lighting, issues have been reported with fee structures for opening and closing channels, and for transferring funds betw een channels. Further, Bitcoin Lightning is locked to Bitcoin, which is not a “pegged” coin, and exhibits 5-10% intra-day valuation fluctuations.

[00265] As an aside, this model of store & forward dovetails nicely into how Bluetooth mesh networking is implemented.

[00266] FXArbitrage

[00267] Currency fluctuations can be managed by reference to a fiat currency, for example, at the time of a transaction. That is, exchange rates among local currencies, foreign currencies, pegged coins, stable coins, and speculative coins can be managed without exposing users to the fluctuations associated with speculative coins.

[00268] For example, even in a virtual currency that is private to payment network system, the transaction can be noted as being valued in USD. Although no cash in the banking system is exchange at the time of an offline transaction, cash in the specified amount can be moved through the banking system when one or both of the parties is back online.

[00269] For transactions between parties in different jurisdictions - the U.S. and a country using the Euro, for example - the transaction may be agreed to by the parties to be pegged to one of the currencies involved, e.g., the Euro, to be settled for the U.S. user at the exchange rate prevailing at the time of settlement. Alternatively, the agreement could involve acceptance of a certain banding of FX shift between transaction origination and completion times, or could involve an averaging of fluctuations.

[00270] UX design

[00271] Care should be taken to shield users from the complexities of cryptocurrency transactions. Crypto technology is confusing to most users. Users are also perplexed by high and variable transaction fees, as well as the volatility of speculative coin valuations. To address this, additionally or alternatively, a payment network system may be implemented with uses blockchain ledgers to track fiat currencies directly or to track cryptocurrencies with are tied to fiat currency valuations. Using such pegged currencies, offline blockchain transactions may, from a user perspective, be fundamentally indistinguishable from online USD based ones, for example, since they are valued in USD. Their value is therefore perceived as constant over time. Further, using progressive trust building, such transactions may be conducted with absolute privacy from user to user - as private as cash.

[00272] Notably such transfers may be implemented using blockchain technology within the payment management system, rather than using public blockchains. In contrast, speculative crypto coins such as Bitcoin, while nominally anonymous, offer limited privacy. Anyone can view the transactions for a given wallet address for all time. In this way, all transactions are public. To send or receive crypto coins, you need to reveal your wallet address. In doing so, now at least one other person knows you, and your wallet address. . . At that point, it’s just a matter of time before you get “doxxed,” or robbed. In the payment network ledger environment, users should not be permitted to search central ledger / blockchain, nor even have access to private identity of those with w hom they conduct business.

[00273] ATTENDANCE AS CURRENCY

[00274] A payment network system may offer rewards, digital goods, non-fungible tokens (NFTs), etc., to users of mobile devices based on one or more cryptocurrencies. The cryptocurrencies may be existing currencies, such as Bitcoin, speculative cryptocurrencies, or a currency unique to the payment network, for example. Thereby, the payment network system may facilitate and/or provide a marketplace of rewards, digital goods, and/or NFTs offered only to people and users on the payment network system platform who have been authenticated through the system’s progressing onboarding process.

[00275] Proof attendance at a location by a user may be confirmed by the system. Attendance may be required for eligibility for certain rewards or promotional offers, for example. The system by not just confirm attendance, but also store this proof of attendance in a digital form, and permit system users to exchange proof of attendance as a digital good.

[00276] In a first example, a user downloads the payment network system application to their mobile device. The user is onboarded to the system using basic personal information and/or credentials. The user allows access to their geo-location to the payment network system. The user connects their new payment network system account to an external payment account, such as a web3 wallet, and gives a public address and read permission to the payment network system.

[00277] The payment network system backend registers the web3 wallet and associates it with their existing payment network system wallet, which is connected to a bank account. This allows payment network system to use existing cryptocurrencies on the payment network system application to make purchases for the user.

[00278] The authenticated user is able to then pick up digital goods at a designated location. This good will only be transferred to the user if they have passed the payment network system security and authentication levels for accepting the digital goods.

[00279] These goods are stored in a wallet on the payment network system, which could only be accessed through the payment network system app.

[00280] The payment network system will read the user’s wallet and extract a collected token or digital good’s metadata in the wallet.

[00281] Users who have collected these digital goods will be able to further unlock benefits in the payment network system app because they have gone through the security assessment process and collected a specific digital good that can unlock new layers of the payment network system app.

[00282] The payment network system can also send a push notification if a digital good is within a short distance of the user’s cunent location.

[00283] This digital token can also be transferred for real world items at physical locations that accept payment network system digital goods as currency. For example, if someone has to submit their state ID with their age confirmed on the payment network system app as part of their security assessment on payment network system, and the user is above the age of 21, perhaps they can redeem the digital token for a real world, physical item that can only be sold to someone over the age of 21. The application can authenticate users for access to specific in-person activities by offering a token that is immutable, such as a non- fungible token.

[00284] Similarly, in a second example, a user downloads the payment network system app. The user is onboarded with basic credentials and gives access to their geolocation on payment network system. The user connects their web3 wallet and gives a public address and read permission to payment network system, which allows payment network system to use existing cryptocurrencies on the payment network system app to make purchases. The payment network system backend registers web3 wallet and associates it with their existing payment network system wallet, which is connected to a bank account. The payment network system backend registers web3 wallet and associates it with their existing payment network system wallet, which is connected to a bank account.

[00285] The user goes to a phy sical location for an exclusive offer that is only available to redeem with payment network system at that specific location. They receive a non-fungible token that serves as a right to buy that store’s goods in the future, either in- person at that location or online. The verification of in-person participation at an event combined with account verification with security controls provides double protection against fraud.

[00286] Attendance at multiple locations may be required, for example, to unlock a benefit. That is, a kind of participatory scavenger hunt, or signs of repeated loyalty, may be securely recorded and tracked for individual users. Users may then exchange these proofs with vendors for benefits, or trade proofs of attendance between users.

Claims

CLAIMS We claim:

1. A payment network server, comprising a processor, communication circuitry, a memory, and computer-executable instructions stored in the memory which, when executed by the processor, cause the payment network server to: receive, from a first mobile user device (sender device) associated with a first user (sender), a first indication comprising an intention to deposit funds electronically at a first location (drop location) in a first amount; receive, from the sender device, a second indication comprising a confirmation of a current presence of the sender device at a second location; determine, based on a first database of users of the payment network server and a second database of regulatory requirements, whether sufficient information is available to the payment network server about the sender device to securely make a deposit to the drop location and, if not, engage the sender device in a first dialogue to acquire necessary missing information; if sufficient information is available to the payment network server, deposit, from a first wallet to a second wallet, funds in the amount of the first notification, wherein the first wallet is associated with the sender and the second wallet is associated with the drop location, and wherein the wallets reside electronically in the payment network server; receive, from a second mobile user device (receiver device) associated with a second user (receiver), a third indication comprising a confirmation of a current presence of the receiver device at the drop location; receive, from the receiver device, a fourth indication comprising a request to withdraw fund from the second wallet; determine, based on the first database and the second database, whether sufficient information is available to the payment network server about the receiver to securely conduct a withdrawal from the second wallet and, if not, engage the receiver in a second dialogue to acquire necessary missing information; if sufficient information is available to the payment network server, transfer, from the second wallet a third wallet, funds in the amount of the first notification, wherein the third wallet is associated with the receiver and resides electronically in the payment network server; transfer, at the request of the sender, funds into or out of the first wallet via a first external financial system gateway; and transfer, at the request of the receiver, funds into or out of the second wallet via a second external financial system gateway, whereby: if sufficient information is available to the payment network server, transfers from the first wallet to the second wallet and from the second wallet to the third wallet occur without requiring personally identifiable information associated with the receiver being sent to the payment network server from the sender device and without requiring personal identifiable information associated w ith the sender being sent to the payment network server from the receiver device.

2. The payment network server of claim 1, wherein personally identifiable information comprises a phone number, name, online person, email address, web address, postal mailing address, residence, or credit card or other account number.

3. The payment network server of claim 2, wherein the drop location is a fixed geolocation.

4. The payment network server of claim 2, wherein the drop location is a proximity to the sender device.

5. The payment network server of claim 2, wherein the drop location is a position relative to a mobile beacon.

6. The payment network server of claim 2, wherein the instructions further cause the payment network server to: receive, from the sender device, one or more conditions for withdrawals from the second wallet; and determine whether sufficient information is available to the payment network server about the receiver to securely conduct a withdrawal from the second wallet is further based on the conditions for withdrawals from the second wallet.

7. The payment network server apparatus of claim 6, wherein: the drop location is a fixed geolocation; and the conditions for withdrawals from the second wallet comprise a requirement for withdrawal by an owner and/or a legal occupant of the drop location.

8. A payment network server, comprising a processor, communication circuitry, a memory, and computer-executable instructions stored in the memory which, when executed by the processor, cause the apparatus to: receive, from a first mobile user device (sender device) associated with a first user (sender), a first indication comprising an intention to transfer funds electronically to a second mobile user device (receiver device) associated with a second user (receiver); receive, from the sender device, a second indication comprising an amount of funds to be sent to the receiver device; receive, from the sender device, a third indication comprising a confirmation of a current presence of the sender device at a location; receive, from the receiver device, a fourth indication comprising a confirmation of a current presence of the receiver device at the location; determine, based on a first database of users of the payment network server and a second database of regulatory requirements, whether sufficient information is available to the payment network server about the sender device to securely conduct a transfer of the funds and, if not, engage the sender device in a first dialogue to acquire necessary missing information; determine, based on the first database and the second database, whether sufficient information is available to the payment network server about the receiver to securely conduct the transaction and, if not, engage the receiver in a second dialogue to acquire necessary missing information; if sufficient information is available to the payment network server, transfer, from a first wallet to a second w allet, funds in the amount of the second notification, wherein the first wallet is associated with the sender and the second wallet is associated with the receiver, and wherein the wallets reside electronically in the payment network server; transfer, at the request of the sender, funds into or out of the first wallet via a first external financial system gateway; and transfer, at the request of the receiver, funds into or out of the second wallet via a second external financial system gateway, whereby: if sufficient information is available to the payment network server, the transfer from the first wallet to the second wallet occurs without requiring personally identifiable information associated with the receiver being sent to the payment network server from the sender device and without requiring personal identifiable information associated with the sender being sent to the payment network server from the receiver device.

9. The payment network server of claim 8, wherein personally identifiable information comprises a phone number, name, online person, email address, web address, government identification number, postal mailing address, residence, or credit card or other account number.

10. The payment network server of claim 9, wherein the location is a fixed geolocation.

11. The payment network server of claim 9, wherein the location is a proximity to the sender device.

12. The payment network server of claim 9, wherein the location is a position relative to a mobile beacon.

13. The payment network server of claim 9, wherein the instructions further cause the payment network server to receive, from the sender device, an anonymous indicium of the receiver device, the anonymous indicia pertaining to a QR code displayed by the receiver device.

14. A payment network server, comprising a processor, communication circuitry, a memory, and computer-executable instructions stored in the memory which, when executed by the processor, cause the payment network server to: receive, from a first mobile user device (merchant device) associated with a first user (merchant), a first indication comprising an intention to register a virtual Point-Of-Sale (POS) terminal at a first a location; receive, from the merchant device, a second indication comprising a confirmation of a current presence of the merchant device at a second location (merchant location); determine, based on a first database of users of the payment network server and a second database of regulatory requirements, whether sufficient information is available to the payment network server about the merchant device to securely register the virtual POS terminal at the first location (POS location) and. if not, engage the merchant device in a first dialogue to acquire necessary missing information; if sufficient information is available to the payment network server, register the virtual POS terminal at the POS location and associate a first wallet with the virtual POS terminal, wherein the first wallet is associated with the merchant and resides electronically in the payment network server; receive, from a second mobile user device (shopper device) associated with a second user (shopper), a third indication comprising a confirmation of a current presence of the shopper device at the POS location receive, from the shopper device, a fourth indication comprising a request to make a payment to the virtual POS terminal; determine, based on the first database, the second database, and status information regarding the virtual POS terminal, whether sufficient information is available to the payment network server about the shopper, the merchant, and the virtual POS terminal to securely transfer funds from the shopper to the merchant and, if not, engage the shopper in a second dialogue to acquire necessary missing information; if sufficient information is available to the payment network server, transfer, from a second wallet to the first wallet, funds in accordance with the fourth indication, wherein the second wallet is associated with the shopper and resides electronically in the payment network server; transfer, at the request of the merchant, funds into or out of the first w allet via a first external financial system gateway; and transfer, at the request of the shopper, funds into or out of the second wallet via a second external financial system gateway, whereby: if sufficient information is available to the payment network server, transfers from the second wallet to the first w allet occur without requiring personally identifiable information associated with the shopper being sent to the payment network server from the merchant device and without requiring personal identifiable information associated with the merchant being sent to the payment network server from the shopper device.

15. The payment network server of claim 14, wherein personally identifiable information comprises a phone number, name, online person, email address, web address, postal mailing address, residence, or credit card or other account number.

16. The payment network server of claim 15, wherein the POS location is a fixed geolocation.

17. The payment network server of claim 15, wherein the POS location is a proximity to the merchant device.

18. The payment network server of claim 1 , wherein the POS location is a position relative to a mobile beacon.

19. The payment network server of claim 15, wherein the instructions further cause the payment network server to: receive, from the merchant device, one or more conditions for payments to the virtual POS terminal; and determine whether sufficient information is available to the payment network server about the shopper to securely conduct a withdrawal from the second wallet is further based the conditions for payments to the virtual POS terminal.

20. The payment network server of claim 15, wherein the instructions further cause the payment network server to allow the merchant to alter the POS location.